Best Practices: CI Patterns and Anti-Patterns

Here is the summary of all CI patterns and anti-patterns as mentioned in this article. Refer to the link for a more detailed explanation of these.

Build Software at every change

Pattern	Run a software build with every change applied to the Repository.
Anti-patterns	Scheduled builds, nightly builds, building periodically, building exclusively on developer's machines, not building at all.

Task level commit

Pattern	Organize source code changes by task-oriented units of work and submit changes as a Task-Level Commit.
Anti-Patterns	Keeping changes local to development for several days and stacking up changes until committing all changes. This often causes build failures or requires complex troubleshooting.

Label build

Pattern	Tag or Label the build with unique name so that you can refer to run the same build at another time.
Anti-Patterns	Not labeling builds, using revisions or branches as "labels."

Automated build

Pattern	Automate all activities to build software from a source without manual configuration. Create build scripts that will be executed by a CI system so that software is built at every change.
Anti-Patterns	Continually repeating the same processes with manual builds or partially automated builds requiring numerous manual configuration activities.

Pre-Merge build

Pattern	Verify that your changes will not break the integration build by performing a pre-merge build—either locally or using Continuous Integration.
Anti-Patterns	Checking in changes to a version-control repository without running a build on a developer's workstation.

Continuous feedback

Pattern	Send automated feedback from the CI server to development team members involved in the build.
Anti-Patterns	Sending minimal feedback that provides no insight into the build failure or is non-actionable. Sending too much feedback, including to team members uninvolved with the build. This is eventually treated like spam, which causes people to ignore messages.

Expeditious fixes

Pattern	Fix build errors as soon as they occur.
Anti-Patterns	Allowing problems to stack up (build entropy) or waiting for them to be fixed in future builds.

Developer documentation

Pattern	Generate developer documentation with builds based on checked-in source code.
Anti-Patterns	Manually generating developer documentation. This is both a burdensome process and one in which the information becomes useless quickly because it does not reflect the checked-in source code.

Independent build

Pattern	Create build scripts that are decoupled from IDEs, but can be invoked by an IDE. These build scripts will be executed by a CI system as well so that software is built at every change.
Anti-Patterns	Relying on IDE settings for Automated Build. Build cannot run from the command line.

Single command

Pattern	Ensure all build processes can be run through a single command.
Anti-Patterns	Requiring people or servers to enter multiple commands and procedures in the deployment process, such as copying files, modifying configuration files, restarting a server, setting passwords, and other repetitive, error-prone actions.

Dedicated resources

Pattern	Run master builds on a separate dedicated machine or cloud service.
Anti-Patterns	Relying on existing environmental and configuration assumptions (can lead to the "but it works on my machine problem").

Externalize and tokenize configuration

Pattern	Externalize all variable values from the application configuration into build-time properties. Use tokens so the build process knows where to add variable values.
Anti-Patterns	Hardcoding values in configuration files or using GUI tools to do the same.

Scripting database changes

Pattern	All changes made to a database during development should be recorded into database scripts that can be run on every database on every platform hosting the project (including developer machines, see below).
Anti-Patterns	Expecting database administrators to manually compare databases between platforms for changes, or to create on-off scripts that are only good for updating a single platform.

Database sandbox

Pattern	Create a lightweight version of your database (only enough records to test functionality) Use a command line interface to populate the local database sandboxes for each developer, tester, and build server Use this data in development environments to expedite test execution
Anti-Patterns	Sharing development database.

Update Scripts Stored In The VCS   

Pattern	Store the scripts for updating the database and its data in the version control system with the code and annotate appropriately
Anti-Patterns	Storing update scripts in an alternative location, i.e. a shared file server

Automated tests

Pattern	Write automated tests for each code path, both success testing and failure testing.
Anti-Patterns	Not running tests, no regression testing, manual testing

Build quality threshhold

Pattern	Notify team members of code aberrations such as low code coverage or the use of coding anti-patterns. Fail a build when a project rule is violated. Use continuous feedback mechanisms to notify team members.
Anti-Patterns	Deep dive reviews of every code change. Manually calculating or guesstimating code coverage.

Automated smoke test

Pattern	Create smoke tests that can be used by CI servers, developers, QA, and testing as a pre-check to confirm the most important functionality as they work, or before committing resources to a full build.
Anti-Patterns	Manually running functional tests. Forcing QA to run the full suite before every session Manually checking deployment sensitive sections of the project