For deployments, moving the files is the easy part

Posted on by
1

Deploying software can be a complex endeavor. We often think of it as “getting the software to the right boxes”. But, actually grabbing the bits and moving them out to the right place on the target servers is one of the easier and least error-prone parts.

When I asked the Automating Deployment and Release Linked-in Group to weigh the relative importance of this part, they generally rated it as being less than 20% of the overall effort. That’s in line with what I’ve heard in my conversations with experts across the industry.

The more challenging and time consuming parts of the release seem to be:

  • Collecting the set of stuff that is going out the door as a release set.
  • Coordinating with other groups and communicating with stake-holders
  • Applying per-environment and per-server configuration
  • Keeping track of what was deployed to each target
Even when I demo deployment automation tools, there’s an emphasis on getting the bits to the right places. While a critical piece, keep in mind that it’s just a small part of the overall release puzzle when you are working on making your release process more effective.

For more on deployment automation, you should check out our white-paper Deployment Automation Basics.

 

Posted by Eric Minick
 on March 26, 2013#

Apply Release-Reuse Equivalency to Infrastructure

Posted on by
Reply

A common development pattern is to adopt the Release-Reuse Equivalency model: if two applications depend on some common code, they should reuse only versioned, “released” packages of that code. They should avoid having their own copies, or using source control magic to share the latest uncompiled code. Here’s a decent write-up on release-reuse.

Using versioned releases allows us to isolate ourselves from unwanted changes, encourages avoiding hacks to the common components for our project that would detrimental to others, and helps build a manifest of everything that’s in the application.

But what if two applications share not just some code libraries, but also both run on the same kind of application server, operating system and back-end databases? Should we apply the same rules? I think so.

The DevOps matra of treating “infrastructure as code” provides encouragement. If we have a versioned “library” that is a base virtual machine, a versioned application server install, and versioned rules for applying patches and security settings we have the core of what we need. The run time application can depend on a version of the application, and a version of the software stack it runs on.

The implications for deployment are also interesting. An update to the the infrastructure should be propagated through the environments in conjunction with code updates. Functional testing should be considered to apply to the full stack from VM image to application configuration.

I’m going to continue to play with this concept, but I’d love your feedback. Should only versioned infrastructure be used and should changes to the infrastructure follow a release lifecycle that looks just like application releases?

Posted by Eric Minick
 on March 13, 2013#

C-Suite signals towards DevOps

Posted on by
Reply

CIO.com (and the print edtion) is reporting that CIOs are increasingly looking to embed IT staff in the business units they serve rather than centralize them all directly under the CIO.

With a major theme in both agile development and DevOps being better collaboration of IT teams with the business (“alignment” in C*O speak) these are the kinds of reports we should expect to see more of as Agile and DevOps gain traction. If you notice this happening in your organization, it is a good time to try to nudge the reorg towards aligning dev / qa / ops teams along application boundaries. While the system is in flux, push hard to get closer to an arrangement that will support better collaboration across the application delivery chain.

Posted by Eric Minick
 on March 4, 2013#

8 Deployment Tooling Lessons Learned

Posted on by
Reply

It didn’t take long. A few months after we released an open source continuous integration tool (Anthill) in 2001, we were asked, “It’s great that I have the build setup, now how do I deploy to the test lab?” That email started a clear transformation in our thinking. Lesson 1: Builds generally exist to be tested or released to customers. The corollary is: Continuous integration is not about build, it is about quality and checking quality generally requires a deployment or six.

In 2005, we updated our AnthillPro 2.5 with a shiny new deployment capability. It worked ok, but with that generation of tool being so build oriented, it was never a clean fit. Lesson 2: Deployments are a serious challenge, and can not be bolted on to a build tool. This lesson has been reinforced over the years as we’ve watched the results of various tools tacking on deployments.

In 2006, we released AnthillPro 3. Oh boy, what a change. Continue reading →

Posted by Eric Minick
 on March 1, 2013#