Our Perspective on DevOps – UC4 Guest Blog Post

November 7, 2012 Wesley Pullen

This is a guest blog post by Wesley Pullen, VP of Global ARA Technologies at UC4. UC4 Software is the world’s largest, independent IT Process Automation software company for organizations facing increasingly dynamic applications and infrastructure, and those migrating to next generation service models for cloud, DevOps, and big data.

Throwing Software Over the Wall

We used to throw software over the wall. It’s just the way things were. You developed your application, tested it a few times and once its ready for production you “threw it over the wall” and let the Ops guys worry about it. Production environments were isolated and centrally managed not only to ensure compliance but mostly in order to ensure business continuity and adequate performance. “If it works don’t touch it.” Production releases and new deployments were avoided as much as possible and highly restricted. Only the most experienced engineers are allowed to deploy anything new to production. All in an attempt to avoid service degradations and outages from an IT Operations perspective; it is all about protecting the business.


The business environment has radically changed in the last decade.  However, sophisticated software platforms and the Internet has opened up new and relatively cheap ways for competitors to enter almost any marketplace and force the respective incumbent enterprises to react and operate in a more agile way or face risk of losing market share. From a technology perspective, advances in virtualization technology and cloud infrastructure are making it possible for competitors to gain access to immediate computing power on-demand. From a software development perspective new methodologies (such as scrum) and Agile ALM solutions like TeamForge are transforming the way teams collaborate to engineer new products and bring them to market. It all happens much faster than ever before. From the engineering perspective it’s all about giving the business a competitive edge.

If you read the two paragraphs above you have likely noticed the conflict. One group is trying to protect the business by reducing friction and keeping changes to a minimum while the other is working hard to introduce as many new capabilities as possible and maintain a competitive edge. The business sides with both. It cannot afford outages and bad performance and it must remain competitive and move fast. The goal of the DevOps movement is to reconcile the conflict, sounds impossible right?

1, 2 & 3

It is not impossible. In fact the way forward is a simple three (3) legged formula:

1. Developers that learn to think like OPS

2. Operations that learn to think like DEV

3. An end-to-end collaboration and automation platform that connects them

1 & 2

The DevOps movement started from points 1 and 2 above. Likeminded developers and system administrators started to collaborate more to reduce error rates and overcome problems. Facebook for example, has taken this to the company level and is reportedly only employing people who understand code in any technical position, Ops or Dev. This is a luxury only a few can afford. Typical DevOps teams are initially focused on provisioning and configurations. Tools such as Puppet and Opscode Chef have sprung out of the movement in an attempt to automate as much as possible and reduce risk. Concepts such as environment as code from Opscode and PuppetLabs help DevOps teams to automate beyond what the cloud provides and lets them quickly align large number of servers to known configurations and a desired state. We are left with the most important piece – the applications that sit on top of these well configured servers, and serve the business.

Application Release Automation (ARA)

ARA technology lets DevOps teams design and execute visual deployment workflows that take care of all the complexities of deploying the application to different environments, including production. Instead of a documented manual procedure or a bunch of custom scripts, ARA uses visual workflow diagrams built from a huge library of built in run books. Run books exist for every application, web, messaging and database server in the book – pun intended. These built in run books have many advantages over scripts and manual operations: they are capable of automatically rolling back in case of need, they are cross platform, fully audited and have impersonation capabilities to execute as different users in varying conditions. ARA workflows handle cross tier dependencies and deploy a multi-tier application to any number of servers an order of magnitude faster than existing techniques.  An ARA solution provides a built in deployment model that keeps the workflows simple and lets DevOps team collaborate and still keep their respective duties.


TeamForge Deploy with UC4 is a new product co-developed by UC4 and CollabNet that we are introducing. We haveDevOps and ALM with TeamForge and UC4 taken our ARA platform and fused it right into TeamForge. We didn’t just link the two applications; we really took the time to think how to best make our two platforms work in concert, and we are proud of the outcome. We integrated the TeamForge build system with the UC4 ARA packaging module and made workflow editing, execution and monitoring available from a new “Deploy” tab right within TeamForge. We believe this is the most advanced DevOps platform in the world today, and we have tested it to scale to very large environments. Our aim has been to provide that last #3 item: an end-to-end collaboration and automation platform that connects Dev and OPS teams and allow them to reconcile the conflict I just talked about. It does so with great success. Automation eliminates the human error factor from the deployment process and enables deployments to happen at any speed with the assurance of automatic rollback and a full audit trail.

Finally, we are not done!  We are already working on the next stage of developing our integrated DevOps platform and it promises even more exciting new features.

Stay Tuned!

Wesley Pullen.


Previous Article
Too Much ‘Management’ & Not Enough Agile in Your Agile Tool?
Too Much ‘Management’ & Not Enough Agile in Your Agile Tool?

Anyone feel like the clutter required by your management overhead cuts into the team’s productivity?  It’s ...

Next Article
Deconstructing a Branch — Rolling Up Our Sleeves, Battling the Beast (Part 5 of 5)
Deconstructing a Branch — Rolling Up Our Sleeves, Battling the Beast (Part 5 of 5)

This is the final installment in the continuing saga of cleaning up the feature branch I put through the Os...