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 77 posts at DZone. You can read more from them at their website. View Full User Profile

Deploying Packages not Components

11.09.2012
| 3649 views |
  • submit to reddit

Those who attended the DevOps: IT’s Automation Revolution webcast last week (recording here), won’t be surprised by my favorite slide from Glenn O’Donnell’s portion of the presentation. He discussed the challenge of moving a complex application through environments, and the likelihood of “droping the ball” and missing a piece when you go to production.

To address that challenge, Glenn suggested that you create a package containing all the components and make that the granularity for deployment. With all the components tied together, you can’t forget a piece or deploy versions that haven’t been tested together to production.

A "Package" ties versions of various components into a version of the application.

At UrbanCode, we love this approach. After a few years of helping AnthillPro customers approximate this with the dependency subsystem, we built uDeploy around the concept of an application model, and a Snapshot Deployment. The Snapshot in uDeploy is a virtual package, that ties together versions of all the components, without creating a single monolithic binary.  It was exciting to see a great analyst explain the rationale for this approach so clearly.

Want to learn more? Check out uDeploy or let us know that you’d like a private demo for your team.



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