Moving things from test to production.

  • Thread starter Thread starter Mufasa
  • Start date Start date
M

Mufasa

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.
 
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
 
I actually use this more simple model as well , 90% of the time.

This post:
http://groups.google.com/group/microsoft.public.dotnet.framework/msg/1f2a4acce0d9c77c

shows a trick I use to get release-build stuff, without going through the
GUI. via a .bat file.
But its essentially the same thing. Build in release mode.....
I actually never copy my web.config file....to a staging or production
server....you might even include web.config in the exclude.txt file. (This
is how I ensure the debug=false setting stays correct).




.............

But again, this is the simple approach...there are many steps between simple
and super-duper MSBuild level...so throw out some goals.
 
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".
 
Back
Top