In a way, CA Technologies has always been in the business of DevOps—the paradigm just didn’t always have the revelations and philosophy of agile development—and desire to provide a business service to clients that delivers “acceleration, transformation, and security” to IT across the globe. As business on the Internet in mobile, across the web, and other spaces becomes more competitive development and operations teams need to be more capable than ever at reducing the cycle-time of production.

In order to keep up with the times, and better service clients, CA Technologies looked at its product suite and what clients needed to help produce the best solutions for them. DevOps isn’t something that can be bought off the shelf, certainly some elements stay the same (for example the philosophy and approach) but implementation can differ greatly between an enterprise that provides only web-based services and proprietary back-end and a medium business who deploy only mobile games.

CTO John Michelsen of CA Technologies described the path that the company took from its old view of development and operations into the modern, agile field of DevOps solutions.

CA Technologies already produced a variety of systems that assist clients with DevOps, but they were decoupled and scattered. The company has organized its DevOps products into one suite: it started by creating a traditional automation product, and then married it with Dev/Design Time tooling such as visualization, and finally by writing a new strategy for making DevOps application-centric and operations savvy.

This all centered around the Application Delivery business unit, which focuses on four major pillars:

• Service Virtualization: Simulation techniques for rapid development and testing;
• Continuous Delivery System: Building application and getting testing automated as well as making rollbacks as easy as deployment;
• Complete Monitoring: Everything that possibly can must be instrumented with performance management and infrastructure monitoring (this is their traditional space);
• Collaboration Enabling Technology: Allowing the operations technology to enter into the development space as smoothly as possible–this is because Dev and Ops have separate cultures for approaching applications.

Examples of how clients could be CA Technologies for better DevOps

Sometimes clients want to give weekly releases of customer facing code–this is nice when it comes to agility, but it means that it’s unlikely that they would have gotten their testing done with each one. To deal with this they leverage what operations expects (from profiling, delivery expectations, and environmental factors) and communicate that to development via testing automation.

CA Technologies software allows the application software to test itself by loading the same historical patterns in simulated environments–this gives Dev the ability to test as if its in production environment.

Michelsen explained that one problem is that Dev people don’t often use the very products that they make. This is another reason why virtualized environmental testing could help soothe fears that something is untested. To do this, it’s all about learning from production and applying back to development. An example of this is module/product known as “Pathfinder” enables applying historical hacks and exploit-attempts that had hit production back to test suites to new software to make sure that it’s still safe.

In order to allow DevOps teams to collect histories from sensors and data logs the suite is capable of pulling data from numerous sources, not just CA Technologies, and import and leverage that information for customers.

An example of continuous delivery and CA Technologies DevOps

When it comes to continuous delivery, as with providing any DevOps solution, Michelsen says that it’s all about opening up workflow opportunities for clients to take advantage of.

In the beginning: It starts from the build.

As with any system the binary already exists, produced from code and prepared to be deployed, but what CA needs to do is take the build artifact and combine it with configuration and hardware–the idea is to automate abstraction Ops from Dev. In this fashion, development doesn’t need to worry much about what operations is doing. Both groups can define what they expect from the software and its configuration and this changes appropriately when it shifts environments.

Via a ruleset and configuration documentation software has the entire DevOps lifecycle described in infrastructure and configuration, this means that once the product is built it can grab the binary code and put it into place while providing the proper configuration for whatever environment it’s going into.

Hit a button to refresh the Dev environment; push it through to Test with another button press; and finally Ops can bring it out of Test and deploy it live, all the while knowing that the steps for getting the configuration right across each of these stages has been prepared and tested. Less fuss and less muss.

Of course, with any lifecycle, the CA Technologies suite also allows for swift and easy roll back.