Manual Deployment Steps.
I'm in the process of tidying up our release and deployments to make them easier to use, and implementing a new department requests.
We have multiple build streams at any given time, perhaps 4 or so, they are built the same way, and only differ by git branch, version numbering and a few other things, which I have extracted out as parameters. These are now all building using a Template, all good so far.
I now need to look a the deployment plan aspect. The first problem, whilst these 4 or so streams are all deployed in the same way (aside from a few differences that could be extracted out as parameters), I'm unable to template these deployments, as each deployment plan has implicit references to it's build plan and uses parameters such as %dep.xxxx% where he xxxx is defined in the build. I don't see how this could work with templates, as the xxxx is different for each plan.
The final problem I am trying to solve, is that I have been asked to look at a release plan. How our deployment works, is that every build is essentially a candidate, we build a fully deployable final image, and when we have decided on our “golden build” we want to do a small release procedure, basically copying the deployment to s few places, and some other steps relating to deployment artefacts. Ideally, we would like a manual stage in deployment plan, however I can't see anything relating to this.
I did look at a sub project on my deployment plan, however this comes with some issues itself, I'm not seeing variables from the deployment in there (despite it being deployment plan), I'm only seeing variables from the build, which is odd.
It also means it's yet another plan to create/copy when we create new steams, which is extra headaches on setup for devs who use us, and also more to go wrong.
What would be the recommended approach to do some additional steps on a specific build once it's passed QA. We don't want to rebuilt or rerun anything, as this is going to be changing what's been tested.
Thanks.
Please sign in to leave a comment.
Hi. First of all, having a concrete example of how it is currently set up and how exactly you want it to work would help to be specific with the suggestions.
In the meantime, it seems like you could store project settings in version control and have branch-specific build configuration settings. If you use Versioned Settings, you might as well store the settings in Kotlin DSL format. It allows more flexibility with the settings, especially when you use Kotlin extension functions instead of the Build Configuration Templates. Here, you can see a video tutorial for setting up pipelines with Kotlin DSL.
Regarding manually deploying the "golden build", you can achieve that using Build Promotion. For example, configuration A produces an artifact and configuration B deploys it. Let's say A is started automatically by a trigger, and B has snapshot and artifact dependencies on A. You can pick the build of A and promote it to the configuration B. B will deploy the artifact produced by the picked build of A.
We already use the deployment step to build ISO and installer images, these are what we want to promote, we don't want to change them, just sign them off, run some release steps.
Having deployments that depend on builds is a required evil, but having another layer of dependent release sub projects, one for each release stream is unmanageable, which is why I was hoping manual steps might help, like TFS has.