Iteration #2 - Day #3 Tuesday 1/7/2003
The continious integration issue raised its head again in the form of deployment issues. Simply put our current process stinks, it takes over an hour to create the build and 3-4 hours to deploy to Dev and QA and that is a simple website + database deployment, it doesn't include any other services. The first order of business was to automate the website build process and dedicate a build machine and build master. After fiddling with nAnt for awhile I discovered the devenv.exe command lets you build a solution without haveing to redefine it in nAnt, a big bonus. I then created an installation (deployment?) project for dev and QA. I only created the QA install project to support our current shared Dev/QA web server, that will be changing soon so that Dev and QA have completely seperate environments. The end result is we can build a Dev installer for the website in about 5 minutes now. The tasks remaining are automatically getting the latest source from VSS and labeling the source. I'd like to automate the VS IDE since it has its own ideas about which files belong to a project and how that is integrated into VSS. Eventually I'd love to have automated version control, builds, unit tests, functional tests (FIT) and deployment. We'll see.
Our other issue is that each environment has it's own need for *.config files, service accounts, permissions, extra virtual directories, etc. Currently this is a manual process that takes the bulk of the time during deployment since none of the builds are consistantly one way or another. The other disadvantage of our current system is that all the config files are not under version control!
We are planning to address these issues by placing all environmental setting in one config file per deployment unit including a setting indicating which environment should be used and a custom configuration class for accessing the settings. The other non-config settings will be handled by extending the installation process with some custom logic.
Another issue we've bumped up against is the issue of common projects. Previously the complexity was low enough and only a single developer worked on any one project (for the most part) that this wasn't a problem. With the advent of collective code ownership and common interfaces to remoted services it became an issue. We solved this one by placing the shared code in it's own solution and putting the release dll in VSS and sharing them into a "Lib" folder for each project that needs access to them.
We also brought another team into the agile fold. The team is struggling with some of the same issues we did originally, but we have better answers this time.
We are also having fits and starts trying to get the stories written at the correct level of detail. QA is stepping up to the plate here and becomming what we are calling the "Customer Advocate" by fleshing out the stories with assumptions, constraints and highly sinplified use cases. This is a natural progression into their acceptance tests and helps the developers as well.