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 PlanningA finished release plan, staged by flag: deploy vs release, rollout strategies, the way back, and four releases that failed.Feature flagsCanary
- Git Branching StrategySix models on one screen and five questions that choose — and why review latency, not the model, makes branches long.Trunk-basedGitFlow
- ChangelogA finished changelog, line by line: what a version number promises, entries people can act on, deprecation, and automation.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 25 topics in six groups — product management, decomposition, methodologies, the release process, the formal frameworks, and the craft of running a project rather than a method for running one — 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.