The age of multi-month release cycles is coming to a close, and the movement of Continuous Integration (CI) and Continuous Delivery (CD) is taking its place.

CI/CD is ultimately about adopting a set of practices and tools to accelerate the deployment of software, from the moment its written, to the time it is live on a site.

The benefits of CI/CD are numerous:

• You can get to market with your initial idea or new feature faster
• The risk of any given deployment is smaller
• Because your team will be able to reliably ship code without manual intervention, they will feel more productive, professionally fulfilled, and ultimately happier

The touch-points in the CI/CD release cycle are numerous, and should be optimized individually to cut down cycle time as much as possible, so your team can deliver software faster, more reliably, and with fewer headaches.

Understanding continuous deployment

At its core, CI/CD is about increasing the speed in which software can be delivered to customers by automating the deployment of code while maintaining confidence in its stability.

Continuous Integration (CI) is the practice of continually integrating code into one shared repository, and ensuring that the code delivers the desired customer experience. Continuous Delivery (CD) governs how that continually integrated code is actually deployed in an automated fashion.

There are four essential ingredients for any successful CI/CD process:

1. Code is checked in as frequently as possible
2. Test coverage stays high
3. Tests are fully automated
4. Deployment happens without the need for human intervention

Maintaining a culture of CI/CD requires significant investment in process, an organizational commitment to velocity, and tools to facilitate each step in the code review review, CI, and CD stages of delivery.

The five ways to speed up your continuous deployment cycles

To increase the velocity at which you launch software, you should optimize every stage of the delivery cycle, from code review, to building and testing your code, to actually deploying the changeset.

Here are our five tips to shorten your cycles, starting with how you write code, and ending with how you deploy it.

Identify the minimum viable changeset

Keeping pull requests small both increases the speed at which they are reviewed, and reduces the risk associated with downstream failures.

• If your pull requests are massive, no one will want to review them. As such, writing smaller PRs decrease the "time-to-first-review" for each PR.
• Smaller PRs are easier to review, and so the "time-stuck-in-review" goes down the smaller the changeset.
• Large PRs that touch many parts of the codebase carry a larger risk of subsequent merge conflicts, as well as potential test failure.

Reduce time-to-discovery of pull requests

Code sitting in limbo carries a great cost. It slows down velocity, and discourages the writer of the code.

• To ensure PRs are reviewed promptly, adopt tools to surface accountability to the team. Pull reminders is a great way to surface PRs that need review, and notify team members in a public channel.
• Eliminate the bystander effect by adding fewer reviewers to each PR, so each reviewer feels more accountability for that review.

Automate your testing

Test automation is an essential ingredient to a well-running CI/CD process. Dependencies on manual QA or any sort of human intervention hold up deploys and defeat the purpose of continuous delivery.

However, if not implemented correctly, tests can hold up your deploys just as much as humans. Flakey tests caused by frequent changes to the site can lead to failures.

Ultimately, to maintain continuous deployment, you need high coverage, with flexible automated tests. You can't just have one.

Want better test coverage with one line of code?

Try walrus.ai – integration tests in one line of code, in plain English. We handle the rest.

Adopt a feature flag system

Feature flags are a great mechanism to test changes in production without rolling them out to all of your users at once.

• Create dynamic flags that deliver the new experience to people in your specific domain.
• Ramp up exposure of your updated experience over time in order to reduce the risk of your changeset even further.

Focus on production monitoring

CI/CD requires moving quickly and confidently. Automated tests help in terms of providing a layer of protection against a broken customer experience, but rarely can they catch everything.

• Identify key business metrics that reflect the true state of the customer experience.
• Make dashboards of key metrics publicly viewable, so if a deploy goes out that breaks the customer experience, you can catch it quickly.