81.8 Project 84: Release automation with changelogs
Friends, hand-written release notes drift. Today we tag a semver release, generate a changelog from conventional commits, and publish a release asset.
मित्रांनो, हाताने लिहिलेल्या release notes drift होतात. आज semver tag, conventional commits वरून changelog, आणि release asset publish.
दोस्तों, हाथ से लिखी release notes drift होती हैं. आज semver tag, conventional commits से changelog, और release asset publish.
What you will build in this project
- Use conventional commits.
- Tag vX.Y.Z.
- Generate CHANGELOG.
- Attach the build artifact to the release.
1. Start from a real company story
At Swiggy in Bengaluru, nobody knew what shipped in v4.2 and a rollback took hours of git archaeology.
Rough cost: about ₹12 lakh in prolonged incident time.
Neha enforced conventional commits and automated changelogs on every tag.
Today we automate that release.
Ravindra Bagale's Tip
Students force-push tags after people already pulled them. Treat published tags as immutable. Keep that habit.
Students publish झालेल्या tags force-push करतात. Published tags immutable. सवय ठेवा.
Students publish हो चुके tags force-push करते हैं. Published tags immutable. आदत रखिए.
2. Start and prepare
Step 1: Why automate releases
Why: Humans forget what shipped. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: echo why. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 1: a1
Type this:
echo 'Changelog + tag = auditable what shipped when'
You will see:
Changelog + tag = auditable what shipped when
What it means: Why.
Example 2: a2
Type this:
mkdir -p /tmp/rel84 && echo 'Today: conventional commits, tag, changelog, asset'
You will see:
Today: conventional commits, tag, changelog, asset
What it means: Scope.
Example 3: a3
Type this:
echo 'Semver: MAJOR.MINOR.PATCH'
You will see:
Semver: MAJOR.MINOR.PATCH
What it means: Semver.
Step 2: Conventional commits
Why: feat fix chore. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: examples. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 4: b1
Type this:
printf '%s\n' 'feat: add cart discount endpoint' 'fix: handle empty cart total' 'chore: bump eslint' > /tmp/rel84/COMMITS.txt && cat /tmp/rel84/COMMITS.txt
You will see:
feat: add cart discount endpoint
What it means: Examples.
Example 5: b2
Type this:
echo 'feat -> MINOR, fix -> PATCH, BREAKING CHANGE -> MAJOR'
You will see:
feat -> MINOR, fix -> PATCH, BREAKING CHANGE -> MAJOR
What it means: Map.
Example 6: b3
Type this:
echo 'Commitlint in CI can reject bad messages'
You will see:
Commitlint in CI can reject bad messages
What it means: Lint.
Step 3: Tag
Why: Create v1.2.0. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: git tag. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 7: c1
Type this:
echo 'git tag -a v1.2.0 -m "release: v1.2.0"'
You will see:
git tag -a v1.2.0 -m "release: v1.2.0"
What it means: Tag.
Example 8: c2
Type this:
echo 'git push origin v1.2.0'
You will see:
git push origin v1.2.0
What it means: Push tag.
Example 9: c3
Type this:
echo 'Annotated tags (-a) store the message and author'
You will see:
Annotated tags (-a) store the message and author
What it means: Annotated.
3. Build the main pieces
Step 4: Changelog generate
Why: From history. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: tool tip. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 10: d1
Type this:
printf '%s\n' '# Changelog' '## v1.2.0' '- feat: add cart discount endpoint' '- fix: handle empty cart total' > /tmp/rel84/CHANGELOG.md && cat /tmp/rel84/CHANGELOG.md
You will see:
## v1.2.0
What it means: Changelog.
Example 11: d2
Type this:
echo 'Tools like standard-version or git-cliff generate this from commits'
You will see:
Tools like standard-version or git-cliff generate this from commits
What it means: Tools.
Example 12: d3
Type this:
echo 'Keep CHANGELOG.md in git so reviewers see it in the release PR'
You will see:
Keep CHANGELOG.md in git so reviewers see it in the release PR
What it means: In git.
Step 5: Release workflow
Why: On tag push. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: YAML tip. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 13: e1
Type this:
printf '%s\n' 'name: release' 'on:' ' push:' ' tags: [ \'v*\' ]' 'jobs:' ' release:' ' runs-on: ubuntu-latest' ' steps:' ' - uses: actions/checkout@v4' ' - run: echo Build artifact for $GITHUB_REF_NAME' ' - run: echo Attach JAR or tarball to the forge release UI' > /tmp/rel84/release.yml && cat /tmp/rel84/release.yml
You will see:
tags: [ 'v*' ]
What it means: Workflow.
Example 14: e2
Type this:
echo 'Forge release APIs attach files to the tag'
You will see:
Forge release APIs attach files to the tag
What it means: API.
Example 15: e3
Type this:
echo 'Write the CHANGELOG section into the release body'
You will see:
Write the CHANGELOG section into the release body
What it means: Body.
Step 6: Asset
Why: Attach the JAR. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: artifact. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 16: f1
Type this:
printf '%s\n' 'Build: mvn -B -DskipTests package' 'Asset: target/cart-1.2.0.jar' 'Attach on the release' > /tmp/rel84/ASSET.txt && cat /tmp/rel84/ASSET.txt
You will see:
Asset: target/cart-1.2.0.jar
What it means: Asset.
Example 17: f2
Type this:
echo 'Checksum the asset and publish SHA256SUMS next to it'
You will see:
Checksum the asset and publish SHA256SUMS next to it
What it means: Checksum.
Example 18: f3
Type this:
printf '%s\n' 'Acceptance: tag v1.2.0 has CHANGELOG notes and a JAR asset' > /tmp/rel84/ACCEPT.txt && cat /tmp/rel84/ACCEPT.txt
You will see:
Acceptance: tag v1.2.0 has CHANGELOG notes and a JAR asset
What it means: Gate.
4. Automate and verify
Step 7: Immutable tags
Why: No rewrite. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: rule. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 19: g1
Type this:
echo 'Do not move a published tag to a new commit'
You will see:
Do not move a published tag to a new commit
What it means: Rule.
Example 20: g2
Type this:
echo 'If the release is bad, publish a new patch tag'
You will see:
If the release is bad, publish a new patch tag
What it means: Patch.
Example 21: g3
Type this:
echo 'Protect tags in forge settings when available'
You will see:
Protect tags in forge settings when available
What it means: Protect.
Step 8: Version in code
Why: Single source. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: bump. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 22: h1
Type this:
echo 'Bump package.json or pom.xml version in the release commit'
You will see:
Bump package.json or pom.xml version in the release commit
What it means: Bump.
Example 23: h2
Type this:
echo 'Tag must match the version field'
You will see:
Tag must match the version field
What it means: Match.
Example 24: h3
Type this:
echo 'Automate the bump with the same release tool'
You will see:
Automate the bump with the same release tool
What it means: Auto.
Step 9: Announce
Why: Tell humans. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: notify. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 25: i1
Type this:
printf '%s\n' 'Post the changelog section to the team channel' 'Link the forge release URL' > /tmp/rel84/ANNOUNCE.txt && cat /tmp/rel84/ANNOUNCE.txt
You will see:
Post the changelog section to the team channel
What it means: Announce.
Example 26: i2
Type this:
echo 'Ops runbooks should cite the tag not latest'
You will see:
Ops runbooks should cite the tag not latest
What it means: Runbook.
Example 27: i3
Type this:
echo 'Customer notes can be a filtered subset of the changelog'
You will see:
Customer notes can be a filtered subset of the changelog
What it means: Customer.
5. Harden and accept
Step 10: Story Swiggy
Why: Unknown v4.2. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: story. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 28: j1
Type this:
printf '%s\n' 'At Swiggy in Bengaluru, nobody knew what shipped in v4.2 and rollback took hours.' 'Neha enforced conventional commits and automated changelogs on every tag.' > /tmp/rel84/STORY.txt && wc -l /tmp/rel84/STORY.txt
You will see:
2 /tmp/rel84/STORY.txt
What it means: Story.
Example 29: j2
Type this:
echo 'Rough cost: about ₹12 lakh in prolonged incident time'
You will see:
Rough cost: about ₹12 lakh in prolonged incident time
What it means: Cost.
Example 30: j3
Type this:
echo 'Neha: PASS'
You will see:
Neha: PASS
What it means: Sign-off.
Step 11: Proof
Why: Files. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: ls. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 31: k1
Type this:
ls /tmp/rel84
You will see:
ACCEPT.txt\nANNOUNCE.txt\nASSET.txt\nCHANGELOG.md\nCOMMITS.txt\nSTORY.txt\nrelease.yml
What it means: Tree.
Example 32: k2
Type this:
grep v1.2.0 /tmp/rel84/CHANGELOG.md
You will see:
## v1.2.0
What it means: Version.
Example 33: k3
Type this:
echo 'GHA/GitLab projects 77-84 complete'
You will see:
GHA/GitLab projects 77-84 complete
What it means: Done block.
Step 12: Acceptance
Why: Tagged release with changelog. We do this before the next step so mistakes stay small and easy to undo. Read the output carefully; the numbers and names tell you if the machine is healthy.
What: final. Follow the numbered examples below. Type each command, read the exact output, and match the meaning line before you move on. That is how real teams learn a tool.
Example 34: z1
Type this:
echo 'Conventional commits in use'
You will see:
Conventional commits in use
What it means: Commits.
Example 35: z2
Type this:
echo 'CHANGELOG for the tag'
You will see:
CHANGELOG for the tag
What it means: Log.
Example 36: z3
Type this:
echo 'Release asset attached'
You will see:
Release asset attached
What it means: Asset.
Check yourself
Q1. Who fixed Swiggy release mystery?
Neha
Q2. Commit style?
conventional
Q3. Tag example?
v1.2.0
Q4. Notes file?
CHANGELOG
Q5. Asset example?
JAR
Q6. Force-push tags?
no
Friends, you automated a release with a changelog. Did you understand? Let us try it once more. Cut a patch tag from a fix commit and prove the changelog lists it.
मित्रांनो, तुम्ही changelog सह release automate केला. fix commit वरून patch tag कापा आणि changelog मध्ये तो दिसतो हे सिद्ध करा.
दोस्तों, आपने changelog के साथ release automate किया. fix commit से patch tag काटें और changelog में वह दिखे, यह साबित करें.
Lab: try at home
- Conventional commits.
- Semver tag.
- Changelog file.
- Release asset.
Recap
- Conventional commits unlock automation.
- Tags are immutable.
- Changelog from history.
- Attach the artifact.
- Patch from fix.
Lab
- Finish all eight projects; keep ACCEPT notes for each.
- Never commit cloud keys, runner tokens, or forge PATs.
- Pin action and runner image versions; never float on latest for prod.
- After each project, write one paragraph: what broke and how you fixed it.
- Next batch starts GitOps and DevSecOps projects 85-90.
Practice task
Pick the OIDC deploy and the Terraform plan-on-PR. Prove both before you call the chapter done.
Ravindra Bagale's Tip
Pin action versions. Prefer OIDC over long-lived keys. Matrix for versions. Tag images with SHA. Plan on PR, apply on main. Tag runners for heavy jobs. Conventional commits unlock changelogs. Treat published tags as immutable.
Action versions pin करा. Long-lived keys ऐवजी OIDC. Versions साठी matrix. SHA tags. PR वर plan, main वर apply. जड jobs साठी tagged runners. Conventional commits = changelogs. Published tags immutable.
Action versions pin करें. Long-lived keys की जगह OIDC. Versions के लिए matrix. SHA tags. PR पर plan, main पर apply. भारी jobs के लिए tagged runners. Conventional commits = changelogs. Published tags immutable.
In short
- Pin action versions.
- Matrix for Node versions.
- SHA image tags.
- OIDC beats keys.
- Plan on PR.
- GitLab stages.
- Tagged EC2 runner.
- Changelog on tag.