Ephemeral vs Static Build Agents for iOS CI

Difference Between Static or Ephemeral

Within the world of continuous integration (CI) there are two fundamental camps. On the one hand, you have teams that favor the simplicity of setup and maintenance. And on the other hand, you have teams that are less concerned about the complexity of the CI system than they are about bulletproof confidence in the trustworthiness of a given build.

The first camp mentioned will likely favor a system designed around static build agents (Team Static). The second will almost certainly prefer an ephemeral CI system (Team Ephemeral). We’ll explore what might motivate a team to make one choice over the other, as well as some challenges that these different teams may face.

Generally speaking, a CI system that is founded on single-use VMs – that is, those that are spun up, used once and then torn down – offers the most trustworthy test results. This is the essence of an ephemeral, which is just a nice word for “temporary” or “short-lived,” CI system. The benefit of this approach is that there is no question as to the consistency of the build environment, because literally everything there is freshly installed every time it is used, and then it is thrown away.

This approach requires the creation of additional assets to automate this, often referred to as  “infrastructure as code.”  The “infrastructure” can exist with virtualization, such as inside a VM, and used by, say, a Jenkins file or an Ansible script. This is not the only infrastructure-as-code option, and many companies will write code to re-provision and connect VMs as if they were static on a less regular basis (such as weekly). The big difference with static VMs is this step is optional and can be ignored for a faster time to market.

Costs and Benefits

The cost of increasing the trustworthiness of a given build in such a way comes with the increased complexity required to stand up and maintain such a system. To illustrate this, let’s take a quick look at the alternative approach – i.e. doing CI with static build agents.

With static agents, there are no VM spin up and tear down stages. This means that nothing that makes those “spin up and tear down stages” work in an ephemeral system needs to exist in a static system,  leading to increased simplicity. Suddenly, it’s just a server like any other, listening on a given port for instructions from the orchestration server – i.e. the Jenkins master.

The problem that teams face with this approach is that loads of processes are running on the static agent, and because of that, it's very difficult to know that a particular system hasn’t been changed somehow along the way. And, maybe the most important factor – test results that aren’t totally trustworthy aren’t worth much in the end.

The general solution to this problem is an ephemeral system, which will require the following high-level components:

1. An automation server – let’s call this a Jenkins master.
2. VM images that define the ephemeral agents.
3. A place to store said images.
4. A virtualization layer on which to spin up the ephemeral agents.

Clearly, there is far more going on here, which means there will be a greater cost associated with setting up and maintaining such a system, largely due to the increased technical skillset required to execute this approach.

Takeaways:

There isn’t a right way to do CI, but there are established ways to do it. And teams that do CI can be divided into two fundamental groups – those who do whatever it takes to get reliable tests, and those who are comfortable with a less reliable test for a reduction in the overhead required.

The right choice for your team will hinge on your team’s goals and resources. Need help deciding what is best for your team and CI workflow? Our sales engineers are available to help.

‍