https://puppetlabs.com/blog/continuous-delivery-devops-jez-humble-its-all-about-the-customer/
via feedly.com
If your technical team is talking about and working towards continuous delivery, you should tip your fedora to Jez Humble. The co-author (with David Farley) of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation, and principal at custom software house ThoughtWorks, Jez is one of the leading thinkers driving big changes in software development.
Jez also contributes to the thinking around DevOps, a term he thanks Patrick Debois for inventing just in time to be included in the book (published in 2010). Commonly described as a cultural movement, "DevOps is much of the 'how' of achieving continuous delivery," Jez said.
Jez will be speaking at PuppetConf 2013 about what it means to have a DevOps mindset, and what you can do to grow a high-performing organization. I sat down with Jez at DevOpsDays Mountain View last month to talk about why continuous delivery matters, and how DevOps can help you achieve it.
Continuous Delivery Helps Everyone
Continuous delivery offers great benefits to both business and technical people within an organization. The core concept of making small frequent changes, and testing at every step, reduces the risk inherent in deploying new code. From the business point of view, continuous delivery allows a company to discover more quickly just how well a new product or feature will work.
"When a C-level person approves a project and analysts come up with a big list of requirements, these aren't really requirements – they are guesses, or hypotheses," Jez said. No one really knows yet if the product will actually address the needs of its target customers, whether internal or external. "That's where continuous delivery comes in; it makes it more economical for you to run lots and lots of experiments."
Continuous delivery goes hand in hand with Agile, the method of developing software in small increments. Agile was a reaction to the waterfall method of developing software, the long-term de facto standard. Developers working the waterfall way write lots of code over longer periods before testing.
While this method seems to make intuitive sense – you need to build a fairly complete system before testing – there are known pitfalls. A big one: When the completed code is "tossed over the wall" – that is, passed on to IT operations for deployment – it usually doesn't meet the needs of operations.
"It's hard to monitor, there's no facility for archiving data, the log messages are useless, and it's not designed to degrade gracefully under high load or unexpected failures," Jez explained.
With continuous delivery, you create, test and deploy code in much smaller increments, making it easier to identify which changes break the system. "You get quality because you test more often, and catch bugs when they're small and cheap to fix," Jez explained. The result: better, more consistent code quality.
Developers also find continuous delivery a more satisfying framework. "They're motivated because they get done with stuff, and they get feedback," Jez said. It adds up to less frustration for developers, and more of their time freed up to be creative.
Continuous Delivery Requires a Shift in Attitudes
While continuous delivery sounds like a dream come true, there can be pushback from developers who believe the hand-crafted, unique solution is always best.
"Developers can have a bias – you want your solution to be perfect," Jez said. But it makes a lot more sense to make sure whatever you're building is valuable before putting a lot of time and effort – expensive time and effort – into building a perfectly crafted, fully featured solution.
Developers who are used to creating more code over longer cycles may also not know how to work in small increments. "The trick is to do the smallest possible amount of work to create the experiment that produces meaningful data," Jez said. "Even if you're not releasing frequently, you still have to behave as if it's valuable to work in increments, and as you write code, create tests that will ensure you don't create regressions as you move forward."
What We Talk About When We Talk About DevOps
The increasing adoption of continuous delivery is really driven by the movement of so many products, services and business models to the web. That also explains why DevOps has become so important over the last few years, Jez said.
"Part of the work of operations is to provide developers the tools they need to validate whether the changes they're pushing are safe," a concern that's even more important when your code is available to any and all on the web, at all hours of the day or night.
Without a culture that emphasizes active collaboration between dev and ops, continuous delivery becomes very difficult – if not impossible. You can't toss frequent, incremental changes over a wall; in fact, IT ops people should be included early in the software design process to make sure their needs are considered.
"Developers need to treat operations as customers of the systems they build," Jez emphasizes. After all, it's IT's job to maintain these systems for the good of the entire organization.
While culture change is not simple, the transition can be eased considerably by keeping in mind that the goal of DevOps is the same as it always has been for people who care about quality code, Jez said. "To quote Damon Edwards, it's about creating measurable customer outcomes."
Learn more about continuous delivery and DevOps:
- Get More Agile: Learn How To Automate One Small Thing with Puppet Enterprise
- Continuous Integration for Your Puppet Code (video)
- Learn more about DevOps today. Download our 2013 State of DevOps report.
- Busting Silos: Aligning IT, Dev & C-Suite
No comments:
Post a Comment