Good article. I want to offer my thoughts on a couple of things from my personal experience. > If the change deployed is small, there is less code to look thro

Good article. I want to offer my thoughts on a couple of things from my personal experience. > If the change deployed is small, there is less code to look through in case of a problem. If you only deploy new software every three weeks, there is a lot more code that could be causing a problem. That's relative. Pushing out an accumulated amount of small changes once a week will most likely have the same end the result. The difference is, if you commit more than one breaking change you are dynamically expanding the window of service degradation. One release with three breaking changes is better than three broken pushes. > If a problem can’t be found or fixed quickly, it is also a lot easier to revert a small deploy than a large deploy. It is also harder to revert two non-consecutive deploys out of three. > If I deploy a new feature as soon as it is ready, everything about it is fresh in my mind. So if there is a problem, trouble shooting is easier than if I have worked on other features in between. Personally, I favor stability vs. easier troubleshooting. This works for some products and not others. > It is also frees up mental energy to be completely done with a feature (including deployed to production). Anecdotal evidence, but my team would usually catch and correct bugs when they have to come back to green light a production push. Engineers that ship clean and fast are rare. > All things being equal, the faster a feature reaches the customer, the better. Having a feature ready for production, but not deploying it, is wasteful. Something like this would usually be pushed out manually to align with other non-engineering parties within your company. Pushing broken features to the customer faster is not a good thing. Unless you can assume 100% success rate; which is not possible. > The sooner the customer starts using the new feature, the sooner you hear what works, what doesn’t work, and what improvements they would like. This depends on the stage of the company, the product, and your customers. > Furthermore, as valuable as testing is, it is never as good as running new code in production. The configuration and data in the production environment will reveal problems that you would never find in testing. All of the environments I govern match production 1:1 (sans data sanitation) in every way possible. I feel pretty strongly about this, if you can't test your code without pushing it into production, you should not be automating anything. > Continuous delivery works best when the developers creating the new features are the ones deploying them. There are no hand-offs – the same person writes the code, tests, deploys and debugs if necessary. This quote (from Werner Vogels, CTO of Amazon) sums it up perfectly: “You built it, you run it.” Don't compare a start-up to Amazon. Amazon has dedicated teams to govern the process and you most likely not replicate that. Also, hiring people that 'just send it' without doing damage takes money, time and a lot of training. It's expensive.