Job role: build and release engineer
As a software team’s release engineer you run release branches with Git, image builds with Docker and a local delivery pipeline end to end.
Level 401 · 13 lessons · 12 practice labs
Lessons
Planning the release
- Semantic versioning and a changelog
- Cutting and freezing a release branch
- Release notes from conventional commit messages
- Pinning dependencies and update day
- Short task: prepare the branch and notes for the next release
The build pipeline
- Building an image automatically on tag with a server hook
- Recording where a build came from
- Smoke tests and promoting a release
- A rollback plan: back to the previous image and tag
- The hotfix flow: from release branch back to main
- Short task: roll back a bad release and ship a patch release
Wrap-up
- A release runbook and handover note
- Capstone: run a release week from start to finish
Practice labs
- What should the next version be?: Decide the next version number under semantic versioning from the commit types since the last tag, write your reasoning and create the annotated tag.
- Release notes from commit messages: Write a release-notes script that groups the commits between two tags by type and lists breaking changes under their own heading, and run it on Oakmere Studios’ repository.
- Tags out of order and reused: Examine a script that picks the wrong ‘latest’ because of text sorting, the prerelease tags and a tag that was moved between two commits; find the true latest release and repair the release notes.
- Cut and freeze the release branch: Cut a branch for the next release, protect it in Gitea so only release managers can write, and show a push from a developer account is refused.
- Get the patch back to main too: Tag the fix made on the release branch as a patch release, carry it to main and show the fix is on both branches with no duplicate commit.
- Features that slipped in after the freeze: Find the feature commits that entered the release branch after the freeze tag, back them out of the release branch while keeping them on main, and update the release notes to match.
- Which commit did this image come from?: Write the commit id, version and date into the image as standard labels at build time, and show the image’s source commit with docker inspect.
- A hook that builds the wrong version: Prove the server hook that builds an image on tag push builds the tip of main instead of the tag, fix the hook and show the image in the registry came from the tagged commit.
- The source of an unlabelled production image: Find which commit produced the unlabelled image running in production by comparing digests, registry tags and build logs, pin the dependencies and prove a rebuild gives the same contents.
- A smoke test before release: Write a smoke test script that checks the health endpoint and version number after a deploy and exits non-zero on failure, and try it on a good and a broken release.
- Promote to production without a rebuild: Promote the image tested in staging to the production tag by digest without rebuilding, and prove from the registry that both tags point to the same digest.
- The image to roll back to is gone: In Brightfield Labs’ release, where rollback fails because a tag was overwritten, find the previous image’s digest from the deploy logs, roll back to that digest and put a rule in place so tags can’t be overwritten again.
About this course
As a software team’s release engineer you run release branches with Git, image builds with Docker and a local delivery pipeline end to end.
What you will learn
- Planning the release
- The build pipeline
- Wrap-up
Prerequisites
You should have practised the topics of the same path up to level 301.
Lab environment
Lessons run in your own Kali Linux terminal in the browser, connected to a private lab network. Nothing to install.
Frequently asked questions
- Is this course right for my level?
- The course is at level 401; it assumes you know the topics of the lower-level courses.
- Is there anything to install?
- No. Every lesson runs in your own lab environment that opens in the browser.
- How do lessons work?
- Each lesson has 8 to 10 steps and a short quiz. Early steps show the command to type, later steps give less help; if two attempts fail, the solution opens.
- Can I try it for free?
- Yes. The first three lessons of every course are free.