More often than not, development teams don’t get involved in what we call “production”: they don’t really take part in the software product creation process. But on the contrary, any team that fosters a DevOps culture could be defined as “a team that gets involved in the creation process and is responsible all throughout: from creating user stories to knowing how the app behaves in productive environments.” Taking decisions as to where, how and when we’ll make our apps available for the user empowers the team and lets them know the business in detail.
We do know that DevOps is really just a position taken by someone inside an agile development team. But when we talk about “DevOps culture”, we refer to letting everyone participate in the decision-making process and have responsibility for what we build in the quest for a holistic, integral business vision. When we assign a DevOps position, only one person is responsible for what happens with the infrastructure, and that person alone makes all the decisions, not with the team.
Creating a DevOps Culture
The foundations for an effective DevOps culture are effective communication inside the team, feedback and trying to improve processes. When all these elements are present, big things can happen.
I’d like to focus on how, from the very beginning, a team that’s just starting can work with an agile culture that favors DevOps values. To begin with, we should note that:
- Our apps will be used in a productive environment, in which different situations may arise. The team must be responsible for whatever happens and it needs to implement contingency and security plans, metrics and alerts that might help detect unexpected situations, such as system failures and maintenance problems, among others.
- There will be stories related to business interests and not to add value for the user. Even so, these stories will allow for other maintenance tasks in productive environments.
- Our team must direct its efforts to add value to the business; that’s why the development and infrastructure teams must communicate with each other and understand each other.
If integration and communication among all the areas that take part in developing the product start early, we’ll be able to solve many issues beforehand, avoiding mistakes or misunderstandings that could be serious if detected during the last development stage.
For example, in my experience, many projects make the same mistake, which is to leave everything related to development and production environments for very advanced stages of the product, which may really delay delivery. When the deployment of the app is imminent and there’s a need to carry out deeper tests, certain problems start arising, from minor design or implementation details, to staging problems during production.
However, in other projects that take into account the creation of environments and that define early in the process how the app will be moved onto production, the anticipated debate allows us to get to the staging moment with problems that are much easier to solve. At this point in the process, the most important issues have already been solved and we’re already familiarized with the infrastructure.
Including user stories from the very beginning allows us to ease the production stage and, also, to think about other issues and needs that might involve other teams as well, such as the quality team. For example, we could decide how to test automatically and at which point of the whole development flow we’d like to do so. We could also think about how to run tests in different scenarios in which we could manipulate the infrastructure conditions so as to know what will happen with our app under certain circumstances.
The DevOps DNA
Planning, creating and integrating automatically; deploying, monitoring, testing, adapting and iterating indefinitely: these are parts of the DNA of our team, which considers infrastructure as a process from the very moment they start working.
Planning, building and integrating automatically. Releasing, monitoring, assessing, adapting and, after all of that, repeating the process indefinitely. This is part of out team DNA, which includes infrastructure as a process, and it should be taken into account from the moment we start working.