Jez Humble: On DevOps, Cloud Impact, and Go Being Years Ahead of Other Tools

DZone 's Guide to

Jez Humble: On DevOps, Cloud Impact, and Go Being Years Ahead of Other Tools

· DevOps Zone ·
Free Resource

DZone got a rare opportunity this month to interview Jez Humble, the co-author of Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation.  The timing was perfect since Jez's company, ThoughtWorks Studios, has just released Go 2.2—the next version of their release management software (which comes in a free community edition and a commercial edition).  One of the big changes with the Go 2.2 release was the removal of a required license for the community edition.

Here were the questions from my interview with Jez:

DZone:  Are the solutions from ThoughtWorks Studios making more connections for interoperability with open source ALM and deployment tools?
Jez Humble:  Having an open platform is a key part of our philosophy. Go can run any tool through the command line, and store the results in an artifacts repository for further processing. We expose our entire internal data model through Atom feeds. Any action you can perform through the UI you can also perform through a simple REST interface. Go's artifacts repository is accessible via HTTP. Our API is fully documented. We want people to use our tools because they're the best available, not because we've locked people in. We recognize that Go will always form part of an ecosystem, and we have stuff on the roadmap to increase the integration that's possible with other tools, both open source and otherwise.
In some ways, do you feel that having a Scrum team is a prerequisite to having a DevOps work system?  If you're already *really doing* something like Scrum with a multi-disciplinary team (devs, testers, UX, DBA etc.) then DevOps just simply adding a multi-disciplinary sysadmin to that team?
I think agile methodologies in general, and probably XP even more than Scrum, have always emphasized multi-disciplinary teams. And I certainly think that if you're already doing that, then devops might not be a big deal. However in most medium and large organizations project teams simply aren't allowed to push stuff live, for compliance reasons amongst other things. So I think that adding a multi-disciplinary sysadmin to the team is a good move, but in most cases it's not going to get you all the way there.

One other key element is the ability of teams to self-service their own infrastructure, whether that's through the cloud or through some other infrastructure-as-code mechanism.  I think one of the best models for this is Amazon. The biggest obstacle is usually cultural though rather than technological, and a big part of that is convincing people that automation and collaboration is a more effective mechanism for managing risk than heavyweight change management processes. We still have some way to go here, and I think that the devops movement's focus on culture is spot on.
DZone:   Does a tool like Go (and Mingle and Twist) alleviate some of the need for multi-disciplinary knowledge by different parts of the software production team?
Jez:  I don't think so. I think they do a good job of shining a light on where your problems are, and making your constraints very visible. But it's naive - and all too common - to think you can solve organizational problems through tools. Go, Mingle and Twist definitely do an outstanding job of helping you adopt better practices - that's why we created them in the first place.
DZone:  Do you think a movement like DevOps will fade if more enterprises start using Clouds (IaaS, PaaS) for their software production? 
Jez:  I definitely think that enterprises will move towards using *aaS, and I think that's entirely consonant with devops. However that's not the whole story. Development teams will have to learn how to create and manage production-ready systems, and learn how to continuously deliver functionality. That requires excellent automated testing at all levels, and the application of patterns such as branch-by-abstraction, feature bits, and a production immune system.

So I think that while technology and tools are a necessary condition of achieving reliable, high quality, maintainable systems, they're not sufficient. You also need a good culture - particularly discipline and the ability to reflect upon and improve your process - and good software development practices. That's why devops, continuous delivery, and the software craftsmanship movements are important. We also need to focus relentlessly on our users, which is where the lean startup people are doing some interesting and important work.
DZone:  In your 2010 interview with Julian Simpson you said you TWS had some "innovative stuff" planned that you would keep secret for now.  Is there anything you'd like to reveal yet?  Or anything that has been revealed since then?
Jez:  Well since that interview we released Go 2.0, which included support for managing environments and providing end-to-end traceability from deployment back to source. We just extended that all the way through to requirements, since with the releases of Go 2.2 and Mingle 3.3 you can compare any two deployments or builds and see all the stories completed and bugs fixed between them. That means, for example, that you can automatically generate release notes. You can do this whatever your project structure in Mingle, whether you're using Scrum, Kanban or a hybrid process, and whatever statuses you have for your stories. So in this respect we're utterly unique in allowing you complete flexibility with your process and still providing end-to-end traceability.
Other CI tools are still at the stage of copying functionality we launched 3 years ago. For example the Jenkins pipeline plug-in almost allows Jenkins to match the capabilities we provided in Cruise 1.0 back in 2008. We intend to stay well ahead of the field, and we have much more exciting functionality planned based on ThoughtWorks' experience helping all kinds of organizations adopt continuous delivery and devops.


Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}