We eagerly await the 22nd of each month, because we get to share the hard work of our team and community with our users. Our release schedule illustrates our belief in the importance of velocity and our commitment to delivering value in the form of features. Monthly releases might seem aggressive to outsiders, but we believe our ability to deliver features quickly is a competitive advantage that has helped us find success.
Three cheers for a monthly release cycle!
A monthly release cycle is great for users, because it adds value at a predictable pace. Most of GitLab's installations are self managed, helping users identify when new functionality will arrive. As a user, you can look forward to the 22nd of every month, knowing that's when new features become available.
A predictable schedule helps with planning team capacity
The team has also found that it's easier to determine how much capacity we have when we're planning our workload, because there's no need to agree on deadlines. GitLab team-members know exactly how many days they have to work on something, and we can plan in advance. Working with such a short timeframe forces us to build features as small as possible. We can't say, "I need two releases for this," so we have to really think about how we can make a feature smaller, an idea that's reinforced by our iteration value.
"Sometimes, team members will propose having longer release cycles, because we'd be able to fit more into it, or we'd be able to do better quality control, but I think that's short sighted. It's true that in a longer release cycle, you can fit more in, but that will require bigger steps, and we know that iteration is what makes us achieve velocity. So, the smaller the steps we take, the faster we can go and the easier it is to do quality control. We think a monthly release cycle is the optimal frequency." -- Sid Sijbrandij, GitLab CEO
Challenges posed by monthly releases
It's not always easy to stick to the plan
It's not all sunshine and rainbows. While we're strong proponents of the monthly release, we realize that there are quite a few challenges. A few of the drawbacks relate to our actual deadline and staying on track with the direction of GitLab. For example, a release might be far away, but we want to ship something now. Or, we want to ship something, but the release just passed, and now we have to wait. Sometimes we try to cram in something just before the merge window closes even though it's not ready. When these situations arise, we remember to shift objectives and focus on providing value to our users.
There's a big impact on morale
One of the most bittersweet aspects of a monthly release cycle is that morale can soar or suffer, depending on the processes that are put in place. We're thrilled when we make something and quickly see the benefits. With our schedule, GitLab team-members see their hard work in action within a month, which is way better than in some enterprise organizations in which someone might make something that won't get released for six months. At GitLab, people can rapidly effect change with their contributions and feel like their work matters.
There were times in the past, however, when our release schedule dampened morale. In the early days, we had a few times when things came down to the wire, and we battled bugs right until the end, making the 22nd look like an impossibility. The rush towards the end caused quite a bit of stress on the team, so we decided to create a bigger buffer between the release and the closing of our merge window. We also developed a release process to help keep us on track. Our release template has helped us identify problems earlier so that we're not feeling pressured at the end, which could be detrimental to everyone's motivation.
How to determine the right cadence
While we've found success with monthly releases, we understand that it's not right for everyone. If you're a SaaS provider, you don't need releases and can just ship whenever something is finished. If you're shipping software that people manage themselves, you're going to have to do versioning, so that people know what version they're on and are aware of releases, patches, and upgrades. A monthly release cycle forces you into this, so in that case, this cadence would work well for your team. If there's hardware in the loop, extensive testing, or human testing that's needed, then a longer release cadence is required, because you have to factor in significant fixed costs.
Identifying the right cadence for your organization comes down to experimentation and what your users will accept. Some user bases may only want to update every quarter or twice a year, while others want more frequent versions to stay current with industry changes. Because we strongly believe that smaller steps let you deliver faster, we encourage you to start with monthly releases and work towards settling on the pacing that works best. Collaborate with your team to create processes that simplify actions and hold retrospectives to make adjustments. We've found that our retrospectives are extremely helpful in identifying consistent problem areas.
Cover image licensed under CC 0
