This manual contains general background information for users of Deployit.
Deployit is the first out-of-the-box deployment automation solution that allows non-experts to perform application deployments. A deployment consists of all the actions needed to install, configure and start an application on a target environment. Deployments are defined by:
Once the what and the where are known, h Deployit (and it's runbooks) takes care of the how by putting together a list of steps (such as copying files, starting / stopping application servers) that perform the actual deployment.
Deployments can be categorized into two major categories:
A deployment is an initial deployment when the package is deployed to the environment for the first time. This type of deployment typically requires some effort to get right because all deployed items must be specified and configured. A user familiar with the middleware setup and with experience in this area is normally involved in this activity.
Once the initial deployment has been configured, all subsequent deployments of the package to the environment are upgrade deployments. These deployments reuse the deployed items from the initial deployment and can typically be performed without any further configuration. Consequently, users without any knowledge of the middleware setup can perform these deployments.
These are the main concepts in Deployit, in alphabetical order.
An archetype is a die for creating many similar Configuration Items (CIs) and are a way to reduce duplication of data. An archetype contains default values for properties that are the same for all of the CIs that are created based on the archetype. CIs created from an archetype have the option of overriding the values from the archetype. A CI created from an archetype keeps the link to the archetype so that updates to the archetype's properties are immediately made for all of the related CIs. Archetypes can also be nested.
For example, if we define an archetype UnixHost that has the property OS Family set to the value UNIX. If we create host CIs web1 and web2 based on the UnixHost archetype, both host CIs inherit the OS Family property from the archetype. If we change the OS Family property to WINDOWS on the archetype, the value will automatically change for both host CIs. If we change the OS Family property to WINDOWS on web1, this overrides the value on the UnixHost archetype. Any changes to OS Family on the archetype now only affect the web2 CI.
Artifacts are files containing application resources such as code or images. The following are examples of artifacts:
In the Unified Deployment Model, a complete application (consisting of both artifacts and middleware resources) is contained in a single deployment package.
The Deployit CLI provides a way to programmatically interact with Deployit. The CLI can be programmed using the Python programming language. For more detailed information, see the Deployit Command Line Manual.
A configuration item (CI) is a fundamental structural unit in a configuration management system. In Deployit, a CI is a container for properties and relations to other CIs. A CI holds information about a part of the infrastructure, application or deployment. A CI has a certain type that determines what information it contains and what it can be used for.
The following are some examples of CIs:
Deployit CIs all share certain properties:
Some properties of a CI are mandatory (must be given a value before the CI can be used), others are optional. To determine which properties are available and which are mandatory or optional for a CI, see the CI Reference or use the help facility in the Deployit CLI.
Deployed items are members of a deployment package that have been deployed on some target middleware. The deployed item can be configured for the specific target it is mapped to during the deployment. When configuring a deployed item it is possible to override any CI properties that the CI has in the generic package. This allows a single package to be used in different environments.
This process installs a particular application (represented by a deployment package) on an environment. Deployit copies all necessary files and makes all configuration changes to the target middleware that are necessary for the application to run. If there is already a version of the application running on the environment, the deployment is an upgrade rather than an initial deployment (see Upgrading an Application). Before performing an initial deployment, all deployed items must be configured correctly for the deployment to work.
The DAR format is the native format Deployit supports for deployment packages. A DAR file is basically a Java jar archive containing a specially formatted manifest. The archive contains the package's artifacts while the middleware resources are described in the archive's manifest file. Deployit processes the manifest file to know which CIs are stored in the archive.
For a comprehensive description of the manifest format, see the Deployit Packaging Manual.
A deployment package is an archive containing a particular version of an application, containing all artifacts and middleware resources that the application needs. It is independent of the environment it is deployed in (see Unified Deployment Model).
Deployit accepts packages in the Deployment ARchive (DAR) format.
An Environment is a grouping of infrastructure items, such as hosts, servers, clusters, etc. Environments can contain any combination of infrastructure items that are used in your situation. An environment is used as the target of a deployment, allowing members of the deployment package to be mapped to members of the environment.
Middleware resources are pieces of middleware configuration that an application is dependent on. The following are examples of middleware resources:
In the Unified Deployment Model, a complete application (consisting of both middleware resources and artifacts) is contained in a single deployment package.
A plug-in is a self-contained piece of functionality that adds capabilities to the Deployit system. Plugins contain Runbooks, Steps and Configuration Item types.
The repository is a storage space for all things Deployit knows about. This includes configuration items (CIs), binary files (such as deployment packages) and Deployit's security configuration (user accounts and rights). The repository can be stored on disk (default) or in a database (see Configuring Database Storage).
In Deployit, the repository conforms to the Java Content Repository (JCR) standard. Deployit's repository has a hierarchical layout and a version history. The repository stores all CIs of all types. The top-level folders indicate the type of CI stored below it. Depending on the type of CI, the repository stores it under a particular folder:
Deployit's repository contains CIs that are containers for other CIs. There are two ways in which CIs can refer to each other:
Deployed applications have a special structure in the repository. A deployed application is the result of deploying a package to an environment. While performing the deployment, package members are installed as deployed items on individual environment members. In the repository, the deployed application CI is stored under the Environment node. Each of the deployed items are stored under the infrastructure members in the Infrastructure node.
So, deployed applications exist in both the /Environment as well as /Infrastructure folder. This has some consequences for the security setup. See the Deployit System Administration Manual for details.
A runbook is a component that generates a steplist when presented with a task. A runbook can produce steps for any task or only for particular tasks. A runbook is integrated into Deployit by means of a plug-in.
Deployit ships with the following runbooks:
XebiaLabs also provides the following optional runbooks:
It is also possible to customize Deployit by building your own runbook from scratch or by changing an existing runbook. Please see the Deployit Programmers Manual for more information.
A step is one concrete action to be performed to accomplish a task. A step is created by a runbook and contained in a steplist. Deployit ships with a number of standard infrastructure steps. Other middleware-specific steps are contributed by the plugins.
The following are examples of steps:
A steplist is a sequential list of steps that is generated by one or more runbooks when a task is executed. The steplist contains all steps that Deployit will execute to perform the task.
A task is an activity in Deployit. When starting a deployment, Deployit will create and start a task. The task contains a list of steps that must be executed to successfully complete the task. To execute the task, Deployit will execute each of the steps in turn. When all of the steps are successfully executed, the task itself is successfully executed. If one of the steps fails, the task itself is marked stopped.
Deployit supports the following tasks:
Deployit periodically stores a snapshot of the tasks in the system to be able to recover tasks if the server crashes. If this happens, Deployit reloads the tasks from the recovery file when it restarts. The tasks, deployed item configuration and generated steps will all be recovered. Tasks that were running in Deployit when the server crashed will be put in STOPPED state so the user can decide whether to rerun it or cancel it. Tasks that were not yet started (for instance, a deployment for which only mappings have been configured, but no steplist was generated) will not be recovered.
When a user logs in, the Deployit GUI loads any tasks that are pending for this user from the repository and displays them in tabs. This includes tasks that were stopped or executing when the user closed his browser,
Deployit allows a user to interact with the task. In addition to starting a task, a user can:
This process removes an application from an environment. Deployit stops the application and removes the package from the target middleware.
The UDM is XebiaLabs' model for describing deployments and is used in Deployit. The UDM consists of the following components:
This process replaces an application deployed to an environment with another version of the same application. If the application is not running on the environment, the deployment is an initial deployment (see Deploying an Application). When performing an upgrade, most deployed items can be inherited from the initial deployment. Deployit recognizes which artifacts in the deployment package have changed and deploys only those artifacts.
Deployit ships with a number of configuration items that you can use to define your middleware configuration and deploy applications. This section contains an overview of these CIs, their purpose and the properties they support. This section of the manual was generated from the Deployit CLI interface.