Fotolia
What is the DevOps role for operations people?
In a DevOps world, it can be hard to know where Dev ends and Ops starts. Expert Tim Western explains what the various DevOps roles can and should be.
To understand the DevOps role in a company, one must understand the problems it was meant to solve. In a traditional company, development -- and possibly testing -- resided in separate teams. They work daily, building software, kicking it over the wall to testers, who then give a thumbs up that it's ready for release. That's where the "Ops guys" would come in. They would "test" the release to the extent that they tested the deployment to staging environments -- that means all of the SQL scripts that are run, all of the zip files that need to be transferred and extracted, every DLL that needs to be registered, and every install script that needs to be run. Then they get to monitor all the performance counters, up time, CPU usage and error logs. It was a lot of work, and a very manual process.
Classic operations
The DevOps role pulled operations into the team, including ownership of the test servers, concerns about rollout and managing the rollout itself. A team that is pursuing DevOps likely owns responsibility for production servers, including monitoring and managing those servers.
This manifests as the team takes more responsibility about how to build the product, how to deliver it for testing, how to transfer and deploy it to staging, and then production. Later, it may also include how to handle scaling out the product as the customer base grows, which means managing the virtual and barebone infrastructure in test and production.
So what is the DevOps role for Ops in testing? The Ops side of DevOps starts with the servers, getting them to exist and keep running, including after a change (deploy) and actually doing the deployment. Traditional Ops people did a lot to manage and test the infrastructure before a rollout -- including dev and test environments -- they just didn't care much about the details of the application. This includes making sure application program interface endpoints stay up, return meaningful results, are connected to the right source databases, are reasonably fast and are transparent.
The old term for creating a new server was "provisioning;" it involved purchasing something from a vendor and setting it up. Server virtualization made this easer. Testers could file a ticket, and Ops could have a server up later that day or the next. With DevOps, the Dev part (programming, automation) can write code to enable spin-up on demand -- testers can create an environment at the click of a button.
Speaking of builds, the focus of Ops in a DevOps role remains on making builds happen more reliably, more frequently and with some attention paid to good deployment automation that makes it possible to not only create a server, but to upgrade existing servers. Also they make automatic checks via code to verify the deployment has succeeded. They may also play a role in monitoring, as well as some of the more complex aspects of configuration management.
