A common pattern I see is deployment (or build) automation that routinely fails due to a set of common issues. When the deployment fails, people log into the box they were deploying to, perform the well known fix and get on with their lives. This is a trap that minimizes the value of the automation.

Recognizing this (and having seen it rectified at a major customer), I've written up a pattern over at DevOpsWire.com that suggests teams should fix the automation and rerun it to fix the deployment rather than fix the box that was deployed to.

Related Posts
Customer Success Story: A DevOps Team by Any Other Name
The DevOps Scam?
UrbanDeploy's GA Release

Social Bookmarks :              

I get to present UrbanDeploy a few times a week and the part of the demo that always draws questions is when I deploy database upgrades. Why is this spooky magic while application deployments are expected?

Basically, database deployments are hard. Unlike most applications, you can't simply replace the old version with the new. The changes are incremental, they impact data, and they need the blessing of mystics (DBAs). While hard, database deployments are automated by many teams. They treat database changes like code, and use widely available tools to help them with the migrations.

Read more...

Social Bookmarks :              

Ted Dziuba has a great blog entry: "DevOps is a Poorly Executed Scam. The post has been around a while, but I just noticed it and wanted to comment. " The " scam " he points out is that unlike Agile, nobody has put out the book, performed and (as the author of that book or common speaker on the circuit) cashed in with massive consulting rates. I'm sure someone is hard at work in doing that. Ted highlights the folks behind XP and Scrum as executing the "Agile" scam well.

Read on for what we think of the accusation of scamming; some of Ted's suggestions for practical steps to take towards getting better Dev-Ops cooperation; and some practical steps we advise.

Read more...

Social Bookmarks :              

Our team is excited about the release of 3.8 (the last major release under the "AnthillPro" brand). There are lots of great new features and a special emphasis on easier maintainance and management in environments with hundreds or thousands of projects or servers.

Personally, I am particularly excited about using jobs multiple times in a workflow and easier inter-project dependency configuration. For more on the new features, check out the 3.8.0 release page.

Also available (for 3.7+) are new or updated plugins for IBM's Rational Team Concert & ClearCase, Amazon EC2, VMWare vCenter Lab Manager, Bullseye, Microsoft IIS, Websphere, Fitness, Selenium, and TestNG.

Related Posts
Continuous Integration: Why You Don't Really "Get It"
Customer Success Story: A DevOps Team by Any Other Name
What's the Difference: CI vs Build Management?

Social Bookmarks :              

While I can not take the credit for coming up with Continuous Integration (it can be traced back to timeless practices) or for even coining the term, I can take the credit for creating one of the first Open Source (later turned commercial) CI servers -- Anthill, released in July of 2001. That has given me an almost unique vantage point for watching the evolution of CI and seeing it take the industry by storm. One of the most interesting phenomenon I have come across was seeing our customers use AnthillPro (back when it had build only functionality) to automate deployments back in 2004. Keep in mind that this was back in the days before the term Continuous Delivery was coined. At first it seemed to me that the wrong tool was being used for the job. But then I realized that the features present in any implementation of CI really advanced Automation from the invention stage to the innovation stage.

Read more...

Social Bookmarks :              

I recently visited a customer and was surprised to learn just how sophisticated their IT operation is. They have a private cloud for Dev and Test and automated deployments (courtesy of AnthillPro) across all environments. The development and QA teams may request an environment for a specified period of time and then deploy their build to this environment for testing. This entire system, the environment provisioning and the application deployment is fully automated and turns what used to be a multi-week process into a one that literally takes minutes. BTW, these environments are non trivial as they are made up of multiple virtual machines along with network configuration, firewall rules, load balancing, edge caching, and more.

Read more...

Social Bookmarks :              

I was recently brought into a conversation about continuous integration and build management. The questions were predictable: What's the difference? Are they the same thing? They're both kinda about build, right? The two efforts are quite different. However, in practice, the steps taken to achieve them overlap significantly. Definitions of CI and Build Management as well as how their interplay came to define the CI tool market, after the jump.

Read more...

Social Bookmarks :              

Vast majority of daily practitioners of Continuous Integration don't really understand it. This is a bold statement, I know. But it is not made to simply capture attention. Most practitioners of Continuous Integration, when asked, will either tell you that CI is about integrating changes often, or that it's about producing frequent builds of your software. Both these answers are incomplete at best. Even articles on Continuous Integration gloss over the thinking behind it and jump straight to the implementation.

So this blog entry is about the "thinking" behind Continuous Integration. Because only by understanding the core ideas behind CI can you understand what is happening in the industry now or get a glimpse of where it is headed in the future. Once you "get" the core concepts behind CI, it's easy to see that Continuous Delivery is a natural extension of Continuous Integration.

Read more...

Social Bookmarks :              

With more and more companies looking into automation solutions it’s only natural that the debate of risk vs. reward enters the discussion. Recently I’ve heard the question, “What are the true benefits of automating deployments?” Most people would argue that automation will:

· Help avoid human errors that can occur when deploying manually.

· Lower the amount of time a deployment takes.

· Give folks back their weekend

These are all undoubtedly true when implementing deployment automation, but at the end of the day they are simply components of a greater advantage. The true benefit of automating deployments is enhanced business efficiency, effectiveness, and capability. In other words, when automated, deployment enables growth and change rather than existing as a bottleneck to advancement.

Read more...

Social Bookmarks :              

In an enterprise environment patience and small victories are key, when introducing automation into software deployment. This week, I had a conversation with a release manager that reinforced what I know about large organizations. Big change is hard to drive quickly because organizational inertia is so great. Look for little victories in areas the company is ready to take a risk on, and use that to become a trusted provider of a good service to the rest of the company.

Read more...

Social Bookmarks :