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

Three Trends Are Transforming The Service Desk

Three Trends Are Transforming The Service Desk

Your IT service desk is about to change. Find out what's shaping the future. Three factors — enterprise service management (ESM), collaboration, and intelligent service management — are driving the transformation of the service desk. To better meet customers’ needs...

Related Resources

Extending CloudBees SDA Analytics

Extending CloudBees SDA Analytics

CloudBees SDA Analytics has more power than you think One of the main features of CloudBees SDA is CloudBees Analytics, powered by ElasticSearch. It’s a powerful tool for displaying continuous integration data and there are loads of useful metrics available from...

Is The IT Department Really “Dead?”

Is The IT Department Really “Dead?”

“It’s Time to Get Rid of the IT Department.”  That was the title of an opinion piece recently published in the Wall Street Journal.  Provocative?  Sure.  My answer to this is not “yes,” but many of the author’s points are valid.  The Same Old IT Department? No, the IT...

How To Add More Disk Space To Your Redhat Server Without Reformatting

How To Add More Disk Space To Your Redhat Server Without Reformatting

(Originally published in 2012, updated January 2022.) One of the common tasks for any system administrator is managing disk space on a server. A common question is how to increase disk space on a linux system. I won't go into a boring lecture on why managing disk...