From time to time, we tolerate business processes that don’t work as well as we’d like. It’s easy to complain about a process that is slow, clunky, or just plain broken until you try to build one yourself. It’s simply easier said than done.
So, how broken must a process be to spawn an entire social movement ? That was the state of application release in 2009 when the DevOps movement emerged. DevOps pioneers realized that the gap between application development and operations was killing their businesses and making IT look incompetent.
DevOps throws out the old silo boundaries and applies much-needed common sense: dDeeply collaborate and communicate; reduce the scope and increase the tempo of service change; automate to eliminate manual errors and wasted time.
During the first two years of DevOps, the pioneers were carving out new, ad-hoc tools to help do this. But as the pragmatic majority prepares to follow the same path, what’s the right way to make this process actually work?
Fortunately, this isn’t the first revolution against inefficient process. The revolution The resolution began with modern manufacturing and the elimination of broken supply chains. However, more recently, the application development world has gone through its own revolution, discarding the lumbering dinosaur of waterfall development for nimble, warm-blooded agile development.
So what can DevOps learn from this recent IT revolution?
Looking to Agile Development Automation for Inspiration
Agile software development kicked off in 2001 with The Agile Manifesto . Agile development isn’t just a better process for creating software; it is a new methodology for automation that’s paired with better processes.
Several such pairings are directly relevant to DevOps.
Automatic Build and Test
Embracing small iterative changes instead of following a static plan is core to agile process. But that’s only possible when you can do a complete build and test cycle of your product in one step and in a short time frame. That’s why agile development teams use build and test automation, such as Jenkins and Cruise Control, to make the rebuild-and-test cycle as short and easy as possible.
Modular Components from Shared Repositories
Few modern software projects are built completely from scratch. Instead, they are built on a variety of open source and licensed components, which is critical to the agile development process, because it enables rapid design change. When a project team suddenly realizes that it needs a beefier database or a more flexible network library, the new components are immediately available from modern public repositories like GitHub and Bitbucket.
Automatic Dependency Management
Of course, picking components off the shelf is only part of the solution. It can be a complex task to assemble a compatible, working set of components, and this process was once a major engineering task in its own right.
Today, development teams let automatic tools such as Maven, Ivy, and Gradle take care of that problem. Simply name an open-source Java component, and Maven can download it and all of its compatible dependencies for your project. This is not just a convenience. Automatic dependency management enables agile development by making it possible to use many interrelated components.
Distributed Version Control
Distributed version control systems such as Git and Mercurial remove agile development’s brakes. In the “bad” old days, centralized version control was a constant headache and productivity impediment. Git and Mercurial aren’t just quicker — they enable another core agile principle, which is to emphasize individual self-direction. Agile teams want engineers working on multiple improvements in parallel, and distributed version control makes it possible to bring all those changes together.
Put these four examples together, and it’s