Welcome!

Open Source Cloud Authors: Liz McMillan, Zakia Bouachraoui, Pat Romanski, Elizabeth White, Yeshim Deniz

Related Topics: Microservices Expo, Java IoT, Microsoft Cloud, @CloudExpo, Cloud Security, FinTech Journal

Microservices Expo: Blog Post

Continuous Deployment: Are You Afraid It Might Work?

You deploy more often than you think!

Continuous Deployment

This is a republished blog post by Aaron Nichols. You can find Aaron's original article on his blog where he talks about Web Operations, Culture, Security & Startups. If you want to get in touch with Aaron you can find him on twitter!


I've been wondering for a few years now, why it's so hard to get companies to prioritize the work that I feel is important. I mean, I'm telling you how to do it and you aren't listening - don't you want to build quality software?

Would you listen to that argument? I wouldn't. Everybody has an opinion about how to do things, what makes one better than another?

I think you should listen to me, but that's irrelevant
I'm on my 4th SaaS company at this point. I'm starting early this time and hoping to steer things in the right direction. I feel like I've observed some good and some bad and some really ugly at this point and I have a pretty good idea of what patterns and anti-patterns are important. The problem hasn't changed though, just because I feel they are important doesn't make them a priority for the company.

When I go to work for a new company a very important question to answer is whether the company is ready and willing to implement all the cultural and technical requirements for Continuous Deployment. I've at least figured out that, from my position, it's exceptionally hard (so far impossible for me) to convince a company they want to do this - they have to already want to. I know how to implement, I know how to enact change, but I need support that has to already exist.

I focus on Continuous Deployment not because it's a technical solution that you just plug in and go. I focus on it because it drives conversation around all the other areas where organizations should improve. For each improvement you make working toward Continuous Deployment, you make your development process better and your software better. These aren't things that only provide benefit once you are doing Continuous Deployment - but when you've done them all it becomes a fairly easy decision to deploy continuously.

I'm early into my latest venture but already the attention is there, the interest in doing this right. I'm being asked for my thoughts on what we need to prioritize to move toward Continuous Deployment, what do we need to focus on early so that it's easier later on. I'm also being asked to educate folks on what is important and why, what have I watched work and what have I watched fail. What mistakes can we avoid and what mistakes are we just going to have to make on our own?

Oh, you were hoping not to make mistakes? Good luck with that. The best I can hope for is to make my own mistakes.

Dude, I would never do that...
My first flight on an airplane, in my life, was a skydiving trip. When the instructors discovered this as we ascended toward altitude they said "Well this is perfect, next time you fly you can tell the person next to you that you've flown before, but you've never landed". My risk tolerance may differ slightly from others. I like to rock climb as well, plenty of people won't do that. The thing is, both of these sports involve a very risky activity offset by copious amounts of safety. Still, when you watch the girl up on the cliff hanging by a limb all you can think of is "what if she falls?". The answer is, she'll get a little bruised up maybe, but if she's doing things right she'll keep right on climbing.

When you've been climbing a bit, when you understand the safety mechanisms, you pay much more attention to the climb, to the technique, to each movement. You know that the climber is probably safe, because you know what keeps them safe. You can take more risk with each movement knowing that any single mistake will only set you back so far.

These activities, like Continuous Deployment, look more risky from the outside than they are. If you don't take the time to understand all the safety mechanisms then you can't accurately evaluate the risk. For a company who pushes software every few weeks to consider pushing every commit without substantial other changes would be insane. Just like I would never go rock climbing without the right equipment (I'm allergic to free soloing - sorry). The act of Continuous Deployment is a realization of a ton of other effort - and all that effort has to be prioritized before you can ever get on the rock face.

Reality check - you are deploying more often than you think
Let's say you deploy every week - I'm being generous here, but let's just pretend. So you deploy on Thursday during the day because you have an awesome deploy process and you know it's better to spot problems when everyone is in the office. You spot a problem, what do you do? I'm guessing your deploy was from a branch, so you just fix that branch & deploy. Then you merge the fix into master.

Friday comes along, hey there's another critical issue. Fix, branch, deploy. Lather, rinse, repeat. Meanwhile, depending on how involved the fix is and what other stuff you have going on, you've got a bunch of merging to get right and the closer to your next branch you get, the more of a problem this becomes. How about a fix on Wednesday before the next deploy? I'm guessing you've already cut the next branch, so now you apply the fix to three branches (last week, this week, master).

All this deploying and merging and branching, it's all work. The problem is - it's not automated work, it's work asking for mistakes to be made. It's risk. Where are your safety mechanisms? Are they your manual testers? Your automated test suite? If those automated tests aren't good enough to test each commit before it goes to production, why are they good enough to test each week's deploy? Because you do manual testing?

This all sounds risky to me, but for some reason it sounds less risky than Continuous Deployment to some. I think this can only be because of a lack of understanding around the safety mechanisms, the prerequisites. The proof is in the pudding though, and if you still produce shitty software when doing Continuous Deployment because you write bad tests and don't do retrospectives and don't prioritize the important work of making the system work right - then you're sunk either way.

There are some companies that are probably better off deploying every 8 weeks.

Wrapping up - why so much focus on Continuous Deployment?
The practices that surround Continuous Deployment/Delivery substantially reduce risk - things like Feature Toggles, automated testing, automated deployments, deploying off master, retrospectives, monitoring, accountability, access, ownership, reduced MTTR, and the list goes on. These all add up to make a software development and deployment environment so safe, anyone can commit code - if it doesn't work it will not make it to production.

But, things will still break. In my experience you have to break things in very subtle ways for code to get into production & as time goes on and you build better monitoring, even those issues should be detected fast and resolved fast.

It can take a while to reach the end goal, but you've got to start somewhere. However, even if you never actually practice Continuous Deployment, all of these practices will produce better software and probably happier developers.

Codeship - A hosted Continuous Deployment platform for web applications

Further Reading

Here are a few other good resources to learn about Continuous Deployment/Delivery


We want to thank Aaron for making his original article available to us. I might add that - of course - our very own Codeship blog is also a good resource to learn about Continuous Deployment ;)

Also check out our Codeship Xmas Countdown! New freebies, interesting articles and tutorials everyday throughout the Christmas time!


Download Efficiency in Development Workflows: A free eBook for Software Developers. This book will save you a lot of time and make you and your development team happy.

Go ahead and try Codeship for Continuous Integration and Continuous Deployment! Set up for your GitHub and BitBucket projects only takes 3 minutes. It's free!

More Stories By Manuel Weiss

I am the cofounder of Codeship – a hosted Continuous Integration and Deployment platform for web applications. On the Codeship blog we love to write about Software Testing, Continuos Integration and Deployment. Also check out our weekly screencast series 'Testing Tuesday'!

IoT & Smart Cities Stories
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...