What to Do When Merging Faster than Your Continuous Deployment Process

What to Do When Merging Faster than Your Continuous Deployment Process

Published on 

by Dan Manges

CI/CD platforms offer concurrency controls to limit the number of simultaneous jobs that can be running. This is useful for feature branches; when an engineer pushes a new commit, if a build was running on a previous commit, it can be cancelled. It's also useful for continuous deployment to make sure only one deployment happens at a time. Effectively, concurrency controls provide a lock around the deployment process.

Although locking is an effective solution to ensure that only one deployment is happening at a time, it can also create a backlog. If multiple engineers merge pull requests at the same time, deploying them all sequentially may take a while. If an engineering team is big enough, there is potential to create a very large backlog.

We considered these use cases when designing concurrency pools in Mint and added some options that most other CI/CD platforms do not have.

Cancel Waiting

In the Continuous Deployment use case when multiple commits are merged in rapid succession, rather than creating a backlog of deployments, a reasonable solution is to skip deploying the earlier commits and only deploy the most recent one.

You can easily do this in Mint by configuring the on-overflow behavior to cancel-waiting

1
2
3
4
5
6
7
8
9
on:
  github:
    push:
      if: ${{ event.git.branch == 'main' }}

concurrency-pools:
  - id: your-org/your-repo:main
    capacity: 1
    on-overflow: cancel-waiting

Cancel Running

For CI builds on feature branches, it's more common to cancel any in progress runs. You can do this in Mint by configuring the on-overflow behavior to cancel-running

1
2
3
4
5
6
7
8
9
10
11
on:
  github:
    push:
      if: ${{ event.git.branch != 'main' }}
      init:
        branch: ${{ event.git.branch }}

concurrency-pools:
  - id: your-org/your-repo:branch-${{ init.branch }}
    capacity: 1
    on-overflow: cancel-running

Queue

Although it's not used as commonly, Mint also offers another configuration option for when you do want to run everything sequentially without canceling any in progress or waiting runs. In this scenario, you can configure the on-overflow behavior to queue

1
2
3
4
5
6
7
8
9
on:
  github:
    push:
      if: ${{ event.git.branch == 'main' }}

concurrency-pools:
  - id: your-org/your-repo:main
    capacity: 1
    on-overflow: queue

More Flexibility

We've designed Mint to be as flexible as possible to accommodate a wide variety of use cases. A few additional configuration options are available that most other CI/CD platforms do not provide.

You can configure the capacity on the pool to allow more than 1 concurrent run.

concurrency-pools accepts an array, so you can have more than one pool apply.

You can configure an if condition on the pool to determine whether it should apply for the run.

For more details, see the documentation on concurrency pools.

Follow Along

We write a lot about software engineering best practices, CI/CD pipelines, and Mint. Follow along on X at @rwx_research, LinkedIn, or our email newsletter

Enjoyed this post? Share it!

Never miss an update

Get the latest releases and news about RWX and our ecosystem with our newsletter.