AI-assisted release automation I developed from Release Herald, now used in the team’s recurring release process for pinned candidates, shared reviews, and controlled production releases.
My role
Creator & engineer
Scope
Release automation across repositories
Status
Internal tooling · used by the team
Python
Bash
GitHub Actions
Claude
Slack API
Overview
A release involves more than a list of merged changes. Engineers need to know what is included, what deserves attention, and which version they are deploying. I started with Release Herald, an AI-assisted preparation prototype, and developed it into Ship It with feedback and contributions from the team.
My part in the work
I created the original prototype and developed release preparation, shared summaries, and deployment-workflow improvements across the web application and its SDK. I worked with other engineers to refine the controls and fit the tool into the team’s release process.
How it works
A simplified view of the workflow. This is a workflow diagram, not a screenshot of internal tools.
One selected version, shared context, and people in control of deployment.
Technology stack
The tools behind the work, and where I used them.
Release selection
Python
Bash
Git
GitHub API
Collect the actual production-to-candidate changes and preserve the selected commit in a versioned release.
Review & communication
Claude
Python
Slack API
Draft change summaries and review context, then combine related repository updates in one team notice.
Delivery workflow
GitHub Actions
GitHub Releases
Separate release preparation from staging and production deployment, retaining version checks and human approval.
Selected contributions
Make the release scope explicit
Problem
A branch or the latest tag does not, by itself, explain what has reached production or what a new release will change.
My contribution
I developed candidate selection and release preparation around a verified production baseline, a pinned commit, and a reviewable change inventory.
Decision
Record the selected source before preparing the release. Treat preparation and deployment as separate steps, so a draft does not ship code.
Value delivered
The release records what was selected and what changed. Engineers can review a concrete candidate rather than a moving branch.
Python
Git
GitHub API
GitHub Releases
Give the team one shared release context
Problem
Related application and SDK changes arrive from different repositories. Separate notices make it harder to understand the release as a whole.
My contribution
I built shared release summaries, bringing shipping highlights together and keeping supporting risks, checks, and contributor context in replies.
Decision
Keep source changes available for review and use AI to help draft the explanation. Update the existing version notice when repository context changes.
Value delivered
The team gets a combined release overview in its existing communication workflow, with detail available when reviewers need it.
Python
Claude
Slack API
GitHub Actions
Connect preparation to a controlled delivery flow
Problem
Release automation needs clear boundaries between preparing, testing, and approving a deployment.
My contribution
I separated tag-based deployment workflows and contributed production-evidence checks, version validation, and review-driven refinements to the release process.
Decision
Keep human production approval and existing deployment checks. A generated summary informs the review; it does not approve the release.
Value delivered
The team uses Ship It in its recurring release process. Release records and production workflows connect reviewed candidates to deployed versions, while shared notices keep engineers informed and production approval stays with people.
GitHub Actions
GitHub Releases
Python
Engineering decisions
AI assists the review
Generated summaries are tied to collected release context. Engineers still inspect the changes, test affected journeys, and approve production deployment.
Keep the version traceable
Pin the candidate and retain its source reference through preparation and deployment. A published version represents a specific selection of code.
Build within the team’s workflow
Use GitHub Releases, Actions, and shared Slack notices. The tool grew from a working prototype through team feedback and continued engineering contributions.
Outcome
I took Ship It from an initial prototype to a tool the team uses for regular releases. It brings versioned candidates, AI-assisted reviews, and shared application and SDK updates into the release workflow, with engineers in control of deployment.
Let’s compare notes.
Have a related challenge or a question about the work?
