Continuous Integration best practices checklist 2

Share it!Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInEmail this to someoneShare on Reddit

Almost all software companies are using Continuous Integration methodology. Whilst 10 years ago it was considered an extreme programming (XP) practice, nowadays most developers cannot imagine their work without fully implemented CI. There are dozens of system and tools facilitating the implementation of CI, from build systems and testing frameworks to scheduling and monitoring applications.

Nevertheless, we are still facing many problems in our everyday programming work and we are struggling to provide working and robust code. One of the reasons is Continuous Integration that is not fully implemented. As a result we are gaining only some of the many great benefits which it can provide. Checkout the below checklist of the best CI practices to verify how far you are from the almost perfect situation:

  1. Your team members commit regularly to a baseline branch. By regularly I mean a few times per day and in the worst scenario once a day. There are no exceptions and explanations (well, in fact sometimes there are, like for example debugging a nasty bug for three days and then committing a fix plus a test).
  2. Every team member knows where to check CI build results and checks it regularly after their commits. Results should be easy to access and presented in a clear, transparent way.
  3. Broken CI build is handled immediately. Whenever a build is broken, the whole team drops their work and verifies who should handle the fix. An identified person (usually the one who introduced the problem) should immediately work on a fix. If they are not able to provide a solution in a time boxed amount of time (usually 15 to 60 minutes) their change should be reverted.

  4. Your team feels responsible for CI builds. There should be no situation when builds are broken for a few hours and no one cares about it. While there might be a dedicated person assigned to a build watch role, it is more effective if there is a common team desire to have green/blue builds all the time.
  5. No one commits on a broken build. When several problems cover each other the situation is getting really messy and difficult to fix. Moreover, your team starts to get used to the fact that the build is broken and is automatically ignoring points 3 and 4.
  6. Every team member leaves the office after assuring that their commit has not broken the build. No Friday evening last minute commits! If things are going badly, you can always revert the change and let your team members start the next day with a working application.
  7. Every team members locally tests their changes before commit. The CI server is not treated as a first verification of their changes but rather as a final confirmation that a change works. Such tests should include at least compilation, unit tests and possibly short application smoke tests.
  8. Your main CI build (sometimes referred to as a commit stage) is executed for every commit. In most cases it allows you to almost instantly detect who introduced the problem.
  9. Your main CI build is no longer than 10 minutes. Practice shows that longer builds are frequently ignored by development teams. It is much harder to remember to check the build in half an hour (or even a few hours!) than in 10 minutes.
  10. Your CI build works exactly the same as the standard local developer build. The best scenario is when the same build command can be used in both use cases. Also the CI and local developers environments should be pretty much the same.
  11. Your tests executed during the commit stage provides 70 – 80% of code coverage. Thanks to that it is assured that a great amount of code works as developers expect.
  12. Your CI build fails on code style violations and architectural breaches. Thanks to it your team can avoid a lot of the more common pitfalls. The code is cleaner, the application more robust and the grass greener.
  13. Your CI build fails on slow tests. There is a community assumption that it should be possible to execute 100 unit tests within a second. While sometimes it is hard to achieve, you can still define some time period which cannot be exceeded. Depending on the project, it may vary from 100 milliseconds to 1 second per test.

Can you provide a yes answer to all the above points? If so, you are in the one of the model projects that fully benefits from Continuous Integration practice.

However, sometimes such a situation is hardly achievable. It is usually caused by organizational and technical obstacles. It is especially visible in large teams and legacy projects. Nevertheless, by small incremental changes Continuous Integration which runs at full speed can be achieved. How to exactly execute such change is another topic for a few long posts. By now, check your CI practices, figure out which parts of it have some defects and check out with your team what you can do about them!

Share it!Tweet about this on TwitterShare on FacebookShare on Google+Share on LinkedInEmail this to someoneShare on Reddit