Originally published on 2013-06-18; fully revised and updated.
This post covers IBM’s announcement that it acquired UrbanCode, and why that mattered to organizations building continuous delivery capabilities. If you are a DevOps engineer, release manager, or platform lead, this rewrite helps you separate announcement claims from implementation realities and apply the lessons to modern release automation decisions.

What was announced
The original post quotes a message from Kristof Kloeckner at IBM announcing the acquisition of UrbanCode Inc. The stated rationale was to add UrbanCode’s application release automation (ARA) capabilities to IBM’s broader DevOps portfolio, with emphasis on faster and more frequent software delivery across mobile, cloud, analytics, and traditional applications.
- Reduce delivery cost by lowering manual effort, wait time, and rework.
- Improve time to market by increasing release frequency.
- Reduce release risk by improving quality and compliance in deployment processes.
The original text also includes vendor-stated outcome claims (for example, deployment time improvements and annual savings figures). Treat those as announcement-era claims that require independent validation in your own environment.
Why UrbanCode fit IBM’s DevOps strategy
At a practical level, ARA addresses a common enterprise bottleneck: teams can build and test quickly, but releases still stall in promotion, approvals, environment coordination, and manual deployment steps. By automating those handoffs, an ARA platform can make release flow more predictable, auditable, and repeatable.
That is the strategic fit implied by the acquisition: combining development and test acceleration with stronger deployment orchestration across environments.
Typical ARA delivery workflow
The workflow below represents the type of release path organizations usually target when adopting release automation.
flowchart LR
A[Developer commit] --> B[Build and unit tests]
B --> C[Package artifact]
C --> D[Deploy to test]
D --> E[Automated checks]
E --> F{Approval gate}
F -- approved --> G[Deploy to production]
F -- rejected --> H[Fix and rerun]
Announcement points vs engineering interpretation
| Original announcement point | Engineering interpretation | What to measure internally |
|---|---|---|
| Driving down cost | Automate repetitive release tasks and reduce manual handoffs | Engineer hours per release, failed deployment rework time |
| Speeding time to market | Increase release frequency by standardizing promotion steps | Lead time for changes, deployment frequency |
| Reducing risk and improving compliance | Add gated workflows, audit trails, and repeatable procedures | Change failure rate, rollback rate, audit evidence completeness |
| Continuous release and deployment | Move from ad hoc release execution to pipeline-driven promotion | Release predictability and variance across environments |
Example: release automation pattern (illustrative)
This example is tool-agnostic and intended to show the shape of an automated release process with verification and controlled production promotion.
stages:
- build
- deploy_test
- verify
- approval
- deploy_prod
variables:
APP_NAME: payments-service
VERSION: 1.8.4
deploy_test:
script:
- ./scripts/deploy.sh test "$APP_NAME" "$VERSION"
verify:
script:
- ./scripts/smoke-test.sh test "$APP_NAME"
allow_failure: false
deploy_prod:
script:
- ./scripts/deploy.sh prod "$APP_NAME" "$VERSION"
when: manualCode language: JavaScript (javascript)
#!/usr/bin/env bash
set -euo pipefail
env="$1"
app="$2"
version="$3"
echo "Deploying ${app}:${version} to ${env}"
./release-cli deploy --env "$env" --app "$app" --version "$version"
./release-cli verify --env "$env" --app "$app"Code language: PHP (php)
In production, teams usually add stronger policy checks (change windows, separation of duties, and rollback automation) around this baseline pattern.
Source link and attribution
This article is based on the original DevOpsSchool post quoting IBM leadership and linking to IBM’s announcement. Source: IBM press release.
Best practices when evaluating ARA platforms
- Validate vendor claims with your own baseline metrics before and after rollout.
- Prioritize repeatability and auditability over one-off deployment speed gains.
- Design clear promotion gates between environments, including automated verification.
- Ensure rollback paths are tested, documented, and fast enough for incident response.
- Plan integration scope early: CI, artifact repositories, ticketing, and change controls.
I’m Rajesh Kumar, a DevOps, SRE, DevSecOps, Cloud, and Platform Engineering expert passionate about sharing practical knowledge, real-world experiences, and industry best practices. I have worked at Cotocus and regularly write about technology, travel, investing, health, product reviews, and digital marketing through my various platforms.
I publish technical articles at DevOps School, travel stories at Holiday Landmark, stock market insights at Stocks Mantra, health and fitness guidance at My Medic Plus, product reviews at TrueReviewNow, and SEO and digital marketing strategies at Wizbrand.
Find Trusted Cardiac Hospitals
Compare heart hospitals by city and services — all in one place.
Explore Hospitals