Component-Capable Release Management is Key to DevOps

Part 3 — Part 4 Component-Capable Release Management is Key to DevOps – Part 5 Up Next

DevOps conversations are dominated by release management and production deployment. These are the primary topics at the DevOps conferences that we have attended in Atlanta, New York, Vancouver, Portland, Barcelona and London. This concerns me at some level – if DevOps just becomes a fancy word for IT Ops, then the movement will not be that important – but it’s the reality given the DevOps is a new, immature approach. Not only are the conversations primarily about these topics, many of the discussions are tools or technology related – what CI and CD tools are best? What packaging construct should be used?, etc.

So why are the conversations focused on release management and deployment? Given that DevOps is a reaction to Agile, some say that “DevOps completes Agile”, the first thing that the IT Ops has to do is to keep up with agile delivery – that means deploying small and frequent changes in a repeatable, reliable and predictable fashion. It’s a natural and necessary starting point – if DevOps can’t support this capability, then it will fall all over itself when it tries to move to more strategic topics like incorporating security and compliance efforts into the software lifecycle process.

This is not an easy task since many organizations have diverse and large environments. Given that organizations are trying to deploy more often, approaches that rely on manual intervention just won’t work – so organizations that can automate every single aspect of the release and deployment process can outmaneuver their competitors. This is key – just think of the business advantage that an organization has if it can modify it’s website to react to user behavior, or if it can modify it’s production systems quickly to introduce new products. The impact can be significant – so if you are looking for budget justification for your DevOps efforts; try relating release and deployment speed to business agility.

So what does this all have to do with Sonatype? Well, Sonatype is all about helping people manage and leverage components effectively, including open source components. We know that the average application is now constructed of 80% or more components, so the release management and deployment process has to take this into account. While components help developers construct applications quickly, if your infrastructure isn’t capable of managing components effectively, you will introduce risk into your applications – security, licensing and quality risk. As you think about assembling the right mix of tools to support your build and release process, including Continuous Integration and Continuous Delivery tools, make sure you factor in components.

Here are a few things to consider

• Repository Manager Foundation – Start with a repository manager that can help you store and share your binaries effectively. As you scale your efforts, your repository should scale with you – and it should provide the enterprise class features like security, build promotion and staging, etc., that you need to manage all of your components effectively.

• Policy-based Support for Build Promotion and Staging – Instead of automating the approval process for components, use automated policies that apply your security, licensing and architecture standards to the release management process. The automated policies should provide guidance and enforcement (e.g., stop a build from being deployed) so that you can ensure your production systems are rock solid.

• Factor Components into your CI & CD Initiatives – As organizations leverage continuous integration technologies to automate the build and test process, and to extend automation into the deployment realm with Continuous Delivery approaches, they need to think about the role of components. One way to do this is to integrate your component management and governance approach directly into the build and CI technologies. This allows you to apply your policies and enforce action directly in those tools.

The good thing about this approach is that you end up incorporating other constituents into the process – you may be thinking, “I need to manage the release process. I need to keep up with the Developers. I need to automate building and deploying my VMs.” By leveraging security, licensing and architecture policies in your build and release management process, you are automatically incorporating the security, legal/compliance and architecture teams into the process. That’s a completely natural fit since DevOps is about driving collaboration and communication between constituents involved in the software lifecycle.