Release management about tech-radar HOT 9 CLOSED

Sorry, that was long and waffly. TLDR: yes, current scripted releases tick all the boxes!

from tech-radar.

Do we really want to continue doing manual releases? (disclaimer: don't know how many teams currently do this!).

from tech-radar.

As far as I know most teams now have release scripts, but Prompt and DMv6 are still missing them (we just haven't gotten around to writing that latter one since we release that pretty infrequently). I'd definitely be up for actively trying to retire any manual release processes that we have (including cleaning up some release scripts which are mostly-automatic but have some manual bits at the end)

(plus it'd be a good excuse to put more investment into dtw-docs >.>)

from tech-radar.

I'd be keen for manual releases to be in Retire.

I don't think that would force "Move DMv6 over to release scripts" to be a top priority. Leaving that alone seems a pragmatic choice, unless the team think otherwise. I see this as an outlier, which I don't think should have too strong an influence on the tech radar?

(Please do challenge me if you think we should "document the lowest denominator".)

I'd encourage SQL Prompt to use release scripts, though. I'm surprised to hear the product isn't already.

from tech-radar.

1. Adopt basic-release.ps1 if possible, does what most products need in one line
2. The rest of RG.Release is there if your release process differs slightly
3. Arbitrary PowerShell if you're doing stuff no other product needs to do
4. Manual processes for whatever you can't automate

from tech-radar.

Rob Chipperfield has always chimed in on this subject in the past, with good arguments about requiring releases to be traceable to specific individuals, possibly for legal reasons. It's definitely worth bringing this issue to his attention, which I can't do right now because the mobile GitHub app is properly pants!

from tech-radar.

Paging @rmc47 on behalf of @ChrisLambrou

(Although I believe the current scripted release approach ticks all of Bobby's Boxes?)

from tech-radar.

My thoughts have largely been along the lines of:

• Releasing something to our customers - at least for "full" releases, perhaps arguably less so for CfU - should be a thing which a human makes an active decision to do;
• It should be as easy and reliable as possible for someone to do that, so massive 👍 to using release scripts, ideally with common ground where possible (i.e. what @samblackburn said above);
• Teamcity should not have permission to release code into our customers hands of its own accord - there's just too many places where its user can be told to run arbitrary code - but I'd consider Octopus appropriately trustworthy;
• I want to be able to go back in the future and see an actual human's name against the "x made the decision to release SQL Foo 1.2.3", in a way that's provable to pretty high standard.

So @garethbragg, I agree entirely that anything that involves someone manually going through a whole heap of steps across different systems is bad (Retire?), but I would also be wary of having a Teamcity build which automatically shipped some artefacts from another build straight out to our customers with no accountability or human intervention.

The Powershell release scripts seem to strike a reasonable balance between these two, I think?

from tech-radar.

Anyone fancy bringing this to a head with a PR? 🙏

from tech-radar.