ManagementSubsection
Release process
What happens between "the code is merged" and "a user has it" — which in a healthy team is a decision rather than an event. Three topics: how to plan a release when you cannot promise a date, which branching model your review latency can actually support, and how to write down what changed for the people it changed for.
What is inside
Every page in this group, with what each one covers.
- Release PlanningDeploy is not release: the four kinds of feature flag, expand-and-contract, and what a go/no-go should check.Feature flagsGo / no-go
- Git Branching StrategyTrunk-based, GitFlow and GitLab Flow compared honestly — and why review latency, not the model, is the real cause of long branches.Trunk-basedGitFlow
- ChangelogChangelog, release notes and migration guide are three documents. Plus SemVer, 0.y.z, and a deprecation policy.SemVerDeprecation
Where to start
- Releases are stressful eventsRelease planning, and specifically the separation of deploy from release. That one change removes most of the stress.
- Merges are painfulThe branching page. The fix is usually shorter branches, and shorter branches usually need faster reviews.
- You publish an APIChangelog — the public API question and the deprecation policy are what your consumers are actually asking for.
Elsewhere in the section
- ManagementIT project management is the set of decisions that turn an intention into shipped software: what to build, how to cut it into work that can actually be finished, how the team runs itself week to week, and how the result reaches users. This section covers 21 topics in five groups — product management, decomposition, methodologies, the release process and the formal frameworks — and each page gives the trade-off behind the choice rather than a summary for a certification exam.
- MethodologiesHow a team decides what to build next, in what order, and how it knows when something is done. Nine methodologies, from the two most teams actually run to the four that exist because one team stopped being enough. Each page describes what the framework actually defines — every ceremony, every role, every artefact — rather than summarising it, and says plainly where it stops working.
- DevOpsGetting a change from a developer’s machine to a running system, repeatably and without ceremony. Three topics that stack: the pipeline that decides whether a change is safe, the image format that makes "it works on my machine" a testable claim, and the scheduler that keeps the result running. Each page is about the mechanism rather than a tool’s configuration syntax, which is what transfers when you change tools.
Found this useful?
Share it with someone who is working on the same problem.