Setting up a Continuous Integration System, Part 3: CI Workflow

August 25, 2009 15:45

This is the next part in an ongoing series about setting up a continuous integration system. The series includes:

  1. Part 1: Introduction
  2. Part 2: Project Folders
  3. Part 3: CI Workflow (this post)
  4. Part 4: CI Server Baseline Software
  5. Part 5: CruiseControl.NET Custom Plug-in: Update Version
  6. Part 6: CruiseControl.NET Custom Plug-in: Source Retrieval
  7. Part 7: Installing CruiseControl.NET and Custom Plug-ins
  8. Part 8: Configuring CruiseControl.NET
  9. Part 9: Conclusion

Before I actually start configuring my CI server I first wanted to present the general workflow my CI process follows.

Continuous Integration Workflow

CI Workflow

With the CI environment (server) up and running, the initial action is always a developer checking in source. From there, the CI process is completely automated up until we either hit an error or complete successfully.

On success, the output is, of course, a release candidate set of files. I generally produce many release candidates, but just because the CI environment has produced one doesn't mean I'm going to do a production release. But I always have confidence that I could deploy a particular release candidate because I know it has gone through my unit and integration testing wringer and come out squeaky clean.

Conclusion

My CI workflow no doubt differs from your own; the process is not a "one size fits all" sort of thing. If, however, you've got something I've completely missed, let me know. I'm always looking to enhance or improve my CI process.

Next post, let's start configuring our CI server.


All comments are moderated and require approval before display. Thanks for your understanding.

Add comment


 


[b][/b] - [i][/i] - [u][/u] - [q][/q]



Preview