I have a friend (no, really!). This friend works in the layer between IT and end users. Something like a business analyst or consultant. This friend does not have a technical or IT background. They have gained a high level understanding of software and systems, but, for example, are not able to read/write code or converse on the low-level details of software.
My friend's company has Continuous Integration (CI) / Continuous Delivery (CD) pipelines in place to build & deploy their software, but these pipelines must be manually triggered.
My friend is being asked to take responsibility for triggering the automatic deployment pipelines, both for non-production and production environments. The process for doing this is technically simple and quick:
- Login to automation software
- Select appropriate CD pipeline job
- Choose a couple configuration values (environment to deploy to, software artifact to deploy)
- Hit the button to trigger job
To deploy, or not to deploy
My friend does not feel comfortable accepting this responsibility, even though the process itself would not be difficult for them to perform.
I am a software engineer responsible for triggering similar automated deployments at my company, and I would not feel comfortable handing this responsibility over to a less-technical user, like my friend. However, we are both having difficulty in articulating what about this makes us uncomfortable, and we're not sure if we're being unreasonable.
What's the big deal, anyways?
When I, as a software engineer, perform the process to trigger an automatic deployment, I do more than just trigger the job.
I familiarize myself with the code changes between the artifact that is already deployed, and the artifact I am deploying (if I am not already familiar). I assess the scope and risk of these changes. I assess the affects of these changes on the system and dependent systems. If, during the above steps, I identified any areas of risk, I prepare myself to respond to those specific items, if need be. Using my knowledge, I make a final judgement call of whether to proceed with the deployment.
Once I trigger the deployment job, I monitor the status. If the job fails, I first confirm that the automated rollback was successful and that the application / system is not impacted. I then begin initial analysis & troubleshooting of the job failure, and whether another attempt is warranted or if action needs to be taken first.
After the job completes successfully, I perform some sanity checks of the deployment process and software health.
I have intimate knowledge of the code, of each step performed by the automated deployment process, and of the system infrastructure & architecture. This knowledge informs my decisions.
Now, I will be the first to admit - a lot of this stuff could be either automated, or built into the change management process before it gets to me pushing the button. In an ideal world, the whole process could be entirely automated and continuous - no humans necessary.
That said, I do not believe my friend's company currently has a change management process or automation that would handle all of these.
What is needed to allow non-technical, non-IT users to manage automated deployments of software artifacts (both in non-production and production environments). What safe guards must be put in place to make this process safe and reliable? Or is this just a bad idea no matter what?