Real eXtreme Programming (XP) teams being true to their name and spirit, follow the Continuous Integration (CI) practice to the core. Let us explore the "10 Commandments" of the CI practices which the XP teams use to their foremost advantage.
1) No one checks-in on RED builds
A passing green build means the commit changes have safely integrated. A red build means the last change possibly did not get integrated as expected. When a build turns red, you need to stop all further check-ins that aren’t involved in fixing the builds to get it passing again. If you let more changes pile up, the time it will take to fix the build may increase drastically. Moreover, if the piled up changes or commits are also unstable, it will further complicate the process to fix the build.
2) Developers run tests locally
Unit tests should run on your local machine and the build server. Before checking in, a developer should run the unit tests to make sure he/she does not break anything. It leads to a more disciplined approach, firstly by making sure other developers are not affected when they may pull the unstable code-commits. Secondly, if the tests have executed locally the chances of build failures are less, assuring the other developers not being blocked from making their check-ins. Lastly, it leads to better build success rates and avoids build failures due to minor issues.
3) Builds are triggered on every commit
Builds triggers on every commit provide the developers with the most instant feedback possible. It means if the check-in has any issues, the developer can quickly fix it while there is a context of what he/she was working on. Also, the process of fixing the build is simplified as there are no check-ins over the unstable change. Many times, the builds are scheduled rather than being triggered on each commit. In this case, when a build failure occurs, the team has to scan through all the new change commits that were part of the scheduled build. Fixing such a build is a tough task as there could be multiple unstable check-ins, as well as it is not easy to make people accountable for lack of tech discipline.
4) Intermittent build failures are never ignored
Intermittent build failures may occur due to a few tests that arbitrarily (and not regularly) fail without any known reason. If such failing tests are ignored for long, the build will cease to be reliable. The team may also begin to conveniently ignore the failing builds even though for regular test failures. In actual, such test cases are marred by not having a clean and isolated execution environment, the few reasons of which could be dependent on non-empty cache-manager, global variables, system properties, date/time logic, etc.
5) Build environments are always stable
An unstable or inconsistent build environment may lead to random build failures and makes it hard to catch issues in the current change-commit. Competent XP teams not only focus on having a stable environment but also aim to create them consistently through automated scripts.
6) High Build Success "Rate" & Low Build Failure "Period"
The development teams strive for high build success rates and always aim to avoid making the builds red/unstable. Moreover, XP teams also strive for low build failure periods, which means fixing the red/unstable builds as soon as possible, leading to a limited period when the build was red/unstable. It helps to keep the team unblocked always.
7) Build jobs execute fast
If the build jobs take a long time to execute, one has to wait endlessly to commit his/her changes. Also, longer a process takes to complete more are its chances of failure. A long build execution time may become a big blocker more so when the developers recommend making frequent check-ins. Few steps to bring down the execution times could be by isolation from the dependent systems, pulling out integration and UI tests into separate jobs, working with test/stub data, visualizing downstream services, dividing jobs into stages (to pin-point failure reasons), etc.
8) DONE means green build
The XP development teams have green builds as part of their "Definition of Done (DoD)" criteria. No one calls their respective user-stories / tasks as complete until the build is green. It brings in a great deal of discipline, accountability, and transparency towards the code quality.
9) Only Build Artifacts are picked for Testing
It is despised to test or deploy artifacts from any place other than the build server. The build server acts as a single source of truth. The code is considered stable only when it successfully passes through the build and quality gates. It ensures the source code is checked-in, merged, stable, and works. It is considered not only for further automation/acceptance testing but also for manual testing.
10) Each member is aware of build configurations, with relevant access rights
It does not make a lot of sense to shun developers from triggering, monitoring, or configuring builds. It is the development team that owns its builds and has complete autonomy of it. If it is not the case, then the CI process may itself become an impediment and the team may not be motivated to follow it. Moreover, all the developers in the team are aware of the build configuration and its mechanism. It should not be the responsibility of a specialist or team lead to manage/maintain the build jobs.