In the early 2000s, I started my career as a system administrator and shortly after embarked on a new path as a software developer. Thus, I’ve had the chance to see the software development process from both the Ops and the Dev standpoints.
At that time, developers mostly didn’t think about how to deploy a product or how to promote it in the target environment; developers were supposed to only produce the code and not bother about its delivery. Usually, developers used OS desktop versions and held no interest in how production servers were configured.
What’s more, when a new developer joined a team, he or she tended to waste several weeks setting up his or her development environment. In its turn, an operations team had no influence upon a Dev team and didn’t worry about product development. Both teams had their own managers and success metrics.
So, what’s wrong with this picture, and what problems did it cause?
In the old days, when it was high time to deploy a product, we regularly faced situations where the provided code did not work in the staging environment or an Ops team was not able to deploy it. The Dev team was armored with the same excuse: “But it was working on my workstation!”
The Ops blamed the Dev, the Dev blamed the Ops: it was a non-stop battle between the two teams leading to unpredictable delivery dates and all the further negative consequences.
Then management tried to introduce checklists, redistribute control and keep documentation. At the same time, the majority of the operational actions were manual. Additional time was needed to create documents, the conflict was not resolved and the predictability of the delivery date was far from accurate. Time passed while customers demanded delivery dates, new features and fixed bugs as soon as possible.
How did we fix this problem? Agile development methodology became popular, virtualization and cloud entered the business arena and startups started playing first fiddle. The global market became more aggressive; if you couldn’t release a new feature first, you would probably lose most of your customers. It was go big or go home.
Pandora’s Box
From the point of view of modern software development methodologies and technologies, we can sum up the problems with the old model into five potential issues:
- There is no single responsible person who would manage the product from definition of business requirements to the product release.
- The Dev and Ops teams have different success metrics. It leads to an environment where each team is interested only in their own success.
- Lack of communication between the Dev and Ops teams. Developers need more knowledge about the target environment, while Operations have no clue what a Dev team does.
- There is a difference between development and target environment configurations.
- Slow and long delivery processes with unpredictable delivery date.
DevOps: happily ever after
The solution to all of these issues is the DevOps philosophy—namely, software development methodology such as Scrum with a set of roles, steps and practices with predefined responsibilities. DevOps is a culture of developing a product that can be easily deployed as well as operate effectively.
It is not enough to hire DevOps engineers and hope that all the problems will get solved. You need to adopt DevOps culture in your organization.
Here are some recommendations on how to adopt DevOps in your organization and increase productivity of the development and operational teams:
- There should be one, and only one, manager responsible for a product or feature development from A to Z: from the stage of requirement gathering to the release date.
- The development and operational teams need to share common success indicators focused on the delivery result.
- Introduce a DevOps leading role – a person with the support of management as well as good technical knowledge to be a bridge between management, operations and development teams in order to set up DevOps best practices and make sure that teams follow them.
- The development team should use a development environment that’s as close to the target environment as possible.
- To apply an “infrastructure as code” approach, the development team should use virtualization technology and describe environment changes with the help of different configuration management tools: shell scripts, Puppet, Chef, Ansible, etc. In its turn, the operations team may help configure scripts development.
- Both teams should work together on the infrastructure planning.
- The operations team needs to define requirements for monitoring, log management and disaster recovery, as well as help the development team design a solution that complies with these requirements.
- Engage the development team in operational activity automation; in particular, to build and deploy processes, do runbook automations, etc.
When you decide to adopt a DevOps culture in your team, keep in mind that DevOps is not a silver bullet: these are organizational changes that require a shift in Dev and Ops minds. If you establish successful communication between managers, developers and operations through the mentioned best practices, you will avoid conflicts of interest within the team, as well as significantly speed up the delivery process and ensure your customers get first-rate quality.
Vadym Fedorov works at SoftServe Inc. as a solutions architect. He has 12+ years’ experience in enterprise application development but has been focusing specifically on cloud applications the last couple of years. Vadym is a frequent contributor to the SoftServe United blog.