Being able to go to production in one click, who doesn’t want that? But what does that require and how do you set it all up? For starters, you obviously need to have your testing automated, but obviously you already had that. If not, stop reading now!
It also seems natural to me that you have developers reviewing each other’s work. In addition, you need a well-established pipeline with a strict and stable build. Preferably, the build already runs static code analysis, runs unit tests, automatically checks your code for correct formatting, code style, accessibility and known vulnerabilities.
TESTING START
Once this is all done, the next step is to deploy your software to an initial environment and run your component integration tests based on mocks or stubs. If those are all successful, then you can set up your pipeline to automatically deploy your software then to the next environment and immediately run all your integration and e2e tests, these of course without the use of mocks and stubs.
For all these steps, as long as nothing fails, the pipeline may continue. Once something fails, the process stops there and this version of the software does not go to production until it has been looked at by a human (and often new modifications have been made).
RELEASE
New modifications will go through the whole process again from the beginning. Do you have any other manual steps in your release process? Then first consider whether they really are necessary steps, and if so, see how you can automate those final steps as well.
What’s important in this setup, by the way, is that rolling back a release should be done quickly and easily by any member of your DevOps team. In the unlikely event that something did go wrong, it is important to be able to reverse it quickly, so as not to lose (or as little as possible) revenue or incur damage. Oh yes, and release we do of course without downtime, if you want to know more about that, please contact us.
