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

12.10.2012
| 2784 views |
  • submit to reddit
I’ve spent most of the last decade working on problems in build, deployment and release management. While automation has been a focus of mine, the hard part in these domains have always been around dependency management.

A release day for many enterprise IT groups sees a number of application systems get updates. There’s a great deal of coordination required to make sure each phase of the release is executed by the right people, with dependencies between the applications accounted for.

These applications in turn, are increasingly made of multiple runtime components. These leads to dependency management challenges when service oriented architectures and the like fail to deliver on the promise of being able to upgrade just a small piece of the system at a time. Instead a change to one web service often cascades into updates to those that call it. Tests no longer validate that a single version something works. Rather, they validate that a web of dependent services are delivering desired functionality. Deciding what to promote across environments requires being very dependency aware. Likewise, at deployment time, the various pieces and parts of the system must be released in a coordinated fashion with infrastructure changes.

As we continue to look closer and closer. Our attention turns to the makeup of the runtime component of the application. Breaking it apart, we are unlikely to see just a simple standalone chunk of code that was compiled. Rather, each runtime component is made of a combination of the source code and dependencies on libraries, assemblies or headers. These dependencies can be on versioned system libraries, open source components, commercial libraries, or internally built components designed for reuse. The source code itself has interdependencies that are handled by the compiler/linker or a build script.

Despite what our friends and family tell us techies, we are good hiding complexity. The truth is, the systems we release today are extremely complex. But everywhere I look at see the same pattern repeating itself. We mask that complexity by creating composite projects. The hard part of many of our build and releases activities is keeping track of the components that make up the larger system. What version of this works with what version of that? What do we actually have in some environment? How do we get things delivered by different teams to work together? Over the next few blog entries, I’m going to look at a build, deployment and release dependencies in turn.

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.)

Comments

Orlando Selenu replied on Mon, 2012/12/10 - 3:30pm

Thanks Eric. I'd be delighted to read these articles.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.