1-888-310-4540 (main) / 1-888-707-6150 (support) info@spkaa.com
Select Page

Continuous Integration Best Practices—Part 4

As I noted in other articles in this “Continuous Integration Best Practices” Series (click here for Part 1, Part 2, or Part 3“, there are 10 best practice principles associated with Continuous Integration and in this previous articles, we covered the first eight. In this article, we pick up where we left off and talk about principles nine and ten.

For review, the full set of principles are outlined below:

1) Maintain a code repository
2) Automate the build
3) Make the build self-testing
4) Everyone commits to the baseline every day
5) Every commit (to baseline) should be built
6) Keep the build fast
7) Test in a clone of the production environment
8) Make it easy to get the latest deliverables
9) Everyone can see the results of the latest build
10) Automate deployment

9) Everyone can see the results of the latest build

In its most basic form, this principle could look like an email report that’s delivered to all relevant parties following the completion of a build. This is not an ideal solution because it limits the audience to those in the mailing group. Additionally, there is an almost certain chance that the majority of people will quickly tune out due to the volume of reports coming their way.

Email reports may be a necessary first step when implementing a CI system, but a better option is a web-based dashboard that allows interested viewers access and the ability to examine aggregate metrics as well as drill down to individual builds and their constituent steps. Once a suitable dashboard is in place, the email reports can be dispensed with and users should only see items in their inbox that are notifications alerting them to critical events or requesting some action on their part.

10) Automate deployment

When complete, a build should automatically deploy into a production-like environment or set of environments. Following this principle forces several things to be true. First, it forces you to crystallize your understanding of your deployment process. By automating the process, you strip out any reliance on “tribal knowledge” that only your deployment guru has and forces it into the open where the process can be explicitly documented and accounted for.

Secondly, in order to satisfy principles 6 and 7, the process of deployment cannot be manual. Automating the deployment process is the logical consequence of those two principles. Being forced to test in a production-like environment and to make the whole process as fast as possible rules out the use of manual deployments – they must be automated to keep things moving.

David Hubbell
Software Engineer
SPK and Associates

Next Steps:

Latest White Papers

The Next Chapter of Jira Service Management

The Next Chapter of Jira Service Management

The service industry is only becoming more competitive as the years pass, making efficient delivery vital to success. Development and Operations teams need to work together to deliver aid and Jira Service Management can help achieve this. Explore the future of Jira...

Related Resources

Simplify Your Confluence Workflows with Integrated Approvals

Simplify Your Confluence Workflows with Integrated Approvals

As organizations continue to seek the most efficient solutions for increased compliance, new apps and add-ons have emerged on the market. AppFox is a leader in this field, creating add-on applications for increased capabilities. For businesses that currently use...