Welcome!

DevOps Leadership Series

Derek Weeks

Subscribe to Derek Weeks: eMailAlertsEmail Alerts
Get Derek Weeks via: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


Related Topics: Agile Software Development, DevOps Journal

Article

Faster, Smarter DevOps | @DevOpsSummit #Agile #DevOps #Microservices

How to release more code faster without sacrificing quality

Small image courtesy of Datical blog

Call it DevOps or not, if you are concerned about releasing more code faster and at a higher quality, the resulting software delivery chain and process will look and smell like DevOps. But for existing development teams, no matter what the velocity objective is, getting from here to there is not something that can be done without a plan.

Moving your release cadence from months to weeks is not just about learning Agile practices and getting some automation tools. It involves people, tooling and a transition plan. I will discuss some of the benefits and approaches to getting there.

Waterfall to Agile, Agile to Continuous Integration, Continuous Integrationto Continuous Deployment. Whatever your processes are, the theme is the same: find a way to get code to users faster without sacrificing quality. But speed and quality are sometimes at opposition to each other. Going faster means things can break faster, and when we only think about DevOps as releases, it's easy to fall into this trap.

Established development shops cannot just jump from one flow to another. Unless you start out net new, the goal is to introduce new processes without delaying releases for three months or more to do transition in lump. This is often done using a pincer approach that addresses both bottom-up tactics and top-down oversight and culture at the same time.

However, because adopting DevOps tools is so easy, the trend is to focus on tactics only and adopt from the bottom up without consideration of the entire pipeline. The outcome is release automation tools that dictate your delivery chain for you, and not the other way around. Here are the key categories that get neglected when teams hit the accelerator without a plan in place.

Structured Automation: DevOps requires automation. But what is often not considered is automation that sustains and fits into the entire delivery chain. Considerations such as governance, artifacts organization and inventory, metrics and security need to be made. If an organization establishes a vetting process for all new automation and how it fits into the pipeline's orchestration, then new automation will support what exists today and in the future.

For example, many organizations driving down the DevOps path have encountered challenges when trying to incorporate practices from security or governance teams. Historically these teams have resided outside of the dev and ops echo chamber and their processes were asynchronously aligned to the work being done. The challenge for many organizations is to determine the best ways to bring the people, processes, and technology supporting these initiatives into the fold without slowing things down. The best organizations are finding new ways to automate policies from security and governance teams by shifting away from artisanal, asynchronous approaches to synchronous processes earlier in the lifecycle.

Let's take a look at an example of application security. A number of technology vendors in the application security arena are touting "automation" as key value point for their solutions in order to better fit them into a DevOps tool chain. In some instances, automation means that machines are now fully responsible for monitoring, analyzing, and fixing security vulnerabilities for those applications at wire-speed. In other instances, automation implies facilitation of human-centric workflows that might represent hours or days of asynchronous analysis not fit for continuous operations. In both cases, the technologies may accomplish similar ends, but their approaches could be dramatically different.

Also, one solution might be built to support asynchronous investigations by a security professional, while the other might provide synchronous support to a developer at the design and build stages of the SDLC. Establishing a vetting process can help determine if the automation levels required by a team or process can truly be delivered before investments are made. It is also worth noting that layers of obscurity frequently exist within words like "automation", "integration", "configuration", and "continuous".

For the complete story, please continue to InfoQ http://www.infoq.com/articles/faster-smarter-devops.

More Stories By Derek Weeks

In 2015, Derek Weeks led the largest and most comprehensive analysis of software supply chain practices to date across 160,000 development organizations. He is a huge advocate of applying proven supply chain management principles into DevOps practices to improve efficiencies, reduce costs, and sustain long-lasting competitive advantages.

As a 20+ year veteran of the software industry, he has advised leading businesses on IT performance improvement practices covering continuous delivery, business process management, systems and network operations, service management, capacity planning and storage management. As the VP and DevOps Advocate for Sonatype, he is passionate about changing the way people think about software supply chains and improving public safety through improved software integrity. Follow him here @weekstweets, find me here www.linkedin.com/in/derekeweeks, and read me here http://blog.sonatype.com/author/weeks/.