# Software Deployment, Speed, and Safety

DevFeed: [Software Deployment, Speed, and Safety](<https://devfeed.tech/articles/software-deployment-speed-and-safety-12515.md>)

Original publisher: [Read original article](<http://brooker.co.za/blog/2022/01/31/deployments.html>)

Author: Marc Brooker

Published: 2022-01-31T00:00:00Z

Content type: article

Language: en

Sources: [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog.md>), [Marc Brooker's Blog](<https://devfeed.tech/sources/marc-brooker-s-blog-2.md>)

Topics: [Deployment](<https://devfeed.tech/topics/deployment.md>), [Cloud](<https://devfeed.tech/topics/cloud.md>), [Amazon Web Services](<https://devfeed.tech/topics/aws.md>), [Security](<https://devfeed.tech/topics/security.md>), [configuration](<https://devfeed.tech/topics/configuration.md>)

Tags: [aws](<https://devfeed.tech/tags/aws.md>), [cloud](<https://devfeed.tech/tags/cloud.md>), [configuration](<https://devfeed.tech/tags/configuration.md>), [deployment](<https://devfeed.tech/tags/deployment.md>), [safety](<https://devfeed.tech/tags/safety.md>), [speed](<https://devfeed.tech/tags/speed.md>)

## AI overview

This article presents a personal perspective on balancing deployment speed and safety, especially for cloud-based services serving large groups of customers. It discusses tradeoffs involving risk tolerance, shipping frequency, smaller changes, reliability, security, and customer access to new features.

## Source excerpt

Software Deployment, Speed, and Safety There's one right answer that applies in all situations, as always. Disclaimer: Sometime around a 2015, I wrote AWS's official internal guidance on balancing deployment speed and safety. This blog post is not that. It's not official guidance from AWS (nothing on this blog is), and certainly not guidance for AWS. Instead, it's my own take on deployments and safety, and how I think about the space. You'll find a lot of opinions about deployments on the internet. Some folks will say that teams have to be able to deploy from commit to global production in minutes. Others will point out that their industry has multi-year product cycles. It's a topic that people feel strongly about, and for good reason. As usual with these kinds of topics, most of the disagreement doesn't come from actual disagreement, but from people with wildly different goals and tradeoffs in mind. Without being explicit about what we're trying to achieve, our risk tolerance, and our desired reward, it's impossible to have a productive conversation on this topic. This post is an attempt to disentangle that argument a little bit, and explain my perspective. That perspective is clearly focused on the world I work in - offering cloud-based services to large groups of customers. Some of that applies to software more generally, and some applies only to that particular context. I have also used the word deployment here to stand in for all production changes, including both software and configuration changes, and the actions of operators in general. Tradeoffs exist In my experience, software teams are happiest when they're shipping code. That could mean code to production, or to testing, or to validation, but nothing seems to destroy the morale of a team quite a surely as making changes with no end date in sight. Folks want to see their changes have an impact on the real world. It's what I like to see too. Shipping often also sometimes means shipping smaller, better unde