olly - Fotolia
Your organization wants to jump into DevOps, but it's brand-new to you as a developer. Here are steps both individual coders and aggregated software development teams can take to grease the DevOps slide.
Step one: Learn a scripting language
Out of the gate, a good first step to enhance the programming team's ability to bring DevOps processes into the software development lifecycle is to learn a powerful scripting language, like Node.js or Groovy. When developers access operational tools, they will be doing it programmatically. The programs that developers will use to access infrastructure-as-a-service resources, AWS instances or even traditional application servers, like WebSphere or WebLogic, are not usually coded in a language like Java or C++. It's important to understand a popular scripting language, know how to write a few lines of code that can authenticate against a resource protected by the operations team and be able to script the control of operational resources. Do all of that while elegantly handling exceptions and error conditions, and your DevOps for developers journey will carry into the operations domain.
Step two: Continuously integrate
In DevOps, it's all about automatic deployments. So, the second step on the DevOps for developers journey is to locally install a continuous integration server, like Jenkins or Concourse. With an installed CI tool on the local workstation, developers can use CI to automate processes such as software packaging, test execution and deployment to local servers. Management, configuration and troubleshooting of a CI server can be the glue that holds the DevOps horse together, as the tasks a CI server governs often fall on both sides of the DevOps divide. A strong understanding of how to work with a CI server, by both developers and operators, will make the DevOps for developers transition a more seamless one.
Step three: Copious and comprehensive test coverage
As the term DevOps implies, implementation requires that developers get their hands on systems traditionally under the exclusive purview of operations. But no ops team will easily relinquish control of its resources if it isn't confident in the developers' code. IT ops doesn't want anything to cause irreparable harm to existing systems.
Fortunately, it won't be difficult to reassure the ops side, but it will require devs to do something they don't normally do: properly test software.
All software development teams do testing. That's a given. But DevOps for developers requires more than just paying lip service to the concept. Software must be unit tested, integration tested and regression tested. And unit tests need to be comprehensive. Too often, software developers write a set of lackluster unit tests that serve no other purpose than to appease the audit team when the question of software testing arises. Monotonous tests won't fly in a DevOps shop.
If the operations team is to trust developers to push their buttons and tweak their dials, assurances should be made that every option has been tested and every possible outcome has been evaluated. As development elbows its way deeper into the operations world, there will inevitably be objections that the dev team can't be trusted to take care of the operational side of things. When such complaints arise, the development team must assure all stakeholders that every path has been tested six ways to Sunday, and a history of quality control through applied software testing must exist to lend credence to its case.
Hit the books, not the exhibition floor
When Ernest Mueller, director of engineering operations at AlienVault, wanted to make sure his developers were ready for DevOps, he didn't send them to conferences or seminars. He simply reached for the bookshelf.
Mueller, a long-time DevOps devotee, thinks the way to begin the journey is to go back to the beginning of Agile and lean programming. "If you can internalize those things, you have a good beginning," he said.
After that, it's the right choice of books. He feels so strongly about this list he brought copies of these to the company’s European headquarters so developers there would have access to the same titles as their counterparts based in Austin, Texas.
Number one on his list is Continuous Delivery by David Farley and Jez Humble. "As a developer participant in a build-and-release cycle, you need to understand how everything behaves in order to make applications that are continuously integratable," he said. Then, to get an insight in to the ops side of the world, he suggested The DevOps Handbook by Patrick Debois, Humble, Gene Kim and John Willis. And finally, his "hardcore" choice is Release It! by Michael Nygard. "This book rigorously enumerates failure modes and the mitigations you can perform. This is like the design patterns books you studied in college, but for production."
Step four: Expansive DevOps testing
When it comes to DevOps for developers, teams also need to integrate new forms of testing into their software development lifecycle. Penetration testing, performance testing and security auditing are often tasks performed by operations. But in a world where a developer has the ability to pull the trigger on a deployment, tests must be performed without sending a requisition form to the head of the ops department. Coders not only need to speed up the ferocity of their testing routines, but they must test their systems in ways that may feel alien.
DevOps has the potential to improve software quality, increase the velocity of feature releases and bring great efficiencies to the IT department. Learn a scripting language, familiarize yourself with the nuances of an integration server and bring your test game to a new level of coverage and comprehensiveness. These DevOps for developers steps will make the adoption processes easier and ultimately inevitable.