“End to end visibility is the way to get confidence in your ability to react. Adopting a DevOps culture is the only way to get that true visibility. This also makes for much happier employees” says Ken Mugrage
Ken Mugrage, is conducting a workshop titled “Building Continuous Delivery Pipelines” on March 11, 2018, as a part of Post Conference Workshops at the Agile India 2018 Conference. Ken will present a talk titled “It’s Not Continuous Delivery if You Can’t Deploy Right Now“. When the AgileIndia2018 team interviewed Ken, he shared more insights about DevOps and Continuous Delivery.
What is “DevOps Culture” according to you? What are the challenges that the organization can face to bring in that culture?
More than anything I think of DevOps as a culture of sharing. Teams are sharing not only the challenges but the celebrations of success. Teams have common goals aligned with business needs. For example, the team would only measure something like “uptime” if that’s important to the business. If it is, then everyone is measured on it. In this way the code is architected, tests are run and all of the other activities would be aligned to improving that metric. What we need to avoid is measuring one group (say traditional ops) on uptime while another group skips redundancies because they are being measured on something like the number of tasks completed. For many organizations, this is a fundamental shift in thinking.
What are some common misconceptions that people have about Continuous delivery and DevOps?
The most common misconception is when people think of Continuous Delivery and DevOps as job roles or tasks to be done. Created a “DevOps” department or job role and assigning those people tasks around things like deployment automation is not the same thing. For example, from a Continuous Delivery perspective… The CD pipeline’s job is to build every change to your systems and then run it through a gauntlet of tests. If all of the tests pass, then the pipeline can deploy that build to users. It’s easy to make all of the tests pass by simply not writing enough tests. This may make the status pages look good, but it’s a recipe for disaster. Instead, the team should be working together to make sure that the pipeline is rigorous as possible. Put another way, it’s the job of a CD Pipeline to prove that a build is not good enough for production.
From an industry point of view, what is the value of practicing continuous delivery and adopting DevOps culture?
There are a many, some direct and some indirect. If you have a solid continuous delivery pipeline which builds confidence in your deployments, you are free to deploy more often. While this in itself should not be a goal in my opinion (it’s a metric, but the Chief Financial Officer doesn’t care how many times you deployed) it enables other goals. For example, instead of debating a small change for weeks, go ahead and try it with real customers. You can get the change deployed quickly, measure its effect on your business, and then either continue down that path or change direction if it didn’t work. Adopting a DevOps culture is the only way to get true visibility from end to end. That visibility is the only way to get confidence in your ability to react. This also makes for much happier employees.
What are the key takeaways from your talk titled “It’s Not Continuous Delivery if You Can’t Deploy Right Now “?
The talk is very high level. It’s meant to encourage testing and coding behaviors that are vital, and yet not often seen. It’s relatively easy to “deploy right now” if you just don’t have a lot of tests. But that’s not safe. I’ll encourage people to include security, performance and many other types of testing, development teams are used to including. I’ll show ways to make sure every test is run on every deployment. At the end of this talk, attendees should have a good understanding of the things they need to implement in their own CD pipelines to enable them to deploy at will.
What are the key takeaways from your workshop titled “Building Continuous Delivery Pipelines”?
The workshop is mostly hands-on building an actual CD pipeline using GoCD. The lessons learned during the workshop could also be applied to other tools, but we use GoCD because it’s the one we’re most familiar with. Attendees will get an overview of a CD pipeline and recommended practices. Over the day, lecture and labs will be mixed so that when complete attendees have a fully operational pipeline which runs various types of tests, includes parallel processing and a promotion strategy.
More About Ken Mugrage
Ken Mugrage started his IT career as a system administrator for Seattle’s first internet service provider in the early 90s. He went on to form his own web development company in 1994, creating some of the first data-driven websites anywhere. Ken went on to hold almost every position in a software development organization over the next 20+ years, from developer to director of a global engineering team. Using this experience, Ken has consulted with top companies on applying the right technical solutions to business problems. Ken is currently a Technology Evangelist for ThoughtWorks, focused on providing education on DevOps and Continuous Delivery.
To register for this workshop click here. Click here to learn about all talks and workshops that Ken will be conducting.
