How do you catch things like:
1. Connection strings are different for test and production.
2. Some page uses a 3rd party control that isn't installed on the production
server.
3. Some code uses an assembly that isn't present on the production server
(e.g. the zip library from vjslib.dll).
4. Firewall issues (if test is inside the firewall and production is in
DMZ).
We've tried to mitigate these problems by using the same server for "test"
and "production" (just a different web site on the same server) and by never
copying web.config (we make changes manually, if necessary).
I'm just wondering if there is a better way. I guess I'm also saying that
it's not always as easy as "1, 2, 3".
"Peter Bromberg [C# MVP]" <> wrote in message
news:F531A6F4-9F7C-4BCA-A1E3-...
> If you are talking about ASP.NET, all you really need to do is:
> 1) ensure that what you are moving is a Release build.
> 2) ensure that the debug ="false" directive is present in web.config
> 3) Copy over the files and the /bin folder.
>
> Most places I've worked we've instituted a "Smoke test" prior to
> production
> deployment. Usually its an Excel spreadsheet that tests everthing in the
> application and you mark "pass" or "fail" in the last column. the project
> mgr
> signs off on it, you copy the app to production, give it a test, and
> you're
> done.
>
> Thats not complicated, requires no special software, and seems to work
> just
> fine.
> -- Peter
> Site: http://www.eggheadcafe.com
> UnBlog: http://petesbloggerama.blogspot.com
> MetaFinder: http://www.blogmetafinder.com
>
>
> "Mufasa" wrote:
>
>> I'm working at a small company that has been very lax about moving things
>> from test to production. We are now going to start doing some real
>> processes
>> for doing this.
>>
>> Does anybody have any suggestions about how to 'release' software from
>> test
>> to production? Are there software packages that will allow us to do this
>> automatically or is it a manual process?
>>
>> Any thoughts would be appreciated.
>>
>> TIA - Jeff.
>>
>>
>>