Release Cadence and Philosophy

6 posts · Dec 2015 – Apr 2022

What this trail covers

GitLab has evolved its release cadence to a monthly cycle, emphasizing iterative development and predictable value delivery. This approach forces smaller feature increments, improves quality control, and positively impacts team morale by allowing engineers to see their work in production quickly. The company has also developed robust release processes and buffers to manage challenges and stress associated with tight deadlines. This post details the features released throughout 2016, including Is

All GitLab trails

Apr 2022GitLab.com is moving to 15.0 with a few breaking changesThis post details breaking changes in GitLab 15.0, focusing on the removal and modification of features across multiple stages. Key changes include: - **Manage:** Removal of audit events for repository push events, deprecation of OAuth implicit grant and tokens without expiration, mandatory enforcement of SSH and PAT expiration, and removal of required pipeline configurations from Premium tier. Changes to the external status check API mandate `status: 'passed'` for passing states. - **Create:** Removal of `PUSH_RULES_SUPERSEDE_CODE_OWNERS` feature flag, making push rules supersede CODEOWNERS. Removal of `defaultMergeCommitMessageWithDescription` GraphQL API field. - **Verify:** Runner API status changes from `offline`/`not_connected` to `stale`. `artifacts:report:cobertura` replaced by `artifacts:reports:coverage_report`. Strict host key checking is now enforced by default for the SSH executor. `type`/`types` CI/CD keywords are removed, replaced by `stage`/`stages`. Project setting for test coverage parsing removed, requiring use of the `coverage` keyword in `.gitlab-ci.yml`. - **Package:** Deprecation and removal of `htpasswd` authentication for Container Registry. GraphQL permissions for Package settings are updated, restricting updates to Maintainer role and above.
May 2020GitLab.com is moving to 13.0, with narrow breaking changesThis post details breaking changes in GitLab 13.0, including updates to Auto DevOps PostgreSQL chart versions (0.7.1 to 8.2.1) and `deploymentApiVersion` to `apps/v1` for Kubernetes 1.16 compatibility. It mandates the transition from `only/except` to `rules` for Auto DevOps and Secure configuration templates, impacting `Build.gitlab-ci.yml`, `Test.gitlab-ci.yml`, `Deploy.gitlab-ci.yml`, and various Secure scanning templates. The `/projects` API endpoint now enforces a 50,000 offset limit, promoting keyset-based pagination. Snippet content is removed from search, and the `cve` field in security reports is replaced by a new `id` field. The `token` attribute is removed from the Runner's details API. Deprecated project paths using `/-/` separator are removed. GitLab Runner 13.0 introduces breaking changes for Windows Batch shell executor (defaulting to PowerShell), the `/debug/jobs/list?v=1` endpoint (replaced by `v=2`), the `--docker-services` flag (removed), legacy build directory caching (removed), and drops support for Windows 1803 and Fedora 29. License Compliance requires the new `License-Scanning.gitlab-ci.yml` template and `artifacts:reports:license_scanning` report type.
Nov 2018How we maintain product velocity with a monthly release cycleThis post details GitLab's adoption and refinement of a monthly release cycle. It explains the benefits for users (predictable value delivery) and teams (capacity planning, smaller feature increments, improved morale). It also discusses challenges such as deadline pressure and potential morale dips, and outlines mitigation strategies like creating buffers and developing release processes and templates. The post concludes by offering guidance on how organizations can determine their own optimal release cadence based on their specific context and user base.
Jul 2016Release Early, Release OftenThis post introduces the concept of 'releasing early and often' as a trend in software development, moving away from large, infrequent deployments to smaller, more frequent releases. It advocates for time-based releases over feature-based releases, with GitLab adopting a monthly release cycle (shipping on the 22nd) and releasing patches as needed. Key advice includes decoupling features, focusing on smaller increments, and reducing the time from issue to deploy. The core takeaway is that usability, fast turnaround, and development efficiency are more important than perfect, feature-complete releases.
Dec 2015How we managed 49 monthly releasesThis post details GitLab's adoption of a strict monthly release cycle, inspired by Ubuntu and GNOME. It explains the rationale behind time-based releases for distributed software, the benefits of monthly cycles for communication and rapid feedback, and the Agile practice of team members picking tasks from a pool. The role of Release Manager is rotated monthly to avoid single points of failure and encourage process improvement. The release process involves creating release candidates, QA, deployment to GitLab.com, and preparing packages and blog posts. Post-release, a regression issue is used to track and fix bugs, with unscheduled patch releases for critical issues. The post argues that a stable release schedule builds trust and indicates a healthy, actively developed open-source project.
Advertisement