See It
Now Try It Yourself
This tutorial provides an overview of the ElectricFlow Deploy object model.
ElectricFlow DevOps automation accelerates development processes and simplifies operations. In the video, we'll show you the Deploy object model. Let's get started.
ElectricFlow Deploy
ElectricFlow Deploy makes deployments manageable, reproducible, and error-proof by modeling the application, the environments that it will be deployed to, and automating the workflow needed for deployment. We can break this into the What, the Where, and the How of your application deployment. What you are deploying is the application, which contains references to the files being deployed. Where the application will be deployed is the ElectricFlow environment. And last, How the application is deployed to the environment is by running processes that orchestrate deployment tasks.
Applications and Processes
Let's look more closely at applications and processes.
Applications are modeled by providing information about their components and defining the processes that orchestrate the deployment of those components. An application object in ElectricFlow consists of one or more application tiers. For example, a three-tiered application with web, application and database server tiers.
The application tier is a logical grouping of components. Each tier contains components. A component is based on an artifact and contains a reference to that artifact. This can be through the filesystem or an artifact repository.
The tier also contains component processes. A component process is a set of actions to be taken on that specific component when the application is deployed. The set of steps in a component process can be defined as direct commands or calls to ElectricFlow plugins or procedures.
At the parent level application, there are application processes. These processes are invoked to orchestrate operations on the application. The steps in an application process can call a component process, run a direct command, or call an ElectricFlow plugin or procedure.
JPetStore Application
Let's take a look at the example JPetStore application in ElectricFlow. The JPetStore application has two tiers: one for the App Server and one for the database (DB) server. Each of these tiers contains a single component.
Let's take a look at the definition of the component in the web server tier. This component definition contains a context reference for the jpetstore-mysql.war file on the file system using the EC-FileSysRepo plugin. You can instead reference the content on your own Maven repository or the Electric Cloud artifact repository. The component contains data on where the file is located on the filesystem, the name of the the file, and the version that will be retrieved.
This component has two processes. Looking at the Deploy process, we can see that it has four steps. Each step has an icon showing the type of action that step performs. The first step is a component process which retrieves the artifact using the details that we provided in the component definition. The second step is a plugin step to unzip the War file, and the third and fourth steps are command blocks.
Back at the application level, we can see that there are two applications defined. Here's the Deploy application process.
A step here can be a call to a component process. The first step is calling the component process that we just saw on the jpetstore-mysql.war component. It calls the Deploy process. In this way, our application Deploy process can call the various component processes and orchestrate the tasks for all of the components from the top level.
Steps in the application process can also be command blocks or calls to plugins and procedures.
Environments
Now that we've seen the What and the How of an application deployment, let's explore the Where--environments.
Environments are modeled using resources that are statically defined on the system, dynamically spun up at deployment time, or a combination of both. An environment object in ElectricFlow contains one or more tiers. These tiers should map with the tiers in the application and are logical groupings of resources.
Each tier defines the resources in that tier, which could be static resources in the ElectricFlow system or dynamic configurations that are spun up on deployment. An environment also contains an Environment Inventory which details the current versions of each component or snapshot that is deployed in that environment.
Once you have defined your application and environment, they must be connected with a tier map. This is the mapping of the application tiers to the corresponding environment tiers where the application will run. Tier maps provide a level of indirection, allowing you to freely add or remove resources from an environment without having to make any changes to the automation.
JPetStore Environment
Now let's look at the JPetStore environment and tier map. In the jpetstore-env environment, there are two tiers as in the application: the first is the JBoss Wildfly App Server tier and second, the MariaDB database tier. The Wildfly tier has one resource assigned to it. This is a static resource existing in ElectricFlow. You can assign multiple resources to a single tier, in which case the component processes for that tier will be run on all of the resources.
Back in the application, there is a single tier map defined. This tier map maps the JPetStore application tier to the associated tiers in the JPetStore environment. With the tier map created, this application can be deployed to the JPetStore environment.
Summary
This tutorial provided an overview of the ElectricFlow Deploy object model. To learn more, visit learn.electric-cloud.com.
What's next
Watch the other videos, and create and run application deployments in ElectricFlow.
To learn more, go to learn.electric-cloud.com.
Comments