The basic idea behind Dev and Ops is to get the two roles working together. This sounds obvious, but think for a moment about how the roles have traditionally been implemented. Operations is responsible for uptime and reliability; the simplest way to keep systems up and running is to lock em down and prevent change. The job of a software developer is to create change. From the beginning, the incentives for one role are misaligned with the other. The first part of DevOps, the very inkling of an idea, is to break down the walls between the roles.
Here's an example.
For years, decades even, system administrators have been writing little scripts bash, perl, awk and sed to automate repetitive operation and setup. These scripts are code, yet the code the sysadmins write follows none of the practices the programmers have to follow. It likely has no requirements, no formal test process, no deploy process ... it might not even be in source code control. With no standards for the work, the code is likely in a different programming language than the production code. It may even do things the programmers would like to reuse, but they don't know it exists. If the roles were actually working together, instead of at odds, they could share knowledge, practices and even the codebase.
Automating the repetitive sysadmin tasks is something that programmers are uniquely qualified for. And it turns out to be a classic starting point for DevOps.
DevOps as concept
Builds. Deploys. Rollouts. Rerunning the unit tests. Integration and automated end-to-end checks. Creating Virtual Machines. All these are straightforward, definable business processes so well-defined that sysadmins often have runbooks, FAQs and wiki pages they can copy, paste and replace variables to do the daily work.
Programmers automate things; that's what they do. So why not combine the role of developer (automation) with operations (deploys and maintenance)?Overlapping these roles automating the parts of operations and testing that make sense is core to the idea of DevOps. It also runs counter to the conventional ideas in IT and process engineering, where terms like "separation of duties" would imply DevOps is a bad thing. Then again, all those Waterfall process documents said something scrum or agile software would be a bad thing, too. So there's that.
Two ways to do it
One approach is to simply rotate developers through operations for a few weeks to a few months. The theory goes that the programmer-in-ops is going to check the existing codebase into the right version control, automate routine tasks in a smart way, create reusable code libraries, replace the installation of physical machines with virtual machines created through code and so on. There's certainly some immediate, easy gain from this, but it seems likely that programmers in operations will be crushed by either the workload or the policies, and that actual DevOps adoption will be limited.
Sign up for CIO Asia eNewsletters.