What's your release workflow on Github? Automatic or manual?
Posted by M1H4F@reddit | ExperiencedDevs | View on Reddit | 16 comments
Every sprint end, I'm still going through merged PRs manually. Because the auto-generated changelog (used release-please, changesets) is technically correct and completely useless.
Curious how others handle this: Do you use what semantic-release or changesets spits out as-is, or does someone always end up rewriting it anyway?
dylanmcguire230@reddit
We don't generate release notes automatically either, so nothing to recommend there.
For the software release process, every merge to main triggers a GitHub Actions build that publishes a GitHub Release marked as a pre-release. The desktop apps we ship pull from an update endpoint we host with two channels: dev tracks the latest pre-release, stable tracks the latest non-pre-release. Promotion is a manual GitHub workflow_dispatch that we run when we feel ready. It just takes the build number we're promoting, clears the pre-release flag, and marks it as latest.
susmines@reddit
We dropped GitHub when they stopped being able to deliver a 99% uptime
apartment-seeker@reddit
What did you switch to?
susmines@reddit
BitBucket
cstopher89@reddit
Yikes, Github downtime sucks but Bitbucket is absolutely bottom of the barrel. You can't even have it re-request reviewers on updates to PR automatically.
kobbled@reddit
Github's been playing catch-up to bitbucket on UX for the better part of a decade and they still haven't made it tbh
susmines@reddit
You totally can do that.
Anyways, BitBucket works just fine for us. It has fully integrated CI/CD, and the deep JIRA integration is handy for us being a heavy Atlassian shop.
Only thing I don’t love is that I wish there was more gradual control over branch restrictions.
cstopher89@reddit
https://jira.atlassian.com/browse/BCLOUD-20676
I don't think you can. Its been like that for years at this point.
apartment-seeker@reddit
I see, thanks
ZukowskiHardware@reddit
I deploy each pr right after I merge it to prod with a semantic tag. Deploys automatic
Gunny2862@reddit
Depends on risk level.
David_AnkiDroid@reddit
Automatic, with manual changelog
vyomc@reddit
I’ve had great experience with release-drafter. It’s flexible enough for your team to get used to, and automates most of workflows like auto labeling PRs based on conventional commits.
Puzzleheaded-Pen9979@reddit
Depends on the project. I've had projects where part of the PR process checklist is to have made an entry in the CHANGELOG.md
dalbertom@reddit
I've worked with both. Neither is right or wrong. The main thing to keep in mind is the target audience: commits are for developers and release notes are for users.
If your team has the budget to hire a technical writer that might help a lot, or the product owner that is in charge of writing the specs can also write the release notes. A lot of developers struggle with writing good commit messages, let alone content that would be useful as a release note or user-friendly documentation.
Personal-Brick-1326@reddit
We are using custom UI as deployment tool on top of Spinnaker and it has own functionality built in (with some additional stuff like risk labels for each PR etc). Also I have used release-please previously in much smaller company than current
https://github.com/googleapis/release-please