automating release

[Br3nda]

automate some or all of the release process. We have deployment automated, but there are a few more steps

• [ ] 1) Propose a release by making a PR to merge dev into staging whenever dev is ahead of master
• [ ] 2) If approved and CI passes, merge this on Friday
• [ ] 3) Tag the release
• [ ] 4) add as a release on GitHub

[pozorvlak]

By "staging", do you mean "master"? Otherwise, yes, let's AUTOMATE ALL THE THINGS.

[Br3nda]

yes! sorry. I mixed up the branch names https://github.com/rabid/nzsl-online

[CloCkWeRX]

To be a bit daring - we dont really have much QA resource to manually test staging; how dramatic would it be if we went to deploy from master on merge, relied on monitoring to pick up issues?

Staging env would be useful for landing bug features that we want to demo still, and rehersing deployment changes, but the default could easily be otherwise...

[CloCkWeRX]

• big features

[Br3nda]

i usually give staging a bit of a test before merging a release - focusing on what's changed.

Are you thinking we merge PRs straight into master for deploy?

[pozorvlak]

Slightly less daringly, we could run curl against a bunch of endpoints on staging and check that we get 2xx responses.

[Br3nda]

I have a bot that can make a PR from dev into master whenever it's out of sync. But the title of the PR won't be "Release X". https://app.backstroke.co/#/links

I can give that a tests -- someone will need to edit the name of the PR

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[CloCkWeRX]

Well, this happens for staging, not for mainline. That's not too shabby. Maybe closable? Our coverage is high but not enough that I feel green build = bulletproof deploy.

[cesy]

Yes, I agree, I think this is done enough for our current level of confidence.