Imagine a bacon-wrapped Ferrari. Still not better than our free technical reports.
- Answer the questions:
- What is Devops?
- What is the ideal DevOps process and toolset? What gets a DevOps guy drooling?
- How can you track the value of using DevOps in your organization?
- What are the lightest processes that Java folks currently use? And possibly contrary to the previous question, “What are the typical processes in use?”
- Systems Engineers
- Software Developers
- Infrastructure / Systems Architects
- Operations Engineers
- Development Managers
- Implementation Managers
- Consultants / IT Services
Before we went, some research was in order. We read blogs, watched presentations, and thoroughly perused Dilbert. A lot of our research will get linked to in this post.
So, What is DevOps?
First off, according to Wikipedia,
DevOps is a set of processes, methods and systems for communication, collaboration and integration between departments for Development (Applications/Software Engineering), Technology Operations and Quality Assurance (QA). It relates to the emerging understanding of the interdependence of development and operations in meeting a business’ goal to producing timely software products and services.
This post on TheAgileAdmin compares & contrasts DevOps with Agile – it gave us a good idea of what we should be ready for, from a 10,000ft view at least. Some key content included:
- Agile Principles – like “business/users and developers working together.” These are the core values that inform agile, like collaboration, people over process, software over documentation, and responding to change over planning.
- Agile Methods – specific process types used to implement the agile principles. Iterations, Lean, XP, Scrum. “As opposed to waterfall.”
- Agile Practices – techniques often found in conjunction with agile development, not linked to a given method flavor, like test driven development, continuous integration, etc.
- DevOps Principles – How we need to think differently about operations. Examples include dev/ops collaboration, “infrastructure as code,” and other high level concepts; things likeJames Turnbull’s 4-part model seem to be spot on examples of trying to define this arena.
- DevOps Methods – Process you use to conduct agile operations – including iterations, lean/kanban, stuff you’d read in Visible Ops.
- DevOps Practices – Specific techniques and tools used as part of implementing the processes, like automated build and provisioning, continuous deployment, monitoring, anything you’d have a “toolchain” for.”
“The best way to define <Devops> in depth is to compare to the definition of agile development. Agile development, according to Wikipedia and the agile manifesto, consists of a couple different “levels” of thinking.
I believe the different parts of DevOps that people are talking about map directly to these three levels.
From the point of comparing DevOps with Agile, Damon Edwards goes on to state that DevOps is not a technology problem, DevOps is a Business Problem. The post suggests that DevOps has a similar goal of Agile (to enable business to work better), but where Agile stops at Software Development, DevOps extends that agenda through to the delivery of functionality to the end user.
Delivering Functionality to End Users
As evidenced by our work on LiveRebel, we’re keen on finding new ways to get functionality into the hands of end users, as quickly and as often as possible. Unfortunately, during the event we didn’t get to have enough discussions revolving around particular toolsets and processes to determine either the optimal setup or the “typical” setup (since most people worked in different environments, had different systems, different goals and different hurdles).
Instead of getting explicit toolset information, we settled for talking about goals the toolchain should seek to achieve:
Reduce the scope of changes
By using iterative development practices, Dev teams can release new functionality more often. A current barrier is that Ops tends to group releases together, since the release process has some hurdles:
- Processes are the same for large rollouts as for small rollouts – nodes need to be taken down and restarted with the updated application. Across clusters, this means rolling upgrades. For others, this means downtime. And unless there is some way to automate this process, it means manual scripting and command line work, which could introduce problems of its own.
- If bugs are introduced, releasing an update can cause problems or even break the app. While the likelihood of introducing breaking changes may be reduced with smaller changesets, there still needs to be some way to roll back to a previous version (or get the current version fixed) rather quickly. This responsibility falls often to the Ops folks, who tend to get penalized for downtime, while Devs get rewarded for releasing code.
Automation Automation Automation
This goal comes in a variety of packages, ranging from Continuous Integration (Jenkins, Hudson, etc), Test Automation, and Automated Provisioning (Puppet, Chef, etc), to Continuous Deployment. It’s probably worth checking out what they were doing at IMVU and Flickr as far back as 2009.
Know what your system is doing and why. Understand what components, policies, and dependencies your system is running (also helps when you need to reproduce the system).
I’m really curious about what tooling & processes are being used for Java teams. What are you using?
David Booth is the CEO of ZeroTurnaround (www.zeroturnaround.com), a software tooling company that focuses on productivity. David’s professional interests include Java, Agile, Marketing and community building. Meanwhile, when not collecting airline reward miles, he spends time training his Hungarian Vizsla, Mako. You can connect with David on LinkedIn.