Why Does a Dev Need to Know About DevOps?

DZone 's Guide to

Why Does a Dev Need to Know About DevOps?

DevOps may be held up as the new standard for development environments, but what does the dev get out of it?

· DevOps Zone ·
Free Resource

Like any developer, priority number one is to produce readable, reusable, and maintainable code. Only those items would be enough to write many books, but not only did the area of development itself grow, the area of operations grew rapidly, and in a segment where once it was only the "infrastructure field", Operations now stands out as its own area with professionals, tools, literature, as well as more and more work opportunities related to the now called "DevOps."

Part of the DevOps concept itself has features directly related to development, so being a software developer today and neglecting this trend is almost impossible. Moreover, it can be somewhat detrimental to your career by not noticing what goes on around you. 

DevOps Defined

I quite like the definition found on Amazon's website, which says:

"DevOps is the combination of cultural philosophies, practices, and tools that enhance a company's ability to deliver high-speed applications and services: by optimizing and perfecting products at a faster pace than companies using traditional software and infrastructure management. This speed enables companies to better serve their customers and compete more effectively in the marketplace."

Another definition that I also found very interesting was the from The Agile Admin. Some of the features (advantages, I would say) are accelerated time-to-market, cost reduction (by automating tasks), greater integration among team elements, and others.


Figure 1: DevOps as the intersection of development, operations and quality assurance. Wikimedia via HostingCanada

What's DevOps Got to Do With It?

As I said earlier, much of DevOps culture is highly dependent on quality-to-development processes. So, even though DevOps has the best tools, it's not useful if an associated culture is not adopted by all parties, including QA, manager, and developers. In this brief article, I will focus on talking about what a developer can absorb in their day-to-day culture.

"Do I Have to Learn More Tools and Buzzwords?"

No, my dear dev, it's likely that most of the concepts you already know just might not be used in your everyday life (I know, it's a lot of code and a lot of work to do, but maybe with a little effort you can make something of all this). DevOps's purpose consists of an attitude of shared responsibility that encourages closer collaboration. It is easy for a development team to become disinterested in operating and maintaining a system if it's delivered to another team to care for. If a development team shares the responsibility to take care of a system over its lifetime, it can share the pain of the operational team and thus identify ways to simplify routine operations by automating deployments and improving the logging of applications where they act.

The Benefits of DevOps for a Dev

Change of Mentality

By adopting the DevOps culture, you will already be leaving your comfort zone and thinking of something new. If your company has a DevOps environment, you have the chance to discuss the trade-offs of this adoption with another professional. In this case, there is always the opportunity to learn something new. If there is no specific position, one can adopt the culture and share responsibilities among all those involved.


Developers are always looking for new tools, be they to use in your daily life to save work or automate routine tasks, or to learn something new and update yourself. The tooling available today for DevOps is relatively new, and grows every day, so there is an opportunity to learn new technologies and tools widely used by large companies (such as Google and Facebook).


One of the pillars of DevOps is to ensure a higher quality of the product, either by reducing the speed at which it's available to the market, or by the security that is offered by the tooling adopted with the software produced. This item tends to occur naturally due to integration between the development teams and operations (both closely watched by the QA team). It's a constant search for greater security and availability of an efficient service in the delivered software. In addition, the quality can always be measured by the feedback cycles.

Beyond Agile

Going beyond the traditional Agile (Scrum, XP, and the like), the purpose here is to expand Agile ideas, values, and practices for operations and development by adopting the same collaboration and transparency, exchanging information in teams for problem solving with which you must be familiar if you have worked in Agile teams. Agile is multifunctional in development, just as DevOps is multifunctional in development and operations. A DevOps team includes developers, testers, and the Product Owner, as well as network engineering and systems engineering experts, DBAs, information security, application support, and technical support. Everyone who will be involved in running the complete system in production is part of the software development and delivery effort.

Just as Agile broke down the walls both between the development team and the client inside the team, DevOps knocks down walls between developers and operations. Just as Agile requires developers to work with customers to understand real business needs and priorities and solve business problems together, DevOps requires developers to work closely with operations and understand their needs and priorities. Developers and system administrators must solve operational problems together.

Tests Are No Longer Underestimated

Developers neglect tests. When tested, the artifact produced will generate more security, be traceable to future modifications, and "re-testable" whenever you see fit, as well as ensure organic growth of the software. At this point, using CI servers for testing validation (such as stress and integration testing) and artifact generation makes the developer take care in the development phase, considering that the quality of what should be produced must satisfy both the tests and the power to "pass in build " of your organization's CI. Integration tests should now be agreed upon with the DevOps professional and reviewed with the devs responsible for what is being produced, in order to ensure that the code will not "break" just because it is no longer on the developer machine. Again, communication is essential among operations and development teams. Here, you can take advantage of Fail-Fast, for example.

Learning to Measure Success

Creating feedback cycles between operations and development is a critical part of DevOps. Developers use production feedback to guide system decisions, improvements, and changes; not just problem reports and user suggestions, but measurable data collected on how the system is working, conversion rates, or any metrics the company uses to determine success. This means you need to think about how to instrument your application, what metrics you need to collect, and make sure your system is connected to monitoring and operations management interfaces. Both the developer and the company's operations manager must decide what is considered relevant metrics for the software in question and find tools that can extract that information.

Image title

Figure 2: Feedback Loops from a DevOps environment

Finally, I conclude that DevOps currently has to be both a culture to be adopted and a skill of everyone in the software development area (QA, Sysadmins, devs), removing the thought that only the "guy in operations" should understand and be concerned about what is being delivered. If you're already working in an Agile environment, whether it's your team or your company culture, you may already be practicing DevOps without even knowing, but if you're just concerned about coding and commit, maybe it's time to look at the whole picture and consider this term as more than a buzzword.

devops ,devops adoption ,devops and agile ,career ,developer career ,developer

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}