Keep CALMS and DevOps Ons
WWT's Mark Balbes discusses the nature of DevOps and its relationship to agile in his latest article with ADT Mag.
Posted by ADT Mag on May 29, 2018:
You are a software developer in an agile shop. You've got a collocated team consisting of developers, QA, UX, and an agile coach. You follow all the agile technical practices. Not only is your team agile, but so is your code. You are very proud of the fact that it has been written so it can be deployed in almost any environment anywhere.
You've gathered with your team around your Kanban board for a special ceremony. With a flourish, your teammate moves the last story card across the board to the "Done" column. "That's it. We are done!" he declares. "Huzzah" cries the team. "Well done!" says your manager.
"Um," says a meek voice from the corner. It's the new guy. "How can we be done when we aren't in production?"
"We don't need to be in production to be done," says one of your more experienced colleagues. "We can deploy this everywhere."
"Yes," continues the new guy, somewhat perplexed, "but we aren't deployed in production anywhere."
Enter DevOps
Agile teams have always had the desire to perform their work to completion, coining the phrase "done done" to indicate that all the i's have been dotted and t's crossed. "Done but" was the call of the non-agile. In order to be truly done, in order to provide value to users as per the agile manifesto, the software had to be deployed into production. So developers started to create software development techniques and build tools to automate tasks beyond software development. A desire for continuous integration and automated builds led to tools like Cruise Control, predecessor to modern tools like Jenkins, GitLab CI and Team Foundation Server.