What Devs Need to Know About DevOps

DZone 's Guide to

What Devs Need to Know About DevOps

Automation, alignment, and security are just three of a long list of things for developers to learn about DevOps.

· DevOps Zone ·
Free Resource

To understand the current and future state of DevOps, we spoke to 40 IT executives from 37 organizations. We asked them, "What do developers need to keep in mind with regards to DevOps/CI/CD?" Here’s what they said:


  • It’s not one thing, it’s a maturity. As you begin, you cannot just flip the switch and know everything. Look at how much is manual and build automation around testing for the full breadth of the process. The maturity curve takes time and practice. It can always be improved.
  • Make it easier to write code. Use a platform for test environments. Unit tests fail in an integration environment. Developers are on the hook for tests in the preproduction environment. Request a test environment and test your builds and applications. Stop managing metrics and managing up. Provide transparency into what’s happening. Integrate security and compliance for collaboration. Be precise on where to focus energies to automate.
  • Automate from your first deployment. Never deploy manually.
  • View every technical tool as prioritizing automation. Embrace the notion and you’re halfway there. How do I automate every aspect of what I need to do?
  • Development teams need to get in the mode of always being ready. Shorten the delivery cycles by embracing automation across their software development, integration and delivery pipelines. They need to have an agile mindset and focus on the “Minimum Viable Product” (aka MVP) and continuously focus on delivering on that. 
  • Simply put, automation is a tool. It cannot replace good fundamental understanding of the systems you are building and deploying. That understanding should guide you into writing strong automation. You can use automation in your pipeline to enforce code style, or to do quality checks, run end-to-end integration tests, or for application security testing. But at every step in the pipeline, you need to give thought to the results you’re looking for and how to achieve them, and then code that into your automation. Fundamentally, this is an engineering discipline and you should invest as much effort into your automation and pipelines as you do into your end applications themselves.
  • CI/CD is entirely dependent on automated tests. Without an extensive test suite for all the different parts of the code, developers will not have the confidence to have their applications continuously deployed to production - which will introduce friction in the dev process. Without automation to ensure tests are always run and to block their release if they fail, teams under pressure could start skipping tests instead of fixing problems. Teams would then risk entering a negative feedback loop of test decay and a decreased motivation to employ DevOps effectively.
  • Reliable and repeatable delivery pipelines require simplicity, collaboration, automation, and measurement.


  • Learn the principles. Look at the sources for research and reference how to think and how to plan. It's all about togetherness. Everyone on the same page with the same process. We fail when we have divisions.

  • There is more to the software stack than the specific part you are working on. There’s more to it than infrastructure, test, dev. Empathize with the entire stack. The best teams work across the entire SDLC. Be open to a new culture to think beyond specific role and task. Be aware of the rest of the machinery to be more efficient in getting features in the hands of the end user.
  • Historically training for developers was organizational -- write code and don’t worry about how it's deployed. Be a developer but understand security, operational, and deployment challenges. As you think about user stories you can have a more intelligent conversation. Be able to empathize with security and operations to deliver applications in a more efficient way to reduce organizational friction. Knowledge is power.
  • Make sure you keep the DevOps team in the loop, planning, development, and review or you deal with challenges in production. Even if you don’t see the connection. They’re going to have to support and deploy. Get them in the loop as early as possible.
  • Developers have to accept that the definition of “done” is not when you have checked in your code, but when the code is actually running in production and delivering value to the customer.  The evolution to the product team approach in DevOps no longer measures success within silos. Both development and operations will be measured not just on the outputs, but the outcomes as well.
  • Application and End-User Focus: In a DevOps environment, the ultimate goal is to deliver greater QoS for end users. To that end, minimizing friction across silos is designed to speed up updates, changes, deployments, and time-to-resolution for problems; the performance of every line of code and the metrics of each component of the stack are only relevant based on how they affect application performance. Developers must remember performance needs to be a discipline. Collaboration: Whether an application is on-prem or in the cloud, the ultimate objective is to provide the end user with the most optimal application experience, which requires collaboration among each team member at every stage of the process. Because the ultimate objective is to provide the end user with peak application performance, silos prevent progress. If an application is down, everyone has failed. There is no database team. There is no virtualization team. There is no storage team. Everyone is accountable for QoS, which includes application performance. This approach requires transparency, visibility, a consistent set of monitoring tools, and teamwork. Breaking down siloes between traditional data center teams and aligning them behind end-user performance goals will help organizations prepare to integrate and manage their development and operations teams down the road. End-to-End Visibility and Automation: A DevOps process and continuous deployment require comprehensive monitoring across environments to guarantee performance and uptime, particularly for automated workloads. In other words, visibility is critical for speed and collaboration and the impact of every change should be known. And to move faster, code deployments, tests, monitoring, alerts, and more should be considered for automation.


  • Learn the fundamentals and make sure you are doing security testing up front. Learn AppSec testing and avoid stupid mistakes. Get results in one or two minutes to test code and get results back. Learn and fix. When you have zero vulnerabilities integrate your code into the build. So fast, easy, and self-explanatory developers have tested the application many times as pieces of code. Ensure you have a secure and compliant application. Adoption is growing. Less than 50% of organizations use technology for security. High adoption of dynamic analysis. Expediting the development process.


  • There’s a nice pairing with DevOps and microservices that ties with AI/ML space. Both stacks are a great fit for tools from DevOps and data ops.
  • It is no longer someone else’s job to test developers’ code. There is no more “throwing it over the wall” to QA. In DevOps, implementing continuous integrations, continuous delivery, and continuous testing will automatically get changes to production as quickly as possible. Developers have a direct impact on customers; it is their responsibility to ensure that what they build meets the needs of the customer and maintains a high level of quality.
  • Two key components: 1) As the developer gets comfortable with the environment in which your app will be deployed, learn configuration, scripting, and tools. 2) Scripting languages – Python and Go for different infrastructures. Create your own vagrant set up and play.
  • Take your code and run across a wide range of environments. Take a baseline and deploy, using containers and VMs. Whatever you invent or write is thoroughly tested. Deploy containers and VMs, push products out, get results – data.
  • It’s easy to fall in love with new technologies. DevOps is only as strong as the weakest link. You need to include DevOps principles in every aspect of your business. The entire process runs at the speed of the slowest element. Focus on speeding up the slowest elements of the process.
  • Developers have a misperception that we’re asking them to carry a pager. Trying to automate what they shouldn’t worry about and get feedback faster. Until deployment and a customer uses your app, you don’t know if it’s valuable or not. If you leverage DevOps, you will get feedback faster. Know how it's used and if it's delivering value.
  • Put everything under version control. Be disciplined. Don’t start hacking and not keeping up with documentation. You’ll turn out code faster for a while, but you’ll reduce quality later.
  • Put a good framework in place and engineers lives become more comfortable. Understand the benefits of the process and why it’s being adopted even if you’re not the manager. Understand how the entire process will work and how you fit into the ecosystem. Also, don’t write stupid log messages.
  • Continue to focus on crafting your technical skill but with a focus on the system. Your technical skills and tooling have a greater impact than just putting code in source control. It will eventually make a customer, tester, or an operations person happy or sad. You can have a positive impact with systems thinking.
  • There are going to be changes in how you work. When developers are invited to the party they explain how you should be doing ops. The way people develop will need to change. You cannot be detached from your team. Code reviews can be running code, this changes how you think about coding. Reexamine the way you work.
  • Treat the adoption of DevOps the same way you’d treat the application. If implementing CI/CD, you need to do that for DevOps and for the application. Part of the process is to continuously improve and integrate. Don’t be afraid to change. Adapt and adopt to the new changing ways of deploying applications. No one will be an expert from the get-go.
  • You have to start thinking about the impact of your next code line on production. Understand what happens to your code when it goes to production. Know who is using your software and how it’s used. Think more broadly. Show interest in what happens from development to operations and how it supports the business.
  • Embrace DevOps. Developers are artists and artists don’t like to be told how to paint. Understand the tools are there for you, not to tell you what to do. Devs have an entire gallery of blank canvases. Change how to build your application any way you want to.
  • Focus on the user. If you keep this as your North Star, it will go fine. When you focus on policies or tools you lose sight of offering better solutions faster. Is this helping the end user? Not everything is technical. It’s about the impact of your application.
  • Hard to keep up with technology. A lot of shops haven’t taken ownership for quality and operations. It's worth the effort to spend time with QA, operations, automation, Cloud APIs. Don’t think of yourself as just writing code. The proof is that your code is correct and able to run well in production.
  • When thinking about the impact and integration of CI and CD tools into a DevOps workflow and culture, you need to consider what needs to really be specific to your process, and what can be more reusable or off-the-shelf. CI tools may need lots of levers and knobs to adjust to specific business process demands. CD on the other hand, may not need to be as bespoke. Some platforms include CD, container management, service management, routing, and more in a PaaS that serves microservices, monoliths, eCommerce apps, CMS, Java, PHP, Go with the same underlying systems.
  • Well, I certainly think it's a great thing for developers to have access to monitoring tools so that they can see graphs and metrics about how their application changes perform in the cloud and in a prod environment. Having developers be responsible for building their own containers is one way DevOps and Dev are becoming very connected. Containers take it one step further on the road to connecting the two teams and this is a positive thing.
  • In an ideal world, a developer never has to think about CI or CD at all - everything just happens as intuitively expected in each case. Developers do need to keep in mind which of their actions triggers which CI or CD process to use those actions to best advantage during the development cycle.
  • 1) For continuous integration (CI), codes from different sources are frequently pushed into a main branch of a common repository. Continuous delivery (CD) is a degree of automation where building, testing, and deploying occur automatically whenever a major change is made to the code. Developers don’t need to be tied up with one tool. Complement your existing tools with other new tools to improve overall efficiency. 2) Additionally, there are cases where automated testing simply won’t suffice due to things like usability or security, which makes manual testing very vital. When manually testing, make sure that every module is unit tested and that these tests are done in an environment which exactly mimics the production environment. If the tests confirm that the application will work as expected in production when it’s deployed, then your DevOps strategy is one to look up to.

Here's who shared their insights with us:

automation, devops, devsecops, security

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}