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 |
