Back 10 years or so when Extreme Programming came out, it began to
change the way that programmers thought about testing. XP made software
developers accountable for testing their own code. XPers gave
programmers practices like Test-First Development
and simple, free community-based automated testing tools like xUnit
made testing cool. Programmers started to care about how to write good
automated tests and achieving high levels of test code coverage and
about optimizing feedback loops from testing and continuous integration.
Instead of throwing code over the wall to a test team, programmers
began to take responsibility for reviewing and testing their own code
and making sure that it really worked. It’s taken some time, but most of
these ideas have gone mainstream, and the impact has been positive for
software development and software quality.
Now Devops is doing
the same thing with release and deployment. People are finding new ways
to make it simpler and easier to release and deploy software, using
better tools and getting developers and ops staff together to do this.
this is a good thing. Because release and deployment, maybe even more
than testing, has been neglected by developers. It’s left to the end
because it’s the last thing that you have to do – on some big, serial
life cycle projects, you can spend months designing and developing
something before you get around to releasing the code. Release and
deployment is hard – it involves all sorts of finicky technical details
and checks. To do it you have to understand how all the pieces of the
system are laid out, and you need to understand the technology platform
and operational environment for the system, and how Ops needs the system
to be setup and monitored, how they need it wired in, what tools they
use and how these tools work, and work through operational dependencies,
and compliance and governance requirements. You have to talk to
different people in a different language, learn and care about their
wants and needs and pain points. It’s hard to get all of this right, and
it’s hard to test it, and you’re under pressure to get the system out.
Why not just give Ops the JARs and EARs and WARs and ZIPs (and your
phone number in case anything goes wrong) and let them figure it out?
We’re back to throwing the code over a wall again.
getting Developers and Operations staff working together and sharing
technology and solving problems together, is changing this. It’s making
developers, and development managers like me, pay more attention to
release and deployment (and post-deployment) requirements. Not just
getting it done. Getting developers and QA and Operations staff to think
together about how to make release and deployment and configuration
simpler and faster, about what could go wrong and then making sure that
it doesn’t go wrong, for every release – not just when there is a
problem or if Ops complains. Replacing checklists and instructions with
automated steps. Adding post-release health checks. Building on
Continuous Integration to Continuous Delivery
making it easier and safer and less expensive to release to test as
well as production. This is all practical, concrete work, and a natural
next step for teams that are trying to design and build software faster.
difference between the XP and Devops stories is that there’s a lot more
vendor support in Devops than there was in the early days of Agile
development. Commercial vendors for products like Chef
and UrbanCode (which has rebranded their Anthill Pro build and release toolset the DevOps Platform
) and ThoughtWorks Studios with Go
, and even IBM and HP are involved in Devops and pushing Devops ideas forward.
is good and bad. Good – because this means that there are tools that
people can use and people who can help them understand how to use them.
And there’s somebody to help sponsor the conferences and other events
that bring people together to explore Devops problems. Bad, because in
order to understand and appreciate what’s going on and what’s really
useful in Devops you have to wade through a growing amount of marketing
noise. It’s too soon to say yet whether the real thought leaders and
evangelists will be drowned out
by vendor product managers and consultants – much like the problem that the Agile development community faces today.