CI Process – Why?

Why is having a CI process good?

There are so many reasons why CI is good. I use it on everything I do. For my recent web based project it’s simple a must have. Forcing you to take an application and pipe it through a series of standardised processes is invaluable. In regards to web applications I go through the full monty. The process I use is:

  • Dev & Debug in Visual Studio
  • run unit tests locally
  • commit to SVN
  • TeamCity Debug Build (Unit Tests included)
  • TeamCity Debug Build with ReSharper Code Inspections and FxCop
  • TeamCity Release Build with NuGet Artifacts
  • Octopus Deploy to local IIS for Staging

I do this even though it’s only me on the project. A web application should be sturdy enough to make it through this process and flourish at the other end of the process. It helps keep things robust, transferable, repeatable, tracked and traceable. All good things for software!

Obviously the quality and coverage of your unit tests is a key element in the process but the pipeline described above is also key to ensuring that an engineered process is always taking place, the randomness is removed entirely. Ideally the build process should be occuring on separate machine as the environment it’s being integrated in is same environment it’s designed in which isn’t ideal but arguably less troublesome than doing it with a desktop application complete with windows installer.

The next step to be added to this process is something along the lines of Selenium automated tests to run against the website itself.

Leave a Reply

Your email address will not be published.


This site uses Akismet to reduce spam. Learn how your comment data is processed.