DevOps Zone is brought to you in partnership with:

Leaving university, I thought I'd be a developer happily knocking out code but was always drawn to tech support. How do we help people use our tools better? Now, I mostly specialize in consulting and introducing new customers to our tools. I am a Tech Evangelist and Lead Consultant at Urbancode. Eric is a DZone MVB and is not an employee of DZone and has posted 79 posts at DZone. You can read more from them at their website. View Full User Profile

Dependencies All the Way Down: Run Time & Deployment

01.22.2013
| 2741 views |
  • submit to reddit

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.
Published at DZone with permission of Eric Minick, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)