Build and Deployment - take 2

We are currently involved in going "live" with our first beta.  This is a mid-sized .NET application using all the .NET pieces - winforms, webforms, webservices, ...

Of course, while we are trying to get a CD to send to our data center we are still finding bugs and patching.  The configuration managment process is very interesting to me.

How to patch by rebuilding only what's necessary and copying the dlls where they need to go is a manual process right now - and mistake prone.   This process will be automated. 

I have a working build process that uses an xml config file containing a list of projects, in no particular order.  The process gets those projects from VSS and builds them in build order.  I use makefiles and nmake.exe to compile.

Nant http://nant.sourceforge.net would have been a better solution, perhaps, but I'm not going to change now.

Other solutions might be:

Build It: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/tdlg_app.asp

or Build: http://www.gotdotnet.com/Community/UserSamples/Details.aspx?SampleGuid=2cb20e79-d706-4706-9ea0-26188257ee7d

Currently the build process is very stable and since I'm not that interested in "improving" it the process will left alone.  The initial deploy/installation process is also stable.

The patch process is another story...

Published Friday, June 27, 2003 9:18 AM by cloudycity

Comments

# re: Build and Deployment - take 2

The patch process is extremely difficult as your software scales up in complexity and you scale out across developers. As more and more deliverables are added(.exe, .asp, .dll, tables, stored procs, data, etc) the process becomes nearly impossible to handle manually....

I think the answer is that you really need automated packaging and deployment. We were forced to build such a beast to control the literally thousands of deliverables that need to be managed as part of our software. For a patch, we may only fix 4 files out of 5000, but finding those 4 and tracking them is a bear.

It is intereting to note that this process is(and needs to be) end-to-end and pretty comprehensive. Incidents need to be tracked to a version, files to an incident, files checksummed, deployment tool support and verification needs to be done. To do the process correctly we need to hook not only the incident system but also Source Control to make sure developers are putting files in the right places and at the right time. Otherwise, the logistsics of this is pretty difficult with a lot of developers and many branches of code/versions.

I know MSFT has some internal tools(SNAP/MadDog??) that model such a process. I secretly hope that they would share these tools and their processes.

If you want to talk more, drop me a line.

sprugh-at-telution-dot-com

Friday, June 27, 2003 6:47 PM by Scott Prugh

Leave a Comment

(required) 
(required) 
(optional)
(required)