DevOps is not a job role: in most organizations and at scale, development and operations are two separate skill sets, though admittedly the lines between the two are blurring more every day. “DevOps” comes down to having more Development in your Ops with, as a few examples, infrastructure as code, scalable automation around CI/CD (continuous integration and delivery) and database automation; and more Ops in your Development with containerization, test driven development, and “microservices” or API driven development.

DevOps is a culture of sharing that enables development and operations to work together to improve their own processes, while focusing on their core competencies, by enabling each other to own their own destiny. To “own their own destiny”, operations must enable development to have a simple clear path to deploy code as it would be to production, and to modify the parameters surrounding that without needing to understand the fine details of networking, infrastructure security, or CI/CD systems. Likewise, development needs to enable operations to build scalable systems and consider the ramifications of new features on the product as a whole.

If implemented well, DevOps can decrease time to market, increase quality, and lead to more engaged, happier teams. The inverse is true as well: implemented poorly, DevOps can slow everything down, decrease quality, and increase the pain points.

To make DevOps work, an organization must:

Enable open communication and knowledge sharing between differing roles and teams Formalize and stand by the end state process changes are trying to achieve Realistically assess the current state and incrementally improve DevOps is more about the people then the process. By merging the knowledge of Development and Operations teams, organizations of almost any size can make software development and delivery smoother for all involved, and most importantly, improve the product for customers and end-users.