Category Archives: Deploy

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.

 

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 →

The ROI of Deployment Automation

Posted on by
Reply
Measure both how much something costs (investment) and what it will save you combined with benefits (return).

Image credit: RambergMediaImages

If you follow my blog, you probably know that I think that continuous delivery and the broader category application deployment automation are pretty great. I spend a lot of time working with engineers and architects who ‘get it’ but need some help selling the idea to their management. They need to build a business case, a return on investment (ROI). Researching this with some customers, I was able to put together a four page white-paper on release automation ROI. The basics:

Manual Deployments are Bad

Really, really bad. So bad that I’m recorded in this webinar calling on them to die. Manual deployment processes are labor intensive enough not to scale. They are too painfully slow. Worst of all, they are naturally error prone.

From labor intensive to push button

Many teams I work with turn to automation when their deployment complexity gets out of hand. Whether it is because they have too many moving parts, too many servers, or just too many deployments a release engineering team can’t keep up at a pace that satisfies their customers (the business and development). To keep up, they would need to hire many more people just to run through deployment plans all day. Instead of incurring that cost, they invest in automated deployments where they can provide push-button deployments to other groups in lower environments, as well as production deployments for themselves. They can then turn toward higher value work of engineering zero downtime deployments and the like.

Continue reading →

Dependencies all the way down – Run Time & Deployment

Posted on by
Reply

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. Continue reading →

“Application Release Automation” is a terrible term

Posted on by
2

The analysts agree, uDeploy and its competitors are “Application Release Automation” tools. We used the same term on our website.  Unfortunately, “Application Release Automation” is a bad description for this class of tools.

Let’s look at the three words in this term and see what fits:

  • Application: Not bad. This scopes things down to software applications rather than hardware or endangered animals. The Application also indicates that we’re working at larger scope than a single tier or component, which is also ok.
  • Release: To release an application, generally means to deploy it into the production environment. Certainly, production is in scope for these tools, but pre-prod environments are as well. Using the same process in prod and testing environments is a best practice. “Release” might be pointing to heavily towards production. In many companies a “Release” is scoped far larger than a single application or application group. A release can contain numerous unrelated applications. That’s not what ARA is about. 

    Similarly, we have shared terminology with release management. Is this tool automating a release managers job? Not really, while it can enforce some quality gates and provide better visibility it doesn’t have a detailed Release Management feature set. At UrbanCode, we even provide a specialized release management tool to focus on those topics.

  • Automation: Not bad. Most people look to a tool like this when they want to greatly improve the speed and quality of their deployments by automating as much as possible.

So the problem is with “Release”. It suggests that we should ignore earlier environments and implies more of a release management role than the tools really fill.

What would be better?

We propose Application Deployment Automation (ADA). Tools like uDeploy are automating the deployment of applications.

Sometimes its a deploying to production – a release. Sometimes its one of the many deployments to the test labs that get us ready for the eventual release. What a tool like uDeploy does extremely well is let you define a standard process that is used in both environments.

Like this sort of thing? Here are other blog posts where I nitpick about jargon:

For Audit, control the binaries

Posted on by
Reply

We include a built in package repository, CodeStation, with AnthillPro, uBuild and uDeploy. They also  integrate with third party repos.  We place much emphasis on this capability because it is critical for safety, governance and audit.

To explain this, let’s first look at a simplified build and release lifecycle:

 

Code, then build, then deploy to test environments, then deploy to production. Developers submit their work to a source control system. A build is generated from that source and any dependency libraries retrieved by a tool like Maven or CodeStation. That build is submitted to test environments and certified. Finally, it is sent to production.

The following questions are important to be able to answer:

  1. What is in production?
  2. Was it certified in test environments (and by whom)?
  3. How do you know your answers to #1 and #2 are true?

To be able to answer 1 and 2, you need an inventory of what version of something is in an environment or at least logging that indicates the version number. But to truly know that what is in production is what was tested, you have to ensure that not just are the file names the same, but that the exact same files were moved into each environment.

In order to know and prove that the files are the same, one must validate that they are bit-for-bit identical by comparing digital signatures or hashes at deployment time. It helps to actually have the original file around in a tamper resistant location. A good package repository, like the one in uDeploy, will provide that location, the automatic signature generation at build time, and the automatic verification so that you know that what is in production is exactly what was built from known source, and tested in the prior environments.

For more information on package repositories, view our on-demand best practices lesson: 'The Role of Binary Repositories in SCM'