The goal of the well-known mantra "release early and release often" is for us to create faster, higher-quality software that meets user expectations. However, managing software releases can be challenging.
In an efficient software release process, your development team deploys a new or modified version of a product while staying aligned around project goals and objectives. This helps ensure faster releases, a higher-quality product, and a better customer experience.
In this article, we'll walk through the high level of how to manage product releases across teams of different sizes. We'll cover product release lifecycles that are well-suited for small, medium, and even enterprise environments.
Why we care about product release processes
The product release process oversees all the stages of a software product’s release to market, from planning through deployment.
Release management helps the team stay on track as they work towards releasing a high-quality product to end users while staying within budget and time constraints. Techniques like agile development, CI/CD, DevOps, and release automation help optimize release management.
There are typically five primary steps to any product release lifecycle: planning, development, testing, preparation, and deployment which are outlined below.
Why are product release processes important?
Product release lifecycles can be beneficial in a number of ways. We've described a few of those in more detail below.
Increased productivity
A repeatable product release process can drastically improve productivity, communication, and team coordination. If teams have a standardized process to follow, everyone knows what to do and when. A documented, repeatable process also guides new team members on the release process and helps them get up to speed faster.
Requirements traceability
Release process management creates a single well-documented process that teams can follow for all releases. This ensures features are being developed according to the documented standards and requirements defined in the release plan. The requirements plan is also a good reference that QA can use to validate that the product has met the requirements and standards.
A standardized process creates traceable data for release activities that allow for audits of the release lifecycle to verify compliance and ensure consistent governance across releases.
Governance and oversight
Broken compliance or unmet governance and security requirements can result in serious security breaches and fines. A structured project release process allows organizations to implement and enforce governance policies across releases consistently to ensure better compliance and security.
More successful releases
Product release management improves productivity, coordination, and communication among teams, which results in higher-quality software. The team can consistently produce quality software with a shorter time to market, and the organization can be more responsive to market changes to deliver software faster at a decreased risk.
Managing product releases
At a high level, the release management lifecycle looks similar for all companies. Depending on the size of the company, though, this process can be adjusted to meet specific needs.
There are several types of release workflows to choose from. First, consider a simple workflow suitable for small teams.
Managing product releases in small teams
Small teams might not have the resources for a full-blown product release plan, and the focus might be mostly on the actual software release process. A release management checklist based on a well-known branching workflow might be all you need.
The trunk-based development (TBD) branching strategy supports a series of small, incremental commits made directly to a single main branch, called the trunk. TBD is simple and works well for small teams in which developers can easily communicate to ensure that they aren’t working on the same piece of code at the same time.
With TBD, developers write code in small, testable batches and commit to the trunk at regular intervals. They commit features to the main or use short-lived (meaning one or two days) local feature branches. All changes are logged in running history. TBD works well with CI/CD systems because commits are small and the trunk is always in a release-ready state, allowing for quicker releases.
Here are the steps for creating a trunk-based development branching strategy:
- Clone the trunk branch:
git clone <git-repository-url> - Create a new feature branch off the trunk. Using feature branches ensures the trunk is always in a deployable state:
git checkout -b new-feature-branch - Merge the feature into the main branch once it is complete, compiles, and passes all tests:
git push origin new-feature-branch - Create a pull request for code review.
- When the code is approved, create a release directly from the trunk or a short-lived branch created specifically for the release.
Maintaining a release-ready trunk is important in TBD. This means that developers must ensure that they are not sending incomplete features to production. Because of this, teams often use feature flags with TBD to decouple feature deployment from release.
Feature flags allow for the continuous integration of code, even when features are incomplete. Developers disable changes that are not ready for release by wrapping them in a feature flag. Once the feature is ready, the flag is turned on to make the feature available to users.
Feature flags can be deployed using configuration files, scripts, or from within the code using a simple “if” statement:
Managing product releases in medium-sized teams
There are a few workflows that can be used for mid-sized teams, including the previously mentioned TBD, GitHub Flow, and GitLab Flow. While TBD and GitHub Flow are best used with smaller teams, they can also work for medium-sized teams when creating SaaS products and other products that support continuous deployment and release.
The GitHub workflow is as follows:
- The trunk is always in a releasable state.
- Each developer creates a feature branch from the trunk to code their changes.
- Feature branches can be pushed to the trunk and deployed to non-production environments, or deployed directly to a testing environment.
- Releases can be done directly from the trunk, or a short-lived release branch can be used to deploy a release.
The most suitable workflow for medium-sized teams and projects is GitLab Flow. GitLab Flow teams cooperate and maintain different versions of software in multiple environments. This works well for feature-driven development, in which an agile framework delivers features in short iterations and frequent releases as part of CI/CD practices.
GitLab Flow uses the main branch along with feature branches, a dedicated production branch, and optional environment and release branches. Team members create feature branches from the main branch to work on code. When the feature is complete, a pull request is created. Once changes are approved, the feature branch is merged into the main branch. Depending on the setup, changes can be pulled from main directly to the production branch or through pre-production branches, such as staging or QA.
Here are the steps for creating a GitLab Flow:
- Create a feature branch from the main branch.
- When the feature is complete, submit a merge request for the main branch.
- After review and approval, merge to the main branch.
- Delete the feature branch.
- From the main branch, integrate through other environmental branches (if any) to the production branch.
With GitLab Flow, the main branch remains stable because development is being handled in branches separate from main and production. Teams can decide which bug fixes and features to move from main to production. Incomplete code is kept separate, and issues can be more easily tracked to a specific set of code.
Managing product releases in enterprise projects
Enterprise environments need a product release process that covers all aspects of project release management. A full-fledged product release process might look like this:
- Review planning and strategy to ensure that the team is aligned with defined goals and initiatives.
- Create a release definition to determine the delivery scope of the product.
- Define and prioritize the features and requirements to be included in the release.
- Develop key features.
- Launch planning to determine how to promote the product and encourage customer adoption.
- Run testing and QA to validate whether the product meets expectations or needs to be sent back to development. If approved, the product is prepared for release.
- Choose and implement a marketing strategy, including blog posts, email campaigns, and social media.
- Offer training and release marketing materials and support documentation, including release notes, how-to guides, and videos.
- Launch product to provide new functionality and features to end users.
In an enterprise environment, where the emphasis will more likely be on maintaining an established product than on speed, a more fault-tolerant branching strategy may be used. The GitFlow workflow works well for large projects where you need more control over what you release and when. This branching strategy has two main branches—main and develop. Other supporting branches are used to enable parallel development and are usually short-lived:
- Feature branches: These are branched off the development branch when a new feature needs to be created.
- Release branches: These are created from the development branch to prepare for a new release, then merged back to both development and main when complete.
- Hotfixes: These are release branches created for bug fixes discovered in production. They allow developers to keep working on features while the bug is being fixed.
How GitFlow works
- Feature branches are created from the main branch.
- Once features are complete, developers create pull requests for other developers to give feedback on the changes.
- Once changes are agreed on, the pull request is accepted and released to the main branch. Developers can continue to work on new features in the development branch.
- When the main branch is ready for release, a separate branch is created for the final version.
- Testing and bug fixes are handled on this branch until it is ready to be released to end users.
- Once done, the final release branch is merged with the main branch and tagged with the release version.
- Hotfix branches are branched off from the main branch to fix bugs in production releases. Once complete, they are merged back to the main branch and tagged with an updated version number.
- To ensure that the fix is included in subsequent releases, the hotfix is also merged back into the development branch.
Feature flags can also be used with GitFlow to release features to a subset of end users. This allows you to observe and gain feedback on how the features function in the production environment.
Getting started
Many tools are available to help you simplify and speed up your product release lifecycle. For instance, Airplane is a developer platform that allows engineers to create internal workflows for multi-step operations and long-running processes. In Airplane, every task is represented as a single atomic operation.
Airplane’s runbooks feature allows you to combine multiple tasks to create a powerful multi-step workflows. You can also toggle feature sets on and off without needing to manually update configuration files. If you’re looking for a way to simplify your product release process, sign up for a free Airplane account and try it out.
Author: Deborah Ruck
Deborah Ruck is a software developer with 20+ years of experience. She enjoys creating engaging, well-researched, and educational content tailored to software engineers.
