- Every time that somebody commits any change, the entire application is built and a comprehensive set of automated tests is run against it. If build or tests fail, the development team stops and fixes it immediately.
- The goal is that the software is in a working state all the time.
- Check In regularly so that changes keep small and less likely to break the build.
- Use proper log descriptions on check ins.
- Never Check In a Broken Build as that breaks the continuous integration.
- Always run all Commit Tests Locally before Committing or get your CI (Continuous Integration) Server to do it for you.
- Wait for Commit Tests to pass before moving on. If commits are done frequently any crash should be a small piece to fix, if left unbroken, code will become more and more unstable, better to fix it as soon as it crashes.
- Never go home with a broken build (try to avoid this even if you need to revert so you can try to commit next day).
- So, always be prepared to revert to Previous Revision.
- Don’t Comment out Failing Tests.
- Take responsibility for all breakages that result from your changes.
- Be warn if using branches, as they don’t allow developers integrate their code to common version and long-lived big branches will face same problems as non-continuous Integration. Use them when appropriate and don’t let them live long.
- Create a Comprehensive Automated Test Suite to provide confidence that the application do not only compiles but also works. This suite should include Unit Tests, Component Tests and Acceptance Tests.
- Keep the Build and Test Process Short, or else people will not be able to do small commits with build + testing, plus there could be more commits in the middle if it takes too long making it hard to know which commit made it crash.
- Store everything on version control, so that deploy a version of the project doesn’t require any config file, library or documentation which state during that version you can’t know.
More on the book Continuous Delivery.