Improving the recipe release process #663
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: toolshed/organising#663
Loading…
x
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
/cc @3wordchant @iexos
Less magic (and things breaking) in
abra recipe releaseand a clear separation in the pushing of changes to a remote.We should also take this opportunity to improve clean up in the release process, when things go wrong? I think it might make sense to rollback the commit if something breaks. A brainstorm on testing scenarios for integration testing is welcome!
Thoughts?
For me it makes total sense to seperate
recipe releaseandrecipe publish. Though on the naming I am not sure, I associate "making a release" with publishing as well.Is there any reason why
recipe sync, which does nothing but change the version label iirc, should be seperated from creating the commit (i.e. release)? Doesrecipe releasewithout publish anything more than creating that commit (and i think asking for release notes)?My proposal right now:
recipe upgradeas it isrecipe syncchange the label like before but also create the commitrecipe releasecheck if push and tagging will work, then create the tag and push itrecipe publishinstead, it might make the transition clearer. Alsosynccould then be namedreleaseinstead, though that might reintroduce confusionIt creates the git tag.
I'm torn about this. Being able to test
abra app upgradewithout pushing is useful. But, I've seen multiple situations where people release an upgrade but don't push the tag, which is very nonideal. Happy to defer to whoever has a clear vision here.This is actually the reason I brought it up. How does this actually happen? I image just using
git pushwithout--tags?Releases should be
Each of these fails sometimes.
I feel we need a common workflow that enables both and is supported and pushed for by
abra.I try to break it down to what is happening right now, maybe we find some clarity as to what would be the ideal release flow:
abra recipe upgradeand/or manual)abra recipe sync)abra recipe release)abra recipe release)abra recipe releaseabra recipe release)abra recipe release --publish)abra recipe releasealready done or fails in some way, need to dogit push --tagsI am not sure if all of this is correct, please add anything that is missing or wrong!
So here is another try at a new flow:
abra recipe upgrade:abra recipe release, which does all of this:abra recipe check? "did you actually test this? ;)")releases/nextabra recipe releaseagain later. It should recognize release commitsOf course this needs thorough testing so we actually trust this. The release process is complex. I feel the more we automate it, the easier it will be for maintainers to not mess up. I think its worth the additional complexity in
abra, though easy for me to say as I don't maintain it 😅amazing @iexos tysm for writing this all out
join me in this rabbit hole #514
And related, there is also the WIP maintainers proposal:
We're due a collective brain dump here, let's try to get ourselves into the next kite flying hour?
Move `--publish/-p` to a new `abra recipe publish`to Improving the recipe release processHey, just jumping into the discussion here.
What do you think of delegating the actual release tagging to Drone?
I think all the recipe development tasks we do shouldn't depend on actual tags, e.g. checking if an upgrade works or else. I'd love to be able to work on branches, have pull requests with automated checks, quality gates and optionally reviews. A release/new tag should therefore only be created when merged into main.
So either I'd like to manually start a drone job from the UI or it might be able to check for a new version in the compose.yml label for the app?
And with that, I'd love to be able to have feature-branch deployments. So when specifing a version in the .env-file, I could add the branch name to always deploy the latest version from the branch?
Might also allow to ommit the -C flag for alle those commands in that situation?
Lots of rambling around here, but I'd love to talk about this in a kite-flying session!
PS: I previously worked in a team where we've made it so fast and fluent to deploy stuff via CI/CD, that we all preferred to use those tools over manual deployments or release processes. Really loved that actually
@simon nice! check #514 I think that'd be going more in that direction. We need some sort of semi-automated process with human review in the middle or towards the end somehow.