🧠 Knowledge Series #29: How does the release process work?

Pipelines, builds, Jenkins, Docker, continuous integration and more explained

🔒The Knowledge Series is a collection of easy to read guides designed to help you plug the gaps in your tech knowledge so that you feel more confident when chatting to colleagues. Clearly explained in plain English. One topic at a time. 

If you’re a free subscriber and you’d like to unlock them you can do so below. Or you can learn more about what you get with paid access here.

---

Hi product people 👋,

There’s an unwritten rule we all follow in product development. And that rule is to never release on a Friday. 

But on the days where releases are allowed, how do they work?

In this Knowledge Series, we’ll explore what exactly happens when a new feature gets released along with essential terminology like continuous integration, release pipelines, canary releases and more so that the next time you find yourself in a discussion about releasing to production you’re able to follow - and contribute - to the discussion.

Coming up:

• The key steps involved during the release process explained

• Release process strategies: canary releases, green and blue releases and others

• How continuous integration, deployment, “builds” fit pipelines into the release process

• How feature flagging works

• Tools and processes you can use

---

The Knowledge Series

The key steps involved during the release process explained

If you’ve worked in multiple different tech companies, you’ll know that the release process can vary greatly depending on the company.

Some companies have such excellent DevOps that they’re able to push to production multiple times a day but for others, the release process can take months. I once worked on a 3 month project for a large ecommerce business and was shocked to learn that everything I’d worked on wouldn’t get released until after I’d left!

The most common deployment frequency, though, is once every few days:

Whatever set up you have in your business, the release process typically includes a cycle comprising the following steps:

1. A feature is developed

2. Code is review and the feature is merged to main branch

3. Deployment to production

4. Post production monitoring 

We’ll use this cycle to help us structure this guide.

What happens when a feature is being built? A quick recap

This is the stage that non-technical members of the team are perhaps most familiar with: a new feature is scoped out and understood by everyone before an engineer picks it up.

Once the ticket or story is prioritised, the next step for the engineer working on the feature is to create a new branch. 

Branching setups vary greatly between companies, but one of the most common ways product teams build features is to create a branch in git for a specific feature, like this:

In this example, the command git checkout -b feature/XYZ-1234 is used in Git for creating a new branch and then immediately switching to that branch. Here's what each part of the command does: