| The agile DevOps series contains the following posts: | |
|---|---|
| What is DevOps | Working software |
| The environmentalists | Ship ahoy! |
| Afterlife | |
This series is about DevOps and how it fits into the agile world. I’ve given this as a workshop at Lean Agile Scotland (slides).
Let’s start with what DevOps is. I went to the source of all knowledge, Wikipedia, and the definition goes like this:
“A culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology professionals while automating the process of software delivery and infrastructure changes.”
Well, isn’t that vague.
Also, it’s not really helpful. The Dev is in there, sure but Ops is translated to IT. Developers have always needed and worked with IT, so what happened on the way to paradise?
To the time machine!
In 2001, there was this little thing called the Agile Manifesto. It talked about working software, the result of team collaboration. If we apply this to the DevOps definition, we’ll notice a couple of things :
“A culture, movement or practice that emphasizes the collaboration and communication of both software developers and other information-technology professionals while automating the process of software delivery and infrastructure changes.”
Obviously, the collaboration part is there. And it evolves the original team aspect from the agile manifesto. You see, at the time of the manifesto (and the half decade before it, when the agile methodologies developed) the “team” definition was already expanding.
Scrum defined the “team” as anyone who needs to be there to make sure software is delivered. That meant developers, testers and product owners (ok, that’s a separate role, but without POs, nothing meaningful gets delivered). Today we need more skills on the team. Automation, deployment, preparing testing environments – this is a short list of examples that are required to make sure software works.
DevOps is really an extension of the “team” definition. We can think of it as new roles. But we shouldn’t.
We like role playing so much, we confuse skills with roles, and come up with new. and somewhat dysfunctional ideas for how work should be handed over, rather than how it’s done.
We think of DevOps as a role, or a team, doing their work separately from what the developers and testers do. We think that DevOps is only a about automation, and therefore try to hire, train and upgrade people within these roles.
This is wrong – After so much work to create a true multi-disciplinary team, we’re putting up the walls again. The truth is, we need the skills in the team, not outside it.
So repeat after me: “Separate DevOps teams are not agile”.
DevOps is not a role. It’s a set of…
99 skills but DevOps ain’t one
Man, that DevOps skill-set is huge. We are now handling a whole new set of complex problems that were either not there, or were just beginning to rear their ugly head in the nineties. No wonder scrum didn’t define it.
We no longer put our software on 34 disks and ship them (thank God). We got cloud services, clusters and orchestrations that we need to optimize for business operations. The accumulated knowledge (some of it only a couple of years young) is required in order to deploy and assure working software in production.
We need to set up environments in-house so we can develop and test even before we deploy it to the outside world. And those environments are not as complex as they are out there, so we need to simulate those external conditions in order to test properly. Granted, we have better tools to manage those things. But we still need to keep up on the technologies and tools, implement them and upgrade them.
And if that wasn’t all, the risk implication of messing things in production have gone up – we can no longer shutdown servers for the weekend to deploy our software without interruption. Things need to keep running before, during and after we flip the switch. On the other hand, the policy of IT (or Ops) drawing a line in the sand and telling the developers: “you can’t touch our production servers” no longer works. We need better approaches to keep the business going.
Working software is hard.
Riddle me this
We need skills and knowledge to run things smoothly. They hold answers to questions and needs we have. But now we have questions we thought were answered:
- What is a software version?
- What defines a feature in versioning terms?
- What is the feature “ready for release”?
- What defines an environment? How is a testing environment different from a staging environment and how what risks and mitigation go with that?
- What is a rollback? To what version do we roll back when people are committing code to production every few seconds?
And that’s just the short list.
As the agile manifesto says, “we are uncovering better ways to develop software”. We are still early in the process of defining what DevOps really is. But we already know of the skills and knowledge we need now.
Next time, we’ll see how how agile principles and DevOps practices align towards the goal of working software.