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

Download “The DevOps Journey - From Waterfall to Continuous Delivery” to learn learn about the importance of integrating automated testing into the DevOps workflow, brought to you in partnership with Sauce Labs.

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.

Discover how to optimize your DevOps workflows with our cloud-based automated testing infrastructure, brought to you in partnership with Sauce Labs


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

Opinions expressed by DZone contributors are their own.


Dev Resources & Solutions Straight to Your Inbox

Thanks for subscribing!

Awesome! Check your inbox to verify your email so you can start receiving the latest in tech news and resources.


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

{{ parent.tldr }}

{{ parent.urlSource.name }}