fbpx
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

A Field Guide to Threat Vectors in the Software Supply Chain

A Field Guide to Threat Vectors in the Software Supply Chain

The software supply chain is made up of many integrated parts, people, and processes. The components range from tools and configurations to code libraries and systems. These components’ goals are developing and delivering software. Unfortunately, risks are high due to...

Related Resources

Demystifying Atlassian Cloud Licensing

Demystifying Atlassian Cloud Licensing

Understanding the intricacies of software licensing can be a formidable task.  Atlassian, a leading provider of collaboration and productivity software, offers a range of cloud-based solutions that cater to various business needs. This blog post aims to share...

The Business Case for Moving from ENOVIA to Windchill PLM

The Business Case for Moving from ENOVIA to Windchill PLM

With many PLM solutions on the market, it can be difficult to know which is best for your business needs. Dassault Systèmes’ ENOVIA is a popular choice as it is part of their 3DExperience platform. ENOVIA has the same goal as every PLM software which is to manage a...

A Field Guide to Threat Vectors in the Software Supply Chain

A Field Guide to Threat Vectors in the Software Supply Chain

The software supply chain is made up of many integrated parts, people, and processes. The components range from tools and configurations to code libraries and systems. These components’ goals are developing and delivering software. Unfortunately, risks are high due to...