Warning you now tha this will be a very long email, but I think it's a question that some of you must have dealth with, so hopefully you'll read it. And even if you haven't dealt with this, it's an interesting scenario.
I'm creating automated build process for a large, distributed system. There are dozens of individual applications, but overall they make up one large system. There are multiple database servers (each housing different data) There's a web farm of several identical machines, each running many different web applications (which are coupled to varying degrees, either via shared COM objects, shared asp files, and/or shared databases). There is also an additional web server that houses internal tools for used for managing varying aspects of the system. That machine has a couple websites running on it, coupled to the other systems, albeit more loosely, through shared databases. There are also a few backend machines running middle tier logic (jobs processing). There are two classes of these machines. We'll call them class A and class B. There could be multiple identical machines of either class in production. The code is spread out across several projects in our source control (StarTeam). An example of why I don't like the current organization is that for two of the more coupled web apps, dependencies for one project are held in another starteam project. Changing either usually means chaning components in both projects, (and currently manual build, and messy manual deployment, until we start using the scripts). I got around this by creating a view in a neutral starteam project and sharing all the source for the components between the two apps in this view. The build scripts build from this, and label that view. So my question to you is, should such a system have a single automated build, with a single version number for the whole thing? I'm inclined to continue pulling code from other projects into this neutral view and eventually have the entire system built from this location, and versioned/labeled here. This way I can generate builds for any and all of the machines (web farm, internal tools, class A & B middle tier, etc) as they existed for any release, and also know exactly what the source code generated any version of the compiled binaries (or which .asp scripts were in a release along with which COM components, etc). Right now it would be difficult to know what code created which binary (even if I knew). And I also like the fact that the build.number file in the root of the neutral view dictates the build number, and each automated build uses this number to label the neutral view. One build number for the entire system. What would be the drawbacks to a process like this? Speed might be a concern. Another would be that the entire system would be rebuilt with any release, so changes to a component on the IIS machine that wouldn't really affect a back-end jobs machine, would result in rebuilding everything and we'd get a new install package to deploy to the jobs machine. For this reason I don't want to include .asp files in the build. Still not sure though. There are probably ~40 VB6 COM objects (23 of those are already part of what I've automated in the neutral view), fewer than a dozen .NET 1.1 projects, and hundreds (probably > 1000 actually) of .asp files, hundreds of database tables, and hundreds of stored procedures in all. "Few are those who see with their own eyes and feel with their own hearts." -Albert Einstein __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
