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.
Join the DZone community and get the full member experience.Join For Free
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:
- 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.
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.
- 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.
- 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.
- 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.
- 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.
Here's who shared their insights with us:
- Tim Curless, Senior Technical Architect, AHEAD
- Will Hurley, Vice President of Software Lifecycle Services, Astadia
- Lei Zhang, Head of Developer Experience (DevX), Bloomberg
- Ashok Reddy, Group General Manager, CA Technology
- Sacha Labourey, CEO, CloudBees
- Logan Daigle, Director DevOps Strategy and Delivery, CollabNet
- Sanjay Challa, Senior Product Marketing Manager, Datical
- Colin Britton, CSO, Devo
- OJ Ngo, CTO, DH2i
- Andreas Grabner, DevOps Activist, Dynatrace
- Anders Wallgren, CTO, Electric Cloud
- Armon Dadgar, founder and co-CTO, HashiCorp
- Tamar Eilam, IBM Fellow, Next Generation Cloud and DevOps, IBM Research
- Mathivanan Venkatachalam, Vice President, ManageEngine
- Jim Scott, V.P., Enterprise Architecture, MapR
- Mark Levy, Director of Strategy, Micro Focus
- Glenn Grant, President - U.S. East, Mission
- Jonathan Lewis, VP of Product Marketing, NS1
- Zeev Avidan, Chief Product Officer, OpenLegacy
- Tyler Duzan, Product Manager, Percona
- Bradbury Hart, Vice President and Chief Evangelist, Perfecto
- Damien Tournoud, Founder and CTO, Platform.sh
- Bob Davis, Chief Marketing Officer and Jeff Keyes, Director of Product Marketing, Plutora
- Brad Micklea, Senior Director and Lead, Developer Business Unit, and Burr Sutter, Director, Developer Experience, Red Hat
- Dave Nielsen, Head of Ecosystem Programs, Redis Labs
- Brad Adelberg, Vice President of Engineering, Sauce Labs
- Adam Casella, Co-founder and Glenn Sullivan, Co-founder, SnapRoute
- Dave Blakey, CEO, Snapt
- Keith Kuchler, Vice President of Engineering, SolarWinds
- Justin Rodenbostel, Vice President of Open Source Applications, SPR
- Jennifer Kotzen, Senior Product Marketing Manager, SUSE
- Oded Moshe, VP of Products, SysAid
- Loris Degioanni, CTO and Founder, Sysdig
- Jeffrey Froman, Director of DevOps and Aaron Jennings, Engineer, Temboo
- Pan Chhum, Infrastructure Engineer, Threat Stack
- John Morello, CTO, Twistlock
- Madhup Mishra, Vice President of Product Marketing, VoltDB
- Joseph Feiman, Chief Strategy Officer, WhiteHat Security
- Andreas Prins, Vice President of Product Development, XebiaLabs
Opinions expressed by DZone contributors are their own.