 |
| "One click" deploy (*) |
I was working on some ideas for him to meet the team and get some insights into our daily work. While most of the company is aware of UI/UX and front-end changes we are doing to our site, some of the back-end and infrastructure work can seem like black magic. I think it is important to take every opportunity to bring this output closer to the rest of the company and especially the leadership.
By chance I watched the very good presentation “Getting Real about Managing up” by Kellan Elliott-McCrea, which contains as one example the idea of letting your CEO deploy to production.
One of the goals of our engineering team is continuous deployment. I set this out when I joined Devex to give us a far goal to aim for. I was inspired by Etsy’s Code as Craft blog and the book “Web Operations”. For me the important part was not continuous deployment itself, but all the changes in engineering culture required to achieve it. You need a good technical base from unit to integration tests, infrastructure as a code, continuous integration and a infrastructure team that is working side by side with the developers.
At the beginning this seemed to be an impossible task, QA and deployment were completely manual, there was no unit testing, no code reviews, a clear separation between developers and operations. The code itself was a mess too, with lots of moving parts, outdated libraries and no easy way to introduce testing.
But we slowly made progress, simplified the system and slowly worked our way up from deploying once in a blue moon, to once, then twice a week.
Currently we are at one deploy a day, with some manual involvement of QA. The deployment gets kicked off by a chatbot and is well documented in our engineering handbook.
The short version looks like this:
- Check QA status
- Tell the chatbot to deploy
- Check the metrics
Our CEO Raj Kumar was happy to do it and sat together with our two infrastructure engineers to help him along. Because there are some permission requirements it was also easier to do it from the workstation of our lead engineer.
After some hiccups in QA the progress went smoothly and we had a new release in production.
I guess in the end he was surprised how boring it turned out to be. Which a deploy should be.
btw: we are hiring: Check out our current open positions
*) the hat is part of the deploy protocol and not a fashion statement