One of the tasks I'm facing at a project these days is coming up with a automatic build configuration for the project. the idea is having a “daily build” for an existing project which comprises of roughly 110 sub projects (imagine loading that solution in vs.net!).
It is quite fun. Like solving a big puzzle.
Here's a little about what I envision. Feel free to comment.
The tool:
The automatic build tool that we Will be using is FinalBuilder. It has roved itself in many areas I've seen, including some of the most respected members in the community that use it on a daily basis.
Why not the free tools out there?
Let's face it - MSBuild, NAnt and all their friends, unless I'm mistaken, are pretty sucky in the visual development and maintenance department. I made a promise to myself I won't do manual XML editing unless I am forced to by gun point or a salary decrease. Neither has happened. yet.
The architecture:
A build server
A source control server
A backup server
A testing server
A staging environment (multiple machines imitating the machines at the production location)
A remote staging environment(less machines but more similar security restrictions).
In broad strokes a daily build would mean:
The build server takes out all source control from source control
build it all (including all versions, debug and release)
Back up to zip files using incremented version ,date and time into the backup server
Deploy automatically onto the testing machine all the part of the distributed application in question, allowing the team to run smoke test on the built application.
However, there are more processes.
After smoke testing and more rigorous tests, another automatic script will deploy a version into the staging server.
It Will use the backed up zip files from the back up server for this.
Load testing and others will performed on the stating servers.
After that another automatic deployment will take place - onto the remote staging servers.
These serves sit in the same place as the real production ones, and so enjoy the same security benefits , meaning we can test what happens behind the real firewall and active directory and all that. Once tests have passed there, we can use another auto deploy into production.
These are the basic steps. It's pretty fun planning this, kinda like building your own big ant farm.
One of the biggest issues we are facing and still haven't solved is this: Databases.
In many cases, making a new release might mean just a few changes on the database data, and nothing more.
There needs to be a way to get just those changes from the dev DB and into the test DB, automatically.
It gets a little tricker. We also want the database to be backed up along with each version's source files into the backup server. A binary backup will do in some cases (multiple databases here, but some databases need to be retained only in schema and not in binary form.
certainly this will prove to be the biggest challenge in this process.
I'd be interested to hear how other people get around this problem.