What is the scope of a DevOps team?

Question

I joined a Devops Team of 6 in a Large Software Development programme (100 Developers in the program). At the time the scope of work was:

• containerisation of the Java server App
• scaling up automated web testing using selenium grid and containers
• hosting and rapid-deploying the JavaScript SPA on Amazon S3
• Continuous integration server integration for deployment of our database applications
• full-stack integration testing of our database, application and SPA prior to scheduled deployments into controlled environments
• developer pre-test by using containers in the cloud
• horizontal scalability of the continuous integration infrastructure

After some restructuring, it has been put to our team that Devops means 'general engineering activities' (anything not delivering business features - a grab-bag of resources for BAU technical projects). This means monitoring infrastructure, error logging infrastructure, new distributed database infrastructure.)

We need to articulate the scope of work that our team will and will not do. (Whilst still delivering a clear economic benefit to the company. )

My question is: What is the scope of a DevOps team?

Answer 1

Be careful! Without proper guidance from technical leadership, DevOps "teams" can end up being janitors, responsible by default for any/everything that isn't explicitly someone else's responsibility already.

As Jez Humble has stated, DevOps "is a practice, not a tool.", with one of the driving motivations being to reduce silos between engineering, QA and ops teams.

Whether or not there should even be a DevOps team is debatable, as it effectively reintroduces a siloed team that's responsible for builds, automation, deployments and other similar activities, with the significant downside that these burdens are removed from other teams which are then less incentivized to be concerned with the build/deploy/runtime considerations of their product.

So, with the caveat that this can vary wildly between organizations, there are two potential models for organizations to follow:

• No DevOps Team: Engineering teams are responsible for making sure their stuff builds in the CI system, gets deployed to test environments, and is packaged/containerized in a way which is consumable by the ops team for final deployment to production environments. (In small organizations without an Ops team, the production deployment may be done by engineering as well).

• DevOps Team as Facilitator: If a separate DevOps team (or person) exists in a standalone role, one approach is to make this team responsible for providing automation or tooling gaps that allows a more self-service approach by the rest of the organization, i.e.:

  • Don't create test machines/VMs for people, create (or buy) a service to do so (we rolled our own, but MS SystemCenter is an example).
  • Automate to zero or one clicks the deployment of test candidates and production releases so that anyone can be the initiator of a build and test cycle, and it doesn't fall on the DevOps team to be involved with every single iteration.
  • Promote the use of containers or other packaging mechanisms so that teams can hand off complete bundles to Ops that are ready to be deployed.

In this model, it's important to define the team's role as automators and facilitators, otherwise it's entirely possible to end up as "the installer folks", by which point the benefits of the DevOps practice have already been lost.