How many releases have you been a part of that ended with the team and management feeling miserable? I can imagine at least a few — and the process behind it is usually the reason!
When I first started my role as the Head of QA & Release at Bragi, I was given the task to track all of our releases in one place — from the very first firmware created to the moment the customer gets the full package.
The roles and responsibilities were already set, with me acting as a release manager, so it was a job partially done. I built upon it by creating a one-stop shop for all information, supported by an embedded calendar showing the schedule of the current month at a glance, which also included test reports shared via Qase public links all in one place.
From there, a weekly call was scheduled, which gathered all the stakeholders for a 30-minute sync — that way everyone could get full visibility on the current state of all the releases across our company. While there are always ups and downs, after these years I feel like we are in a much better position.
I’d like to share some of my personal knowledge and learnings that I gained in my role over the years so that you can use them to craft a better process for yourself.
The process
A software release process is a series of steps and procedures that guide the whole SDLC — development, testing, deployment, and maintenance — of software products. It ensures that development is efficient, meets quality standards, and is deployed/delivered in a controlled and reliable manner. It is like a roadmap that shows how a piece of software goes through the entire SDLC flow.
But enough boring terms, let’s get to the interesting part!
Key components of the process
A good, well-structured software release process helps deliver high-quality software efficiently. It usually consists of five parts.
- Planning is the initial phase where the groundwork for the entire process is laid. This involves defining scope and objectives, the release schedule, resource and budget allocations, and risk assessments.
- Development is when the actual software gets created. It includes requirement analysis, coding, version control, and continuous integration.
- Testing includes unit testing, integration testing, user acceptance testing (UAT), automation, and manual testing. This step is crucial for ensuring that the developed software functions in a way that users would expect it to.
- Deployment is the process of moving the created piece of software from development to testing, and then to the production environment. The deployment phase should include strategies for release times (for example, releasing outside of peak usage periods) as well as a rollback plan in case anything goes wrong.
- Monitoring/feedback is essential for maintaining and improving the software after the release is done. This includes monitoring, incident management, and user feedback.
Building the process
Now let’s design a process that you can use in your company. First, we must define the objectives and requirements. Doing so helps us understand why this process is so important and helps us gather feedback from key stakeholders.
Objectives might include:
- Delivering on time
- Delivering with high quality
- Mitigating risks
However, objectives and requirements will differ from company to company and project to project.
Establish roles and responsibilities
Without clearly defined roles and responsibilities, nothing will move forward. For example, you may need release managers who will monitor and update internal documentation to keep stakeholders updated and testers who provide test results with each release. Meanwhile, developers may need to produce clear changelogs and maintain pre-defined versioning and clients would need to provide requirements in a timely manner.
Define tooling
After the responsibilities are set, tooling needs to be defined to support the established goals. For instance, in our process, having a quick way to access the test results for the whole company was one of the most important features of a test management system. The QA department stays transparent as anyone can take a look at the results by simply logging in via SSO or using public reports — which can be accessed without logging in or even embedded as iFrames on the respective Confluence pages — all of which are features available in Qase.
In contrast, a closed system that does not provide everyone with access or an easy way to share reports will lower confidence in the quality of the software. Other tools that can be defined are CI/CD systems or version control systems.
Create a workflow
We have our objectives, roles, and tools — now it’s time to define the workflow. We’ll cover defining requirements, refining the story, planning the sprint, developing the code, testing, and then deployments. But we’ll also need to include check-ins from release managers, act on blockers quickly, and set clear expectations for communication about possible delays. Having a clear structure for testing helps tremendously and can help maintain high quality without introducing unnecessary regressions.
Mitigate risk
While everything looks great on paper, every project comes with risks — and those risks need to be mitigated. Whether it be planning for a resource shortage during the summer holiday months or having a backup plan if the delivery is made late on a Friday afternoon, it’s critical to identify these potential risks and have a plan B for everything.
For my team, that means:
- Holiday peaks (happening around summer and Christmas) are measured and we add a buffer to the releases happening in these periods.
- New projects that launch with a limited amount of hardware are pre-planned in terms of who gets the devices first, or they are set up in a remote environment where they can be used as a shared resource. We also always keep one device in the on-site office so on-site resources can support testing without needing to ship the devices back.
- Issues that cannot be found using structured testing (think “stream music for 8 hours straight”) are picked up by dogfooding, beta testing, and crowdtesting activities.
Define KPIs
This is not a strict requirement but it helps us see if the process needs further refinement. If there are issues leaking into production at an alarmingly increasing rate, that’s a sign something needs to be reviewed in the development and testing stages. If all the projects are suddenly getting delayed, maybe there’s an issue in the planning department. A sudden downtime of a key system — like the remote-testing environments mentioned above — might hinder the team’s ability to deliver on time. Having KPIs helps improve the process in the long-term.
Document the process
Now that we are getting to the end of defining the process, we need to get it documented. With all the expectations, roles, and tools, it’s easy to get lost in the details. A simple documentation page, even structured just like this article, should be enough for anyone to pick up and get up to speed on the process. It also helps the person in charge — like a release manager — take their holidays without having to hop on a call to quickly support unknowns.
Common challenges
While establishing a great process is crucial, there are always uncertainties and unplanned changes that can break the best process out there. These include:
- Integration issues: Two parts of the software may work fine separately but reveal a multitude of issues when integrated. It’s best to plan for this and set aside additional time for possible required bug fixes.
- Last-minute changes: When suddenly a missed requirement is uncovered by the end of the deadline, but it cannot be pushed – then a switch of priorities is required. Tools like crowdtesting, which are not constrained by regular business hours, can come in handy!
- Resource constraints: Ideally, you’ve planned ahead for resource constraints, but there’s not always a way to plan for something like flu season putting half your team on sick leave. Reprioritizing or trying to push the release further out is the best solution as pulling in new engineers at the last minute can sometimes do more harm than good.
Creating a process is an investment in quality
While integrating a release process seems tedious, it usually takes a lot of stress off the team and release manager in the long run. Making it right from the start will save a lot of time. I encourage everyone to try the given approach at your own company and make everyone's lives easier!
