My 2￠ on : Release Process Automation
NB : This is just a 5 min non exhaustive reading..
Lately a customer asked me about :"Automating the release process, targeting CD".
Context
Big company, 4 products, 4 feature/product teams, SCRUM methodology (2 weeks sprints)
Quick reminder (cheat-sheet)
- Release process : moving a software build through different stages and environments (ie : DEV -> TEST -> PRE-PROD -> PROD)
- CI / CD : Continuous Integration and Continuous Delivery
- Automation : basically... a "robot" do the job instead of an human ;)
My 2 cents
It will definitely helps to improve Time-To-Market ! But it will probably requires to upgrade the level of maturity of Release Process
Let's draw a little bit :)
Here is the 5 levels of maturity of a release proces (inspired by CMMI)
Level 0 "Chaos" : Here is a ZIP file with the release inside, good luck bro' !! ??
Level 1 "Documented" : Here is a ZIP file and a readme.txt, you should be able to install ! may the force be with you ! ??
Level 2 "Managed" : The 1.7.4 release package is in the repository, there is a specific install document Install_1.7.4.docx, release notes and Rollback Procedure in the repo ! ??
Level 3 "Scripted" : All you have to do is to run Update_1.7.4.sh script, make sure the result is ok, if not run the Rollback_1.7.4.sh script to go back ! ??
Level 4 "Automated" : the release is scheduled for tonight between 2AM and 3AM, if it fails it will automatically rollback and we will be notified ! ??
Ok, but where to start from ?
- Be honest and evaluate where your are
- Explain the team that you are going to climb a stair-step (ie : communicate)
- Don't go too fast, each stair-step should be "mastered" before considering to move to the next one
Some considerations :
- You should "climb the stairs" step-by-step, it's easier and safer like this
- Buying a tool to make a shortcut is probably not a good idea.. use orchestration tool to climb the last stair-step (from 3 to 4) when you are 100% sure of your scripts
- If you're launching a new product you can choose the stair-step you like (I recommend number 3 - Scripted)
Thanks for reading !
We could write a book on this topic.. but that's it for today ! And don't forget to like, share, comment !
Previous article My 2￠ on DevOps & Microservices
DevOps Engineer na Revolut. Organizador do Meetup DevOps Lisbon
6 年I agree with your point of view, with a little twist.? You cannot automate without a script, you cannot script without knowing what to do (documentation), you don't know what to do if you don't experiment. Automation is a extremely important step in DevOps, but its not the goal. The goal is to bring quality value to our customers as fast as possible.? With that, your approach, and the way you expose it, seem much of a waterfall style. The delivery process should be viewed in a holistic view, from end to end, looking for the slowest moving parts of the system and making optimizations, which should be improved without causing degradation on the rest of the system. That optimization can be done with some extra manual validation, process review, automation, .. There are situations where with some clicks and some human decision is the best way, at that moment, to optimize that process, since it could be very hard and wrong to do through complete automation, and you could be better off investing in the optimization on another part of the system. The first way of DevOps is certainly the most important, but it can be achieved without just thinking in automation.?
Co-Founder and CEO | Official Member Forbes Technology Council
6 年I liked the way you explained the maturity levels. You kept it simple and straight. Good one
Architecte d'entreprise - manager de transition
6 年I disagree with most if the comments. There are cases where step 4 is enough, even for new apps (try automating deployment of a solution including COTS and show me it's worth it $ wise), and the 5 steps are quite nice to pave the way to improving legacy apps deployments. Still it's true that automation should be the initial goal for new bespoke apps, but it's only about 40 % of what a real world ops team manages. So, thanks for sharing, i might reuse it quite often.