Many organizations find themselves in a challenging situation with the rise of cloud-based Web applications that allow for quick releases in response to issues or requests coming in from the user community. Responsiveness to their user base is the goal of every software development shop, but it can put a strain on the functional teams within the organization. This strain often results in more defects and consequent disruption to the team. DevOps attempts to solve this problem by developing a partnership between Development and Operations (hence, the name). In this structure, the development team supports operational requirements such as deploy scripts, diagnostics, and load and performance testing from the beginning of the cycle; and the operations team provides knowledgeable support and feedback before, during, and after deployment.
DevOps is the direction in which many software development teams are going. They have to, given the pressures organizations are under to produce higher-quality code faster with less time available for QA. This is a new environment and many developers will need to adjust if they want to prosper. With timelines compressed, the walls separating development, QA, and production are barriers to agility. DevOps attempts to break through those walls. Now, team-playing skills are as important as technical skills. So, too, is a singular focus on the end-user experience and how that is affecting the business. Rather than a new set of tools or organization, DevOps is a new culture and process. It's development, QA, and operations working together to expedite development and problem resolution.
Why Developers Should Want DevOps
DevOps is good for developers. There are three principal reasons a developer would want to work in a DevOps-oriented organization:
- A better quality of life. Developers working in DevOps-mode receive fewer calls in the middle of the night to resolve production issues. That's because they see issues before they become catastrophic problems due to an orientation of proactive monitoring rather than reactive alerts.
- Pride of ownership. In a traditional software process, once software is developed, it's "thrown over the wall" to QA, which later throws it over another wall to production so what the end-user ultimately sees might be quite different from what the developer wrote. But under the DevOps model, what you write goes live because you continue to have visibility and access to the code even after it goes to QA and production. In other words, developers own the delivery of the code from creation to implementation.
- More relevant work. Developers, like most human beings, get greater satisfaction from work that has relevance in the real world. Because developers in a traditional organization are isolated, they often work on simulated problems in made-up user scenarios and they only find out that these approximations were wrong when something breaks. In a DevOps model, scenarios are real. Environments are load tested, for example before they're put into production to see if they work correctly. Another example is that test scripts are, themselves, tested for realism by being deployed in the production environment, not just test labs. Sharing these test results with developers gives them the opportunity to see how their code performs under real-life conditions.
What "DevOps-Ready" Means
Perhaps your organization has already adopted the DevOps model. Three questions can help clarify where you stand on the DevOps curve:
- Do you, as a developer, have access to troubleshooting information in real time?
- Does your production environment use tests and other tools from the development team to validate that the production environment is working?
- As a developer, do you view the networking team as your partner?
If the answers are "no," you're not there yet. Here are some things that can be done to improve the situation. Let's start with your tools. While DevOps is more about culture and process than organization, tools can help enforce best practices specifically, the sharing of troubleshooting information across silos. That requires adding more instrumentation in your software to see how your software is performing in QA and production, not just in development. This is code that traps errors, checks system parameters, reports function timeouts, and returns other values during program execution, which it then writes to log files.
In a siloed environment, developers often won't see these log files again once the code is released into production. In a DevOps world, developers have visibility to the files regardless of where the software is run in development, QA, or in production. Not only do defects get fixed faster, but the same defects are less likely to reappear in future releases making development, itself, faster and more responsive to the business. That brings agile quality to agile development.
Break Old Habits
DevOps is also about breaking old habits like the natural tendency to focus on software bug counts as a measure of quality. Fixing a single bug will not provide much leverage for creating bug-free software faster. A better measure is process bug counts. In other words, where is the process broken that led to the bug in the first place? For example, is the code that developers are building on their local machines somehow different from the code that gets deployed to QA or to production? Or is the code behaving differently in one environment because there is something present there that is not present in the other environments?
Unless code versions are tightly synched across environments, and unless the environments themselves are tightly synched, it is hard to tell whether an issue is a logic problem, a data problem, an environment problem, or something else. This is another case where tools can enforce consistency as in automated deploy to push the same code to multiple environments all at once.
Partners or Finger Pointers?
Probably the most important adjustment developers will need to make is in their day-to-day interaction with other team members. Do developers address software issues proactively (such as by monitoring operations logs daily) or do they wait for problems to come to them through support? And when there is a problem, how is it resolved? Are team members partners or finger pointers?
A lot depends on leadership whether management is preaching the DevOps vision, leading by example, providing the necessary training and support, and rewarding developers for team contributions, not just technical prowess. DevOps requires an orchestra leader. If that job isn't filled yet where you work, maybe you should apply. Selling a DevOps environment is about understanding what's important to management: Is it moving faster? Is it moving higher quality? Is it about developers being more accountable for their code? All these things come about by way of a DevOps environment.
Neil Garnichaud is the Host Solutions Business Manager at SmartBear, responsible for product development and software development.