10 Continuous Integration Practices

Continuous Integration is a process, not a set of tools, it is requires great amount of discipline from software development team members. The goal of Continuous Integration (CI) is to make sure that software is operational and working all the time. Another benefits are constant feedback for developers about software quality and their work.
In order for CI to be successful, some rules need to be followed by development team members:

  1. Don’t checkin a broken build
  2. Developer who broke the build are expected to stay and fix the build. Developer who broke the build has the best chance to fix it. If one of our colleague broke the build, he wants to see problem he introduced, without us checking in further changes, triggering new builds, and compounding the failure with more problems.

  3. Always run tests on your local instance before committing
  4. Committing is a form of publishing. Running the commit tests locally is a sanity check before committing to the action. It is also a way to ensure that what we believe to work actually does.
    Before committing, developers should update their local project from Version control Repository and then do local build and run tests. If test passed locally but fails on CI server, then developer probably forget to check in some new artifacts – classes, code, configuration data.

  5. Never Go Home on a Broken Build
  6. I remember one person on my team always was checking in just 1 minute before he headed to the door. More often that not, the build failed as a result of his checkin and everybody who stay could not commit or could not get feedback from CI server for their work. Commit early and often. Commit early enough to give yourself time to deal with problems should they occur. Alternatively, save your check-in for the next day; many experienced developers make a point of not checking in less than an hour before the end of work, and instead leave that to do first thing the next morning. This is especially important for globally distributed teams.

  7. Always Be Prepared to Revert changes to the Previous Revision
  8. If build is broken, it is important that we get everything working again quickly. If we can’t fix the problem quickly, for whatever reason, we should revert to the previous change-set held in revision control and remedy the problem in our local environment. After all, one of the reasons that we want a revision control system in the first place is to allow us precisely this freedom to revert. so learn how to revert changes.

  9. Time-Box Fixing before Reverting
  10. Establish a team rule: When the build breaks on check-in, try to fix it for ten minutes. If, after ten minutes, you aren’t finished with the solution, revert to the previous version from your version control system. Revert after 10 min passed and fix on your local environment.

  11. Don’t Comment Out Failing Tests
  12. Some developers in order to checkin their changes will comment out test code. If test that was passing start failing developers should figure out why. It takes time, but this is the only way
    to keep integrity and quality of the application. Test commenting should be used only as a last resort, for example, when having important meeting and demo with the customer. But then test should be running again. I saw projects where tests get commented out and never executed again. I saw test coverage drops from 80% to 50%. This is a very bad practice, defeating the purpose of continuous integration.

  13. Take Responsibility for All Breakages That Result from Your Changes
  14. If your changes broke the build you have to fix it. Sometimes you have to fix program written by another developer on the project. That why it is necessary for everybody to have full access to the whole code base of the project. If this is impossible, good communication and collaboration are in order to let other developers know how to fix the issue.

  15. Test-Driven Development
  16. Having comprehensive test coverage is nesessary for continuous Integration. Application is broken until you prove otherwise via tests. Aim for at least 80% test coverage. Without tests the only thing you get from CI is that your code is compile. For those not familiar with test-driven development, the idea is that when developing a new piece of functionality or fixing a bug, developers first create a test that is an executable specification of the expected behavior of the code to be written. Not only do these tests drive the application’s design, they then serve both as regression tests and as documentation of the code and the application’s expected behavior.

  17. Failing the Build for Slow Tests
  18. We want to encourage frequent checkins but If the commit tests take a long time to run, it can have a seriously detrimental effect on the productivity of the team because of the time spent waiting for the build and test process to complete. This will, in turn, discourage frequent check-ins, so the team will start to store up their check-ins, making each one more complex – with more likelihood of merge conflicts and more chance of introducing errors, and so failing the tests. All this slows everything down even further. you can test how long test takes and fail the build if some particular test runs too slow. This to force developer to rewrite the test.

  19. Failing the Build for Warnings and Code Style Breaches
  20. This is optional but highly recommended. Annoying at the beginning, but for to have a good style for application maintability. Checkstyle and findbugs are useful plugins for java developers.

    Continuous Integration is probably the best practice you can do to increase productivity of the team and quality of the software. There are many excellentCI packages available, from very popular open-source Jenkins to commercial Bamboo, TeamCity and others. Just pick up one and start doing CI for you project. you will be glad you did.

     

Submit a Comment

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>