Key Takeaways from Continuous Discussions (#c9d9) Episode 46: Deployment Automation 2.0

On this episode of our Continuous Discussions video podcast, our expert panel included: Juni Mukherjee , author of Author of “Continuous Delivery Pipeline – Where Does It Choke?”; Martin Cron , principal engineer at WiserCare; J. Paul Reed , an internationally recognized speaker on DevOps, release engineering, and operations complexity; Robert Firek , software craftsman at Codurance, plus DevOps engineer, Java programmer and Agile practitioner; Taco Bakker , a LEAN Six Sigma black belt focusing on CD; and our very own Anders Wallgren and Sam Fell . During the episode, we discussed must-have’s for deployment automation, advanced deployment patterns, Docker orchestration and what automation 3.0 looks like.

»Must-Have’s for Deployment Automation

 

"You don't want your production deployment to be the first time you are doing it" advice per @anders_wallgren #c9d9 pic.twitter.com/Ltdeyyaw3L

— CloudBees (@electriccloud) July 26, 2016

You have to get to production otherwise you are wasting time and money - figure out how to get there in a predictable way @samueldfell #c9d9 — CloudBees (@electriccloud) July 26, 2016

In Deploy 2.0 scenario, you start to reuse stuff and create a culture of automation | @tsbakker65 #c9d9 #Agile2016 pic.twitter.com/1sDtFNe8Yq

— CloudBees (@electriccloud) July 26, 2016

Tooling and processes are not the most interesting factors in automation says Reed : “What’s more interesting to me is the human factors of automation. I work with start-ups who say they are still going to do things manually because they need to get it out and don’t have time to automate it. For Automation 2.0, there’s enough data out there now where businesses are starting to say ‘We need to invest in automation,’ so it’s not a technical or tooling conversation.”

Firek  views automation as a triangle containing three main parts: “When I think about automation I see a triangle. you can't do any manual steps. When you do manual steps it is painful for everyone and you can't do whatever you want because you can't repeat it. The other thing in this triangle is ‘rapid response’- you have to be able to deploy anything, and you can't wait for approvals for weeks, for days, even hours, because when you have to make changes you have to do them rapidly and now. The most important part of this triangle for me is ‘team effort’ - you have to do together with your team. If you don't have the right culture around automation and the right culture around rapid response it's painful. You want to have a team that is ready to deploy something automatically and work together to automate and improve all the time.”

What is a major difference between Automation 1.0 and 2.0? Bakker explains: “What I see in Automation 2.0 is that you start to reuse stuff. In 1.0, it is basically every man for himself, it’s just automating whatever they were doing in pretty much the way they were always doing it. In 2.0, you get more of a mindset for Continuous Delivery. You have to learn from each other – if someone already defined how to deploy a token application, you should say ‘Let’s just reuse that,’ which then increases the pace in which you can automate stuff.”

Mukherjee expands on advice she has taken from Martin Fowler on Continuous Delivery and automation: “The bits and bytes should roll silently from source code to production and there is this pipeline that takes it through. You enable it, you don’t actually do any execution as humans - you decide how it is done and when it is done, but you don’t actually do it.”

»Advanced Deployment Patterns

 

"Deployment should be seen and not heard" - @samueldfell | #c9d9 — CloudBees (@electriccloud) July 26, 2016

When Dev teams are left out of #Scrum , they have less understanding of the product - @JuniTweets #c9d9 pic.twitter.com/7oh3zP5GZR

— CloudBees (@electriccloud) July 26, 2016

Advanced deployment techniques - you shouldn't let them get in your way, says @martincron | #c9d9 pic.twitter.com/yWvd7Gg43q — CloudBees (@electriccloud) July 26, 2016

Mukherjee “When you treat configuration like first-class citizens, only then can you have your deployment product succeed because your product depends on the deployment configuration being right. Coming through the pipeline, you should have the features, tests for the features and configurations for the features, tests and the environment.”

According to Reed , these advanced patterns aren’t really all that advanced: “What makes advanced is you have to start incorporating all these things that we used to maybe not care about so much. For instance, versioning. A product we see on a website is probably a number of versions of different components put together. But, to do that, you have to care about versioning and that’s something for a long time we didn’t care about. What makes it complex is the advanced interactions within the socio-technical system”

Cron advises not to let the advanced patterns get in the way of automating your pipeline: “Advanced techniques are by definition advanced techniques but you shouldn’t let them get in your way. Just because you can containerize everything, or do some things that are relay advanced, that shouldn’t hold you back from doing things in a straightforward way. Automation is something that is useful for everyone and even automating a small part of your pipeline is an incremental step.”

Think about what deployment patterns make the most sense for your business, says Firek : “These patterns have to express what you are actually doing in the business context. When I take a look at the patterns I always try to ask "Do we need this?" Because if we don't need blue/green we shouldn't use rolling deployments, instead let's just sit down together and think. This is the most important thing - understanding what you are doing. It's so easy to over-engineer something. When you over-engineer you’re just stuck with some kind of new legacy code and you think that its better when it's not better.”

»Docker Orchestration + Automation 3.0

  Firek on Docker and the Cloud: “Docker gives us the ability to realize how we can use the Cloud. Before, the Cloud was just cheap computing power and now we understand that it's not only cheap, it's also a power that we can have on demand, and when we combine Docker and the Cloud together we can create some kind of always adapting system.”

Do what is best for your own business, advises Bakker : “You should always automate what makes sense, but also challenge the current status quo. One of the key things in Deployment Automation 3.0 is do not just assume that the traditional way you are distributing and installing software or existing hardware is right. Maybe there is a better way for your specific situation that might increase the pace that you can deliver your software. Maybe it’s a container, maybe it’s a virtual machine – look where it makes sense to go in a total different direction and start to deploy in a totally different way.” Ops and dev teams should both be involved in the automation process, says Cron : “I like to treat the automation code and infrastructure code, as first-class citizens. It’s not just something the ops people work on, it’s something that every dev does as part of their job every day. Not every team has that luxury but it makes a huge difference of knowing the deployment will work in production because it worked on my machine, and it worked on the workspace environment, and validation environment, and on this other environment.”

Mukherjee explains that immunity and self-healing are a part of Automation 3.0: “For Automation 3.0: immunity and self-healing. Immunity is the human system. For instance, I might catch a cold, but the anti-bodies build up and I become stronger – this can happen to the pipeline just like it can to a human. You have initial failures – test, configuration, features – but if you increase the feedback, you increase your immunity and will fail less. There also needs to be self-healing. For instance, if you have failed even after all the learning we can have different patterns to self-heal so nobody has to intervene. A failure does not necessarily require a manual intervention – we can teach it to self-heal.

IoT will play a big role in the future of automation, according to Reed : “If we buy the argument that the shift from 1.0 to 2.0 is understanding the patterns and making a cultural shift within the organization, I think we will see from 2.0 to 3.0 IoT come into play, because IoT is actual stuff in our lives like in our refrigerator or our car. We’re going to have to reexamine some of the assumptions that we make. In 3.0 when we are deploying things that matter, like Tesla autopilot, do we really want anyone to be able to update that over the air?”

Watch the full episode here:

 

---

Want more Continuous Discussions (#c9d9)?

We hold our #c9d9 podcast every other Tuesday at 10 a.m. PST. Each episode features expert panelists talking about DevOps, Continuous Delivery, Agile and more.

---

The fast-track to bullet-proof deployments

Want to get Deployment Automation right? Download the free community edition of CloudBees Flow , to easily model and deploy your applications, in a fast, predictable and safe way!