Developers, DevOps, and Continuous Delivery
Developers, DevOps, and Continuous Delivery
If you want to be a DevOps engineer, focus on end-to-end delivery.
Join the DZone community and get the full member experience.Join For Free
Easily enforce open source policies in real time and reduce MTTRs from six weeks to six seconds with the Sonatype Nexus Platform. See for yourself - Free Vulnerability Scanner.
To gather insights for DZone's Continuous Delivery Research Guide, scheduled for release on January 26, 2016, we spoke to 24 executives who are implementing continuous delivery in their own company or helping clients do so.
Specifically we spoke to:
Casey Kindiger, CEO, Avik Partners | Ez Natarajan, Vice President Cloud, Beyondsoft | Tom Cabanski, Director of Software Development, Blinds.com | Kurt Collins, Director of Technology Evangleism and Partnerships, Built.io | Chris Madsen, CEO, Circonus | Steven Anderson, CEO, Clutch | Yaniv Yehuda, Co-Founder and CTO, DBmaestro | Andreas Grabner, Technology Strategist, Dynatrace | Elaina Shekhter, CMO, EPAM Systems | Charles Kendrick, CTO and Chief Architect, Isomorphic Software| Baruch Sadogursky, Developer Advocate, JFrog | Topher Marie, CTO, JumpCloud | Edith Harbaugh, CEO and Co-Founder, Launch Darkly | Jessica Rusin, Senior Director of Development, MobileDay | Stevan Arychuk, Strategic Marketing, New Relic | Arvind Mehrotra, President and Global Business Head, NIIT Technologies | Zeev Avidan, Vice President Product Management, OpenLegacy | Richard Dominguez, DevOps Engineer, Prep Sportswear | Prashanth Chandrasekar, General Manager of DevOps and Head of Operations, Rackspace | Steven Hazel, CTO, Sauce Labs | Bob Brodie, CTO, Sumo Heavy | Dr. Chenxi Wang, Chief Strategy Officer, Twistlock | Scott Ferguson, Vice President of Engineering, Vokal Interactive | Adam Serediuk, Director of Operations, xMatters
We asked these executives, "What do developers need to keep in mind with regards to DevOps and Continuous Delivery?" Here's what they had to say:
Stabilization of the environment is critical. If something is not broken, don’t fix it. We can’t afford to have the CI server go down, we need stability and assurance. You can usually find what’s working for others by asking them. Don’t get caught up in all the new technology, whatever works for you, works for you.
To become a DevOps engineer you need to understand the two different parts of the stack: the code and the server architecture, load balancing, how everything interacts, how server farms are architected.
You’re responsible for creating value for your company. You need to collaborate with everyone that can help you achieve your goal. Get your head out of your computer and talk to others. Make an effort to understand what happens with your code. Find where your code is causing pain and figure out how to improve it. Identify the potential sources of potential failures and successes. Learn how to contribute better quality work.
Understand that release management is coming into your domain space. You need to architect differently. There should be no single monolithic code base. Build for five-minute release patterns with microservices, and become more well-versed in full stack development.
Stay on the cutting edge of continuous development and delivery. People see great value in this. Introduce your company to it in order for them to be viable.
Don’t ever let yourself get stagnant. There's a fear that developers get stuck in their ways. Don’t be afraid of new languages and tools, because the fundamentals of programming patterns still apply to new tools. Don’t get too focused on one thing.
Communicate with a lot of different people. Be good at what you do but be able to talk with anyone in the organization about how and what you’re doing impacts the service being delivered, as well as the organization.
Continue to learn as you age. You are your number one product. Having a broad skillset is the number one thing you can do to prepare yourself.
If you work in a DevOps company, you want to be a full-stack engineer in order to have greater autonomy. Understand how to work in operations and work in smaller teams. The language you code in isn’t as important as understanding how the code fits into the larger context.
This is the wave of the future and how software will be delivered in the future. You need to have a mindset to continually deliver value to the customer. It’s exciting and fun to get feedback so quickly. This makes people more willing to take more risks and be more innovative. Without continuously delivering software, companies will keep features in house too long. You won’t learn unless you put your work in front of users.
DevOps is in the middle of all deployments as such they need to develop programmatic skills. Developers have a tendency to neglect how well their deployment will get into production. Developers must be responsible for what they develop from end-to-end. A feature is done when the users are using it.
Uninterrupted service should be your number one objective. How do you deliver this with testing and development regardless of catastrophe? You go from 95% code coverage to 99.9999%. Do this and you’ll transform yourself and engineering at your company.
Recognize and include the operational aspects of software into development. Learn how to make software operationally friendly so you can manage it later. Spring is doing more operations-friendly development. Operational work doesn’t have to be separate for development.
Developers must spend time in a production environment to know what is produced and how. They need to eat their own dog food. Understand the lean engineering process and find ways to simplify code. Understand tool environments much better, especially in the agile world. It's impossible to release quickly without understanding the process. Don’t deliver code or get onboarded without understanding the language and the tools. Developers need to move away from a microview to a macro view and how it propagates without propagating risk.
Be really knowledgeable about many different areas. Know something about everything and have really deep knowledge about one thing.
Understand that full visibility results in the ability to speed up operations. Understand the implications of a piece of code. A DIY project is an awesome chance to get experience. You need to continue to learn the tools and technology. Don’t run after every shiny tool launched on a weekly basis, and be deliberate about what you choose to use. Ask others what they use and why. Collaborate and engage in a dialogue.
The tendency to just write code holds developers back. You need to produce high quality working code that is well tested, works reliably, and performs well in production. Don’t just build something elegant that doesn’t work well or test well. The best developers have a deep understanding of what’s happening in code at runtime or during production. You need to have an affinity of how the software is going to work in real world scenarios that allow you to do your job faster and better.
Developers can be asked to cut corners on automation and unit testing; however, this results in a product that’s not ready for deployment and ultimately takes longer and costs more. DevOps reduces risk upfront. Invest in automation, and get experience doing projects from inception to production.
DevOps can and should be used as a process for improving a product's documentation. We constantly make small revisions to our documentation as we see users misunderstanding a feature, or just not finding out about a feature they need. We rarely see this discussed, but we see it as possibly the single largest gain from implementing DevOps, as well as one that's easy to see working. You can watch as certain recurring questions or issues just permanently disappear when documentation improvements are rolled out.
As powerful as it is, it’s not a panacea. The foundational aspects of the software development lifecycle — particularly, in my view, Agile software development — still apply. Unit tests, code reviews, and other safeguards…these are all still crucial. We don't get to say, “It's my responsibility to recover bad software anyway, so I'll take my chances and shortcut our protections.” Also, DevOps teams need to understand that communication is more important within this new paradigm.
Understand the object and the reason for what you are doing. What problem are you solving? What is the benefit of what you are developing? If you know why something is important, you will do more, provide feedback, collaborate and influence the project. Be accurate in what you do. Everyone on the team should share the initiative to identify the best way to accomplish the goal.
What else do you think is important to consider with regards to DevOps and Continuous Delivery if you're a developer?
Opinions expressed by DZone contributors are their own.