Recently I had a post where I made the statement ‘To CI or not to CI, did not realize it was still even a question?’. The intent of the post was to assert that I did not realize that having some sort of CI (Continuous Integration)/Build Server was not considered the norm for a development shop. I that post I stated that your CI setup could be as simple as a cron job running a script or be a full fledge product such as Team City, Hudson or CC.Net.
Since I went out and did a rant about how there was no excuse for a team to NOT have a build server I thought I would put together a post on the various things I would expect to see from a CI server. Now I am NOT saying that if your CI setup does not do all these things you are doing the right thing. What I am saying is that the list below (and I am sure I will miss something) are some of the things I expect my CI setup to do for me (in no real particular order).
- Monitor my source repository and build on changes
- Run my unit tests
- Run various static analysis metrics
- Code Coverage
- FXCop/Style Cop
- Any of the metrics from NDepend
- Publish assemblies for usage (could be to a test server, a file server or ftp server)
- Build a clean copy of the database from my setup scripts (we have a running list of alters we use to perform upgrades)
- Be able to commit versioned assemblies back into the repository for other teams to use (if that is something your team needs)
- Create some sort of visual graphs/trends for tracking
- Be able to run a build which creates and packages an installer (for deployment)
- Send notifications (emails/post to discussion boards, twits, etc) when there are issues
Now I know this is an extensive list. I also know that trying to do all of these things at one time is both daunting and not practical. But these should be the goal. What I will say is this, start small and build. Your goal should be to incorporate these things into your build over time and if htat is your goal you will be amazed what happens.
Till next time,
06-04-2009 8:02 PM