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

Continuous Integration Best Practices—Part 1

Continuous Integration is a leading software development methodology whereby new development is constantly being submitted and tested against the main body of work. The goal being rapid feedback on incremental changes, resulting in lower maintenance costs and higher levels of code stability. The purpose of this article is to begin the process of examining the best practices associated with this particular development method.

There are approximately ten key principles, as 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

To begin, we will be looking at the first three of the principles.

1) Maintain a code repository

Having a version control system to maintain your code history is pretty par for the course these days. At this point, the issue is not simply having a repository, it’s how that repository is accessed and maintained. CI, as an ideology, is pretty opinionated about this matter. According to CI, there needs to reside a single, central repository, from which all checkouts and testing is done and to which all commits are pushed. The rationale for this is maintaining one single source of truth at all times and avoiding instances where a change works in a development environment but not production. This being the case, branching is discouraged – at least in the sense that CI does not want you to maintain parallel version of your code.

2) Automate the Build

In a CI system, builds should happen automatically when a developer submits their code, and as much as possible, should be free of manual steps. This is a prerequisite for points 3, 5, 6, and 10. Not only is this point important for the speed of the build process (which is arguably the reason for doing CI in the first place), but it imposes a standard of consistency and repeatability that is vitally important for ensuring quality and tracking progress.

3) Make the Build Self-Testing

If a build requires manual testing, then the build will be slow and the chances of errors sneaking through will also increase. Ideally, CI would prefer that all tests are run with every build, but the reality of the situation is that this is frequently not practical. In many cases it makes more sense to run the tests pertinent to the affected modules, aggregate a set of changes and then run that aggregate set through the full complement of testing. Fewer tests means a faster test execution time and quicker feedback to the developer while submitting batches of aggregate changes conserves organizational resources.

David Hubbell
Software Engineer
SPK and Associates

Next Steps:

Latest White Papers

Atlassian Cloud: Understanding Zero Trust Security

Atlassian Cloud: Understanding Zero Trust Security

Where To Start & Why It Matters What is the Atlassian Cloud Zero Trust Security model? Well, for decades, enterprise security controls were built to protect a large, single perimeter around a corporation. Often described as castle-and-moat security, This approach...

Related Resources

Use Nessus To Harden Your Cybersecurity

Use Nessus To Harden Your Cybersecurity

Cybersecurity should be baked into the onset of IT and product development processes. Additionally, treating cybersecurity as an afterthought opens your organization up to vulnerabilities and risk. Therefore hardening your IT product cybersecurity with a tool like...

2022: The Year So Far Tech Review

2022: The Year So Far Tech Review

There’s been a lot of innovation, software and product releases in the past six months alone. So, we are rounding up the best tech review and engineering releases for the first half of 2022. The tech forecast for 2022 was heavily influenced by how the world adjusted...

CloudBees SDA:  Software Delivery Without Silos

CloudBees SDA:  Software Delivery Without Silos

Tired of missing deadlines, and only measuring performance of departments, but not of your entire software delivery organization? This blog will show you how CloudBees Software Delivery Automation (CloudBees SDA) can break down silos, drive DevOps mentality and...