Continuous Integration

Continuous Integration means that we automatically rebuild the entire project and run the unit tests every time a developer checks source code in to the project's Subversion repository.

More information and the current status of the builds on the integration server is at  http://geocraft.org/metrics.htm

Introduction

When people first hear about continuous integration they usually freak out and hate the idea.

Martin Fowler explains it much better than I can:  http://martinfowler.com/articles/continuousIntegration.html

Subversion

Another shock to the system is using a non-locking source code control system.

Traditionally we all though that you had to checkout a file, hold on to a lock, make your changes and then commit. This was bad because it meant that you had to divide the code base into separate areas for each developer. If you found a bug you needed to persuade the 'owner' to release the lock so you could make a change. With this approach there is not much incentive to check in your changes any time soon. After you got back from vacation would be soon enough. This leads to nightmare integration sessions at the end of the release cycle as everyone tries to get their work into the repository.

With an optimistic scheme though you don't 'own' any of the files. The first one to checkin has an easier time which encourages people to make small changes and commit frequently. Once an hour is not unreasonable. As long as you keep your local repository up to date you can still hold off checking in but there is no benefit to you delaying it. If you don't update often enough then sooner or later you will find that someone else has edited the same file as you in a way that cannot be automatically resolved. They checked in first so now you will have to resolve the problem. This is a complete and utter pain for you. We understand because we have all been in 'merge hell'. Your suffering is good for the team though because next time you will not try and make such large scale changes and will checkin your work more frequently.

Using an optimistic merge scheme means that we have to be consistent with code layout. We have configured Checkstyle so that it will complain if you use tabs in your code. And we all use a 2 space indent and put the braces in the same place. This makes it much less likely that there will be merge problems that we will have to manually resolve.

See also SubversionNotes

Typical Development Sequence

• checkout or update the code so that you have all the latest changes
• check if the build is broken -  http://geocraft.org/metrics.htm
  • if it is, then your time may be more usefully spent fixing it
  • don't pile more new code on top of an unstable code base
  • alternatively email whoever checked in last and ask them to fix it
• start hacking/coding/test driven developing etc.
• update from svn regularly
• as soon as you get to a suitable stable point
  • check the code compiles
  • check the tests compile and run
• commit your changes
  • don't forget to commit the unit tests as well
• if you can't get to a stable point then don't commit.

Wait for 10-15 minutes until the continuous integration build completes. If it takes longer than that then complain on the mailing list.

• check your email or the  metrics to see the current status
• if the build failed then check the  metrics page
  • either the source code did not compile
  • or the tests did not compile
  • or the unit tests failed
  • now either revert your changes from the repository or start work on fixing the build
    • don't just go home and leave it broken :-)
• if the build succeeded then check the  metrics page
  • if your checkin created any lint in the main source code or the tests - fix it
    • if you don't fix it someone else will and their changes may put you in merge hell.
  • did your checkin have any checkstyle errors?
    • if so, fix them before you end up in merge hell
  • at this point the unit tests worked or the build would have failed
  • review the code coverage on your changes.
    • gui code is hard to test but the algorithms and framework classes should be testable
  • check the code coverage page to see if you made it into the Project Risks list
    • if so, consider refactoring / redesigning your code
  • review the javadoc
    • whatever you added to the source code is invariably going to need to be polished
  • finally check there are no javadoc errors

That is the end of one cycle of coding.