Over a million developers have joined DZone.

Dependencies All the Way Down: Run Time & Deployment

DZone's Guide to

Dependencies All the Way Down: Run Time & Deployment

· DevOps Zone
Free Resource

The Nexus Suite is uniquely architected for a DevOps native world and creates value early in the development pipeline, provides precise contextual controls at every phase, and accelerates DevOps innovation with automation you can trust. Read how in this ebook.

This is the third part in our examination of dependencies in build and release.

In part two, we looked at how builds often have both source code and dependencies on libraries. A web application might pull in a third party library that provides XML parsing, and a home grown profanity filter.

At deployment time, we’re worried about a new set of dependencies. That web application probably depends on other components in order to function properly. There may be databases, web services, message buses, third party applications, or content that the application relies on in order to deliver correctly.

Test teams are acutely aware of these challenges. They know that once things get serious, they are rarely testing any single ‘build’ but rather a collection of builds, updates and infrastructure.

There are three major strategies that we see for managing these dependencies:

  1. Minimize:  By using interpreted languages like Java, we lessen our reliance on the hardware specifics. Web services can endeavor to maintain backwards compatible APIs. Databases can use expand / contract patterns to support various queries for a period of time. In short, use extra engineering effort to ensure that each component is compatible with a wide range of versions for other components.
  2. Track: A release manager learns from developers what they believe to be dependent. Release managers then cross-reference deployment requests with the model of relationships they have built and approve only ones that should work.
  3. Aggregate and Test: When the oral histories used for #2 don’t work, we use integration shakeout environments to validate which set of components actually work well together. We then promote the collection of stuff that passed tests together as a unit. In uDeploy we call this collection a ‘Snapshot’. The DevOps principal of “Infrastructure as Code” is meant to make you think of everything else down to the VM as part of this promotable set.
Deployment time dependencies can not be ignored. When you do, the systems fail when individual components are promoted to production. Adding new features and capabilities will often require changes to multiple components forcing release managers to track the changes across several development teams. Using a combination of the three approaches above, development and release teams can minimize their production deployment risks and deliver more rapidly.

The DevOps Zone is brought to you in partnership with Sonatype Nexus.  See how the Nexus platform infuses precise open source component intelligence into the DevOps pipeline early, everywhere, and at scale. Read how in this ebook


Published at DZone with permission of Eric Minick, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}