Continuous Integration (CI) is one of the software practices/techniques I recently had the chance to learn and play with at the SSW’s FireBootCamp and which has completely changed the way how I see software development and how I want to craft it moving forward.

If you feel yourself identified with some of the below items you should be looking into incorporating CI practices into your software development pipeline:

  1. You don’t have a source control system.
  2. You get a copy of a project from your control system but it won’t run because there are missing files or the build is broken.
  3. You rarely check-in your code.
  4. You never get the latest version from your source control system before checking in your code to make sure any new changes made by other developers don’t break your code (or even worse, to make sure YOUR code won’t break the build)
  5. You don’t write unit tests
  6. You don’t write integration tests
  7. You do write unit/integration tests but don’t run them against your code AND the code that sits on the source control repository.
  8. You check in a task/feature only when fully completed (after days/weeks of working on it) only to realise it won’t work on UAT/staging/production

Any of the above will result in painful integrations, poor quality code (usually off-schedule), with many many bugs and with the overall experience that software development sucks (without mentioning what the end user/customer will think about the product/us).

Is there a way out?

Yes !, its called Continuous Integration and it’s relatively easy to implement (I haven’t personally had much experience to be honest but I can see the many benefits from it and the steps seem simple enough)

It’s whole concept revolves around the idea of improving your development practices by encouraging you and your team to:

  1. Get the latest version of the shared code before checking in your code.
  2. Run unit and integration tests against your code.
  3. Check-in your code regularly (at least daily).
  4. Have a build automation system.
  5. Have the shared code built by your build automation system
  6. Have the shared code verified by running automated unit and integration tests against it
  7. If any of the above steps fail then have the build automation tool inform you so you can fix it and start the process again.

Simple, huh? to me the greatest advantage of following this process is that you don’t need to spend separate time trying to integrate a newly built feature into your system; by checking in your code and fixing problems along the way the ‘integration’ becomes an inherent task that of the process, i.e. no need to wait for months to realise that two complex features that you and your team were working on did not integrate properly and now you have now to stay back and fix it rather than going to the pub with your friends :(.

Some others (equally important) advantages are:

  1. You always have a working version of your product (which could potentially be a shippable product)
  2. You get immediate feedback about any problem that arose as a consequence of the new code checked-in.
  3. Greater visibility of the current status of the product
  4. Isolating and tracking bugs becomes easier as it’s often related to the new code.
  5. Reduces the number of bugs in your application as you fix them sooner rather than when the customer rings you a month later.
  6. Improves communication with your team

There you go, start incorporating a continuous integration process in your software development practices if you haven’t already done so.

By the way, there are some great blog posts about this subject that I have listed below:

Do you know of any other advantages that Continuous Integration provides?