Stop writing changelogs by hand. The deploy log already contains every commit that hit production, with the time it landed and who pushed the button. The work is in making the deploy log readable — and that’s a one-day project, not a process change.
For three years our team kept two parallel records of what shipped: the deploy history (auto-generated, accurate, ugly) and the changelog (hand-curated, lossy, three weeks out of date). The changelog was always wrong. We were keeping it because changelog felt like a thing professional teams do. The deploy history was already the truth.
What makes a deploy log a changelog
Three things, none of them hard:
- Conventional commit prefixes.
feat:,fix:,chore:— the format that lets a script group commits into sections. Five characters of discipline per commit message. - A linked PR or ticket per commit. Not in the commit body — in the commit message itself. So when someone asks “why did we change X” the deploy log answers it.
- A title that reads as a sentence to an outsider. Not “fix bug” — “fix calendar invite duplicating recurring events.” The diff is for engineers. The title is for the changelog reader who isn’t one.
What stops being a problem
When the deploy log is the changelog:
- The “did we ship X yet” question gets answered by
git log, not by a Slack search of #releases. - The release-notes email writes itself with thirty seconds of grep.
- The “when did this regress” question is one command instead of a two-day archaeology project.
- The temptation to “write a proper changelog after” goes away because there’s no after. It was always now.
The honest part
This works only because the team agrees the commit message matters. The first month is annoying — people forget the prefix, write title-less messages, push at 5pm with wip. Then it becomes a habit and saves a paragraph of work every release.
If your commit messages are bad, you don’t have a changelog problem. You have a hygiene problem with a documentation symptom.