Electric Cloud today took a leap into the deep end of the DevOps pool with the release of ElectricDeploy, a tool designed to help automate the deployment of complex, multi-tier (typically J2EE) applications.

ElectricDeploy is a model-driven solution that sits above the company’s ElectricCommander execution engine for building, testing, releasing and deploying applications, and can be used to create workflows that can be automated to speed what the company is calling failsafe deployments.

DevOps, according to Electric Cloud vice president of marketing Kalyan Ramanathan, is an extension of agile development practices into operations. “Agile is concrete, with a set of best practices and a set of tools and a set of ways of doing things that are well codified,” he said. “DevOps essentially extends agile to the ops world. If Dev runs at a certain speed, if Dev can code in 15-day Scrums and move the ball significantly forward, Ops needs to run at the same cadence, otherwise whatever value is being provided by Dev is being impeded by the last mile—which is Ops—because they’re not able to deliver this value to end customers and end users.

“From a more tangible perspective, what this means is there needs to be a common set of tools and best practices that needs to be used by both Dev and Ops. Deployment happens to be one of those areas where it makes natural sense for Dev and Ops to use a similar solution. Dev does deployment, Ops does deployment. Dev does a lot more deployment than perhaps even Ops does. Dev has a lot of understanding of the apps and its configurations and how it needs to get tailored for these various environments, and it would be stupid for Ops to pretty much rediscover this every time around to the extent they can leverage all the right models that Dev has in its organization to model the app, to model the environment, to model the workflows and the processes to do deployment. It just makes sense for Ops to leverage all of these same skill sets, same artifacts, same knowledge.”

Keeping up with the workflow
The fact that ElectricDeploy is based on models helps provide a consistent way for all teams—development, QA, release and production—to follow a workflow process, Ramanathan emphasized. “If you want a consistent solution for all these teams, you cannot have an ad hoc way of doing things. What you need is a type model, and we do that in ElectricDeploy through three models. The first is an application model, which you typically define once, and that typically highlights the various components that make up an application: Web, application server, database, middleware, etc. It also speaks to the dependencies of these components; it speaks to the various configurations of these components, so now I can put my arms around what is the application.

“The next piece of the model is ‘where,’ and where essentially means the various environments where I’m going to deploy this application. The ability to model the infrastructure, the configurations of the infrastructure, the Apache Web Server, and the WebLogic/WebSphere app server, and the Oracle database servers or the VMs that may be involved in that environment, is very important. You will have many models depending on the number of environments you’re going to be deploying the application to.

“Finally there is the ‘how’ of the model, which is how do you marry the application to the environment, and that’s typically through a workflow process-execution engine, and we have the ability to very easily create these workflows in our product. So using these models—the what, the where, and the how—we are able to now automate the process of deploying an application to the various environments using the workflow model.”

Ramanathan said Electric Cloud sets itself apart by providing the ability to create what it calls a failsafe deployment. “The place where we really differentiate is by leveraging the fact that deployment happens many times through the release process, and to the extent we can iteratively refine the deploy process, we can capture errors in the deploy process early on, and we can fix these errors as we go through the process. And what it will ensure is, as you get to the final and most critical deployment that impacts the business, that will be as bulletproof as it possibly can be.”

This “failsafe” capability is provided through three mechanisms, he said: Codesafe, Runsafe and Recoversafe. ElectricDeploy comes with an IDE-style environment where developers—or any stakeholder in the process, for that matter—can actively debug the deployment process. “It’s a developer-style interface where you can put debugs, you can stop at a particular step, you can change configurations, you can define what you want to do next, you can skip things on an as-needed basis, and you can restart the process and see that the right things happen at the right times,” he said.
 
The second mechanism—Runsafe—enables users to threshold what is defined as a success or failure. As an example, Ramanathan said, if three of 10 servers on a Web tier fail to deploy, but the application still runs at an acceptable performance level, the user could choose to call that a success and let the remainder of the deployment continue. “The whole notion of Runsafe here is to say, ‘Look, the world is complex, applications are complex, the environments are complex…things will fail.’ Try as hard as you want to, but things will go wrong anyways. So what you need to have is the ability to dynamically account for and compensate for things going wrong.”

The ability to threshold, he said, “allows us to compensate for and accept real-world challenges that you would see in just about any environment.”

The final aspect—Recoversafe—is all about gracefully recovering from errors, Ramanathan said. “If 99 servers worked well and one didn’t work right, we have the ability to create rollback procedures, so you can roll back the 99 if you didn’t think it was the right thing, or roll forward and fix the one server that had the problem.”