What is Continuous Integration & Continuous Delivery?

Continuous integration (CI) allows development teams to make changes safely, because a series of automated tests are executed each time a developer attempts to change the codebase – with a push request, for example. These groups, or suits, of tests, are also written by the development team – ideally in advance of the core product code. These tests run against the code as if the proposed change had been accepted and alert the development team before any new code with breaking changes has been introduced by accident.

CI is a safe, reliable way for development teams to make changes to an application’s codebase. Most developers consider it essential because, without it, they wouldn’t know if their newly written code was going to break existing functionality in their app until after that new code had been added. That is, they would have to break the application to find out if they were going to break the application, which is not a very efficient way of going about writing software.

CD is an abbreviation that is used interchangeably for both continuous delivery and continuous deployment. In the iOS development space, CD generally refers to continuous delivery – a system by which newly built code is shipped to a QA or staging environment – as opposed to continuous deployment, which ships all newly built versions of the application directly to production for end-users to consume.

In either case, CD is the parallel, automated system by which the code that has been integrated via CI processes is moved further down the path to delivery to end-users. For iOS applications in particular, this generally means shipping code to an intermediate environment prior to publishing an updated version of the application to the Apple App Store.

CI/CD is the combination of these two interrelated, but distinct operations within a single, automated pipeline or workflow.

One step forward, no steps back

Writing complex code is a messy affair. Oftentimes relationships between different portions of an application’s codebase aren’t obvious, which is generally what allows bugs to be introduced. A change to one portion of the app is made, and at first glance, everything seems to be working as expected. But some hidden interactions are taking place deep within the code that can impact the performance of other portions of the app. Left unchecked, this can lead to a break and fix pattern of development that stalls out of the larger development life-cycle. After all, there are few tasks more time-consuming for a developer than hunting for bugs.

CI/CD is the industry standard solution to this problem. When development teams write software, they are incrementally adding and removing bits of code from an existing codebase in order to add new functionality to an application, fix bugs, or otherwise improve the app. CI/CD allows development teams to test these proposed changes before they are committed to the codebase. This allows teams to make steady, forward progress on development goals by enormously reducing the risk of introducing bugs that are time-consuming to find and fix.

CI/CD masters and agents

In order to execute a CI/CD workflow when new code is committed to a repository, some mechanism needs to watch for changes to the repo. This functionality can be built into the platform that is hosting the repository, such as GitHub Actions in the case of GitHub. Alternatively, a third-party master can be stood up and pointed at the repository, as would be the case with a team using Jenkins or a similar tool.

When this master detects a change to the repository, it passes the newly written code, along with the associated test suite, to a separate server that is acting as a build agent. This agent could either be a physical or virtual machine, and it could either be stood up indefinitely (static) or a new agent can be spun up by the master each time the workflow runs (ephemeral).

Unlike the master, the agent isn’t responsible for watching any external resources. Rather, it is solely responsible for executing the workflow that the master assigns to it with the resources that the master provides it.

Optimizing CI/CD pipelines and workflows

When teams set out to incorporate CI/CD into their development life-cycle, the first goal is simply to get it to run as intended – that is, reliably execute the test suite associated with the codebase each time a developer requests to make changes to the repository. Once this is accomplished, there are some high-value optimizations that teams generally target next.

Ephemeral CI/CD

Ephemeral CI/CD, which involves the spinning up of a new VM on each workflow run, is the gold standard for iOS development. This approach allows for a known baseline environment for every workflow run that is executed, which eliminates the risk of incremental changes being made to the build environment that can undermine the reliability of builds and tests.

MacStadium offers three virtualization layers that each run on certified Apple hardware in the cloud. This means that your team should be able to continue to use the tooling they are accustomed to – be it containerization tools like Docker, or VM-specific tooling such as VMware offers – as you move your iOS and macOS CI/CD operations to the cloud.

Optimizing for performance

CI is only as effective as the tests that it executes are good. So, the initial optimization teams often look to in new CI/CD workflows is the tests themselves. In particular, identifying and fixing any flaky tests – those that sometimes pass and sometimes fail – will go a long way toward improving the trustworthiness of your continuous integration testing.

Speed of execution is also a high-value target for optimization. The faster the workflow executes, the less time the development team has to wait before returning to writing code. This carries a variety of benefits that range from a happier development team to a faster application release cadence – all of which boil down to a competitive advantage in this competitive marketplace.

Takeaways

CI/CD is a safe, efficient way for development teams to incrementally improve an application and to share that improved application with end-users. It is often described as consisting of a workflow or pipeline because there is a predetermined series of steps that are carried out each time a developer tries to add new code to an application’s codebase. These steps serve to ensure the quality of the code via automated testing and to distribute newly updated versions of the application to consumers.