This is the third in a series of interviews on continuous delivery, this time with Elisabeth Hendrickson. You can see the first one, with Jesse Robbins, on the ThoughtWorks Studios Blog, and the second, with John Allspaw, here. These interviews will eventually be put together – along with some additional exclusive material – into a set of LiveLessons, with the royalties going to Black Girls Code. If you want to be notified when the final product is released, please sign up for my newsletter.
Elisabeth has held positions as a tester, developer, manager, and quality engineering director in a variety of companies ranging from small startups to multi-national enterprises. She has been a member of the Agile community since 2003, served on the board of directors of the Agile Alliance in 2007/2008, and is currently one of the co-organizers of the Agile Alliance Functional Testing Tools program. Elisabeth won the prestigious Gordon Pask award in 2010 and is the author of two books: There’s Always a Duck and the forthcoming Explore It! Reduce Risk and Increase Confidence with Exploratory Testing published by the Pragmatic Programmers. She is the founder of Quality Tree Software, runs Agilistry Studio, and is the creator of entaggle.com. You can find her at testobsessed.com and @testobsessed
In the video, Elisabeth answers the following questions:
What’s been your experience of the evolution of the testing and QA role in the IT industry?
Why doesn’t separation of duties between engineers and testers work? (01:49)
What are the problems with the hierarchies you sometimes see within testing organizations? (04:30)
What’s wrong with the approach of writing and executing manual test scripts? (07:53)
Does record and playback help to solve some of these problems? (08:48)
So the current paradigm for building quality in to software is acceptance-test driven development. Talk us through ATDD. (10:04)
What does what in ATDD? (11:19)
What proportion of time is spent on production code vs test code? (14:15)
How do you get from a typical “enterprise” testing strategy to ATDD? (17:30)
When implementing automated acceptance tests, where do you start? (21:31)
How has continuous deployment changed the way you approach software delivery? (23:43)
How do you go from releasing once every 3-6 months to releasing once a day? (26:36)
Brilliant and unwavering product vision from a few amazing folks going to market infrequently with huge ceremony.
That seems to be the exact opposite of what both lean startup and continuous delivery preach. It’s hard to know what happens behind the scenes at Apple because of their notorious secrecy about their product development process. Furthermore, there’s no way of knowing if the information we do have accurately represents what really goes on there. But if we look at Apple’s history, there are a couple of examples that strongly suggest that the principles behind continuous delivery and the lean startup were very much in play in Apple’s early years.
This is the second in a series of interviews on continuous delivery, this time with John Allspaw, one of my co-authors on the Devops Cookbook. You can see the first one, with Jesse Robbins, on the ThoughtWorks Studios Blog. These interviews will eventually be put together – along with some additional exclusive material – into a set of LiveLessons, with the royalties going to Black Girls Code. If you want to be notified when the final product is released, please sign up for my newsletter.
John Allspaw has worked in systems operations for over fourteen years in biotech, government and online media. He started out tuning parallel clusters running vehicle crash simulations for the U.S. government, and then moved on to the Internet in 1997. He built the backing infrastructures at Salon, InfoWorld, Friendster, and Flickr. He is now SVP of Tech Operations at Etsy, and is the author of The Art of Capacity Planning and Web Operations published by O’Reilly. He blogs at kitchensoap.com
In the video, John answers the following questions:
What is devops? Why now?
What did Flickr do differently that worked? How did you apply that at Etsy?
How did you take Etsy from painful releases to continuous deployment?
How about larger organizations? Does continuous delivery impose more risk?
What’s the role of operations in an organization that wants to practice devops?
Is there still room for specialization in the devops model?
What advice would you give developers who want to do continuous deployment?
How do you reduce the risk of releases?
How do you create resilient systems on the web?
How do you deal with databases in the world of continuous delivery?
Translations:中文 | 한국말
There’s a lot of dogma in the religious wars around software development practices and methodologies. Are phase-gate methodologies effective at managing the risk of software development, or just risk management kabuki? Does TDD really make for higher quality software? Is pair programming a superior replacement for code review or just a way to inflate consulting rates? I’m going to argue that while scientific evidence to decide these claims is lacking, there are two general principles which can help us choose good practices while at the same time improving the value of the software we deliver: reduce cycle time and increase feedback.
There’s been a lotof controversy generated by Voke’s Agile Realities report. SDTimes asked me to comment for their article covering the report, and so I got to read it in full. Obviously Voke want your money to read the whole thing so I am constrained by fair use as to what I can reproduce in this review, but my general conclusion is that the report represents a hatchet job on agile whose most important conclusions aren’t sustained by the (interesting and revealing) data they have gathered.
At DevOpsDays Mountain View I was lucky enough to get some time with Michael Rembetsy, Director of Operations Engineering at Etsy, which manages to be PCI-DSS compliant while practicing continuous deployment. In this short interview, he describes how they do it.
Here are some of the key points from the interview:
Etsy deploy to production 25-50 times a day;
They built a new, segmented PCI-DSS compliant environment for their payment systems – “we built a whole separate Etsy, essentially”;
Segregation of duties doesn’t mean people can’t talk to each other. In fact, collaboration is an essential element of effective risk management. So everybody in the PCI environment still follows devops principles – there’s no physical separation of the teams, and Etsy have hired more people into the various roles (dev, sysadmin, dba, manager, networking) to facilitate collaboration;
In the payments environment they “still have to follow the rules: a developer still doesn’t have access to a production database”, but they’ll have dbas working alongside them who they can ask for help, and graphs showing metrics from the database;
They use a similar deployment process in their PCI environment to their non-PCI environment, but it includes much more logging on who did what when, and they have roles for QA pusher and production pusher;
Developers can run most of the test framework in their PCI development environment, and they have access to production logs via Splunk in read only mode;
They have a ticketing system that all changes have to go through, but they can push out a change from dev to production in less than an hour if necessary with their normal, non-emergency change management process;
Final words of advice: “Make sure that the team is on board and realizes that yes, there’s going to be some constraints, but … if you all work together you’re going to be able to continuously deliver the product that you want even into a secure environment.”
One key goal of continuous deployment is to reduce the risk of releasing software. Counter-intuitively, increased throughput and increased production stability are not a zero-sum game, and effective continuous deployment actually reduces the risk of any individual release. In the course of teaching continuous delivery and talking to people who implement it, I’ve come to see that “doing it right” can be reduced to four principles:
Continuous delivery is a software development strategy that optimizes your delivery process to get high-quality, valuable software delivered as quickly as possible. This approach allows you to validate your business hypothesis fast and then rapidly iterate by testing new ideas on users. Although Continuous Delivery focuses on engineering practices, the concept of continuous delivery has implications for the whole product-delivery process, including the “fuzzy front end” and the design and analysis of features.
When implementing continuous delivery, it’s easy to focus on automation and tooling because these are usually the easiest things to start with. However continuous delivery also relies for its success on optimizing your organizational structure for throughput. One of the biggest barriers we at ThoughtWorks have seen to continuous delivery is teams organized by role or by tier, rather than by business outcome. In this post I’ll address the root cause of this problem, and how to overcome it.
I like to say that feature branches are evil in order to get people’s attention. However in reality I lack the determination and confidence to be a zealot. So here is the non-soundbite version.
First, let me say that Mercurial (and more recently Git) has been my workhorse since 2008, and I love distributed version control systems. There are many reasons why I think they represent a huge paradigm shift over existing tools, as discussed in Continuous Delivery (pp393-394). But like all powerful tools, there are many ways you can use them, and not all of them are good. None of my arguments should be construed as attacking DVCS: the practice of feature branching and the use of DVCS are completely orthogonal, and in my opinion, proponents of DVCS do themselves – and the tools – a disservice when they rely on feature branching to sell DVCS.