| They're a Microsoft shop so it was C#, SQL Server, RabbitMQ
etc running on AWS. What I liked the most about the pipeline: - Speed - we spent a lot of time (as the post says) optimising the process of getting changes into production, and making it as streamlined as possible - Safety - automated testing caught a huge percentage of the issues, meaning we were able to fix them earlier and avoid the turnaround time of finding out later in the process.Tests included visual diffs of many of the pages, approval tests to check contracts and routes didn't change, etc. - Transparency - while there are obviously differing opinions on ChatOps, it was great to be able to scroll back through Slack history on the shipping channel and see a complete record of the pipeline for a particular deploy, seeing the execution of the automated steps interwoven with the conversations of the team members working on it. It was also great being able to see the shipping queue at all times so you could take a look and judge how long it would take to get a change through, and could negotiate with others if you needed to jump ahead of them etc. - Focus on having everyone involved - everybody was involved in reviewing, merging, etc. The aim with a new hire was to get them to complete a change and deploy it to production themselves within their first week. If you were the first person on a "carriage" it was your responsibility to "drive" it and to judge the risk factor, whether to allow other specific changes in the carriage, etc. This meant everyone spent a lot of time thinking about how to reduce risks in their PRs (smaller PRs, more tests, always feature flagging, etc) which was much healthier (IMHO) than having one or two people in the team being responsible for merging or deploying etc and having all the responsibility. Some of it is cultural as well - Just Culture (blameless postmortems etc), being brutally honest (radical candor) and willing to continually refactor processes. |