This manual describes how to customize Deployit for use in your environment.
Out-of-the-box, Deployit provides deployment capabilities for several middleware platforms. However, at times we need to integrate Deployit with certain environments or deploy to middleware stacks that Deployit does not readily support. Tailoring deployment plans, adding support for new middleware and integrating with other systems are all possible by customizing the Deployit system. This manual describes what customizations are possible and how to adapt Deployit to fit into your environment.
This manual will first give an overview of the different ways of customizing Deployit. Then, Deployit system architecture is described to show the role of Deployit extensions and plugins in the deployment process. Finally, we show how to add custom Deployit plugins.
Deployit is designed with extensibility in mind and provides several different ways to modify its behavior. Depending on the extender's skill set and requirements, one or more of these methods can be used to achieve the desired result.
There are four ways to customize Deployit.
Each of these types of customizations are described in the remainder of this document.
Today's middleware products are complicated and support lots of configuration options. Deployit plugins represent this middleware to the Deployit system. If a plugin wants to be a direct representation of the options in the middleware, it will quickly grow very large and unwieldy. Deployit provides a better way.
Given a CI defined in a plugin, an extender can customize this CI by adding new synthetic properties to the Java class, or by using the type system to extend the CI. These additions can either be done using plain Java, or by defining them in an XML file called synthetic.xml which can be added to the Deployit classpath. Changes to the types are loaded when the Deployit server starts and can be used to perform deployments.
Types existing in Deployit can be modified to contain additional synthetic properties. These properties become a part of the CI type and can be specified in the deployment package and shown in the Deployit GUI.
There are several reasons to modify:
The following information can be specified when modifying a CI:
| Property | Required | Meaning |
|---|---|---|
| type | Yes | Specifies the CI type to modify |
Additionally, any property that is modified is listed as a nested property element. For each property, the following information can be specified:
| Property | Required | Meaning |
|---|---|---|
| name | Yes | The name of the property to modify |
| kind | No | The type of the property to modify. Possible values are: enum, boolean, integer, string, ci, set_of_ci, set_of_string, map_string_string |
| description | No | Describes the property |
| category | No | Categorizes the property. Each category is shown in a separate tab in the Deployit GUI |
| label | No | Sets the property's label. If set, the label is shown in the Deployit GUI instead of the name |
| required | No | Indicates whether the property is required or not |
| password | No | Indicates whether the property stores a password. If so, the property value is encrypted in the Deployit GUI and CLI |
| size | No | Only relevant for properties of kind string. Specifies the property size. Possible values are: default, small, medium, large. Large text fields will be shown as a textarea in the Deployit GUI |
| default | No | Specifies the default value of the property |
| enum-class | No | Only relevant for properties of kind enum. The enumeration class that contains the possible values for this property |
| referenced-type | No | Only relevant for properties of kind ci or set_of_ci. The type of the referenced CI. |
| as-containment | No | Only relevant for properties of kind ci or set_of_ci. Indicates whether the property is modeled as containment in the repository. If true, the referenced CI or CIs are stored under the CI |
| hidden | No | Indicates whether the property is hidden. Hidden properties don't show up in the Deployit GUI. Note that a hidden property must have a default value |
| transient | No | Indicates whether the property is persisted in the repository or not |
See the appendix for the full XSD of this format as used in the file synthetic.xml.
Here are some examples of modifying a CI.
The following XML snippet hides the connectionTimeoutMillis property for Hosts from the UI and gives it a default value:
<type-modification type="base.Host">
<property name="connectionTimeoutMillis" kind="integer" default="1200000" hidden="true" />
</type-modification>
For example, you could add a notes field to a CI to record notes:
<type-modification type="overthere.Host">
<property name="notes" kind="string"/>
</type-modification>
It is also possible to define new CIs using this mechanism. By specifying a new type, its base (either a concrete Java class or another synthetic type) and namespace, a new type will become available in Deployit. This means the CI type can be a part of deployment packages and created in the Repository browser. Each of the three categories of CIs (deployables, deployeds and containers) can be defined this way.
The following information can be specified when defining a new type:
| Property | Required | Meaning |
|---|---|---|
| type | Yes | The CI type name |
| extends | Yes | The parent CI type that this CI type inherits from |
| description | No | Describes the new CI |
| virtual | No | Indicates whether the CI is virtual (used to group together common properties) or not. Virtual CIs can not be used in a deployment package |
| deployable-type | No | Only relevant for deployed CIs. The type of deployable CI type that this CI type deploys |
| container-type | No | Only relevant for deployed CIs. The type of CI container that this CI type is deployed to |
| generate-deployable | No | Only relevant for deployed CIs. The type of deployable CI to be generated. This property is specified as a nested element |
For each defined CI, zero or more properties can be specified. See the section above for more information.
Here is an example for each of the CI categories.
Usually, deployable CIs are generated by Deployit (see the generate-deployable element above). The following snippet shows an example of defining a deployable manually:
<type type="acme.CustomWar" extends="jee.War">
<property name="startApplication" kind="boolean" required="true"/>
</type>
This XML snippet shows how to define a new container CI:
<type type="tc.Server" extends="generic.Container">
<property name="home" default="/tmp/tomcat"/>
</type>
This XML snippet shows how to define a new deployed CI:
<type type="tc.WarModule" extends="udm.BaseDeployedArtifact" deployable-type="jee.War"
container-type="tc.Server">
<generate-deployable type="tc.War" extends="jee.War"/>
<property name="changeTicketNumber" required="true"/>
<property name="startWeight" default="1" hidden="true"/>
</type>
The tc.WarModule CI is generated when a tc.War is deployed to a tc.Server. The new CI inherits all properties from the udm.BaseDeployedArtifact CI and adds the required property changeTicketNumber. The startWeight property is hidden from the user with a default value of 1.
In addition to defining CIs, it is also possible to define methods on CIs. Each method can be executed on an instance of a CI via the GUI or CLI. Methods are used to implement control tasks, actions on CIs to control the middleware. An example is start or stopping of a server. The CI itself is responsible for implementing the specified method.
This XML snippet shows how to define a control task:
<type type="tc.DeployedDataSource" extends="generic.ProcessedTemplate" deployable-type="tc.DataSource"
container-type="tc.Server">
<generate-deployable type="tc.DataSource" extends="generic.Resource"/>
...
<method name="ping" description="Test whether the datasource is available"/>
</type>
The ping method defined above can be invoked on an instance of the tc.DeployedDataSource CI through the server REST interface, GUI or CLI. The implementation of the ping method is part of the tc.DeployedDataSource CI.
It is possible to add validation rules to properties and CIs in the synthetic.xml. Out of the box, Deployit comes with the regex validation rule, which can be used to define naming conventions using regular expressions.
This XML snippet shows how to add a validation rule:
<type type="tc.WarModule" extends="ud.BaseDeployedArtifact" deployable-type="jee.War"
container-type="tc.Server">
<property name="changeTicketNumber" required="true">
<validation type="regex" regex="^JIRA-[0-9]+$" />
</property>
</type>
The validation will throw an error, when the tc.WarModule is being saved in Deployit with a value that is not of the form JIRA-number.
Using the type system, the Deployit plugins provided by XebiaLabs can be customized. New CI properties or scripts can be added to supplement the functionality delivered by the plugin. More information about this can be found in the respective plugin manuals.
Functionality in the Deployit Server can be customized by using plugpoints. Plugpoints are specified and implemented in Java. On startup, Deployit scans its classpath for implementations of its plugpoints in the com.xebialabs or ext.deployit packages and prepares them for use. There is no additional configuration required.
The Deployit Server supports the following plugpoints:
A protocol in Deployit is a method for making a connection to a host. Overthere, Deployit's remote execution framework, uses protocols to build a connection with a target machine. Protocol implementations are read by Overthere when Deployit starts.
Classes implementing a protocol must adhere to two requirements:
The OverthereConnectionBuilder interface specifies only one method, connect. This method creates and returns a subclass of OverthereConnection representing a connection to the remote host. The connection must provide access to files (OverthereFile instances) that Deployit uses to execute deployments.
For more information, see the Overthere project.
An importer is a class that turns a source into a collection of Deployit entities. Both the import source as well as the importer can be customized. Deployit comes with a default importer that understands the DAR package format (see the Packaging Manual for details).
Import sources are classes implementing the ImportSource interface and can be used to obtain a handle to the deployment package file to import. Import sources can also implement the ListableImporter interface, which indicates they can produce a list of possible files that can be imported. The user can make a selection out of these options to start the import process.
When the import source has been selected, all configured importers in Deployit are invoked in turn to see if any importer is capable of handling the selected import source (the canHandle method). The first importer that indicates it can handle the package is used to perform the import. Deployit's default importer is used as a fallback.
First, the preparePackage method is invoked. This instructs the importer to produce a PackageInfo instance describing the package metadata. This data is used by Deployit to determine whether the user requesting the import has sufficient rights to perform it. If so, the importer's importEntities method is invoked, allowing the importer to read the import source, create deployables from the package and return a complete ImportedPackage instance. Deployit will handle storing of the package and contents.
Writing a custom plugin is the most powerful way to extend Deployit. It uses Deployit's Java plugin API which is also used by all of the plugins provided by XebiaLabs. The plugin API specifies a contract between Deployit core and a plugin that ensures that a plugin can safely contribute, along with other plugins, to the calculated deployment plan. To understand the plugin API, it is helpful to learn about the Deployit system architecture and how the plugins are involved in performing a deployment. The following sections provide this background information and are followed an explanation of how to build your own plugin.
Deployit features a modular architecture that allows components to be changed and extended while maintaining a consistent system. The following diagram provides a high-level overview of the system architecture:
Deployit's central component is referred to as the core and contains the following functionality:
The Deployit core is accessed using a REST service. The product ships with two clients of the REST service, a graphical user interface (GUI) built in Flex that runs in browsers using Flash, and a command-line interface (CLI) that interprets Jython.
Support for various middleware platforms is provided in the form of Deployit plugins. Deployit plugins add capabilities to Deployit and may be delivered by XebiaLabs or custom-built by users of Deployit.
A Deployit plugin is a component that provides the Deployit server with a way to interact with a specific piece of middleware. It allows the Deployit core to remain independent of the middleware it connects with. At the same time, it allows plugin writers to extend Deployit in a way that seamlessly integrates with the rest of Deployit's functionality. Existing Deployit plugins can be extended to customize Deployit for your environment. It's even possible to write a new Deployit plugin from scratch.
To integrate with the Deployit core, the plugins adhere to a well-defined interface. This interface specifies the contract between the Deployit plugin and the Deployit core, making it clear what each can expect of the other. The Deployit core is the active party in this collaboration and invokes the plugin whenever needed. For its part, the Deployit plugin replies to requests it is sent. When the Deployit server starts it scans the classpath and loads each Deployit plugin it finds, readying it for interaction with the Deployit core. The Deployit core does not change loaded plugins or load any new plugins after it has started.
At runtime, multiple plugins will be active at the same time. It is up to the Deployit core to integrate the various plugins and ensure they work together to perform deployments. There is a well-defined process (described below) that invokes all plugins involved in a deployment and turn their contributions into one consistent deployment plan. The execution of the deployment plan is handled by the Deployit core.
Plugins can define the following items:
These concepts are captured in Java interfaces that can be used to write plugins. See the section on "Writing a plugin in Java" below. First we will describe the steps that are involved when doing a deployment in Deployit.
Performing a deployment in Deployit consists of a number of stages that, together, ensure that the deployment package is deployed and configured on the environment. Some of these activities are performed by the Deployit core, while others are performed by the plugins.
This is the list of stages:
The following diagram depicts the way in which a plugin is involved in a deployment:
The transitions that are covered by a puzzle-piece are the ones that interact with the plugins, whereas the deployit-logo indicates that the transition is handled by the Deployit core.
The following sections describe how plugins are involved in the above mentioned activities. To clarify the description, we will use the sample deployment package PetClinic 1.0, consisting of an EAR file, a datasource and static content, and deploy it to a WebSphere environment.
The plugin is involved in the Specification and Planning stages, these will be detailed below.
In the Specification stage, the deployment to be executed is specified. This includes selecting the deployment package and members to be deployed, as well as mapping each package member to the environment members that they should be deployed to.
The Deployit plugin defines which CIs the Deployit core can use to create deployments. When a plugin is loaded into the Deployit core, Deployit scans the plugin for CIs and adds these to its CI registry. Based on the CI information in the plugin, Deployit will categorize each CI as either a deployable CI (defining the what of the deployment) or a container CI (defining the where of the deployment).
Where the deployable CI represents the passive resource or artifact, the deployed CI represents the active version of the deployable CI when it has been deployed in a container. By defining deployed CIs, the plugin indicates which combinations of deployable and container are supported.
Each deployed CI represents a combination of a deployable CI and a container CI. It is important to note that one deployable CI can be deployed to multiple container CIs. For instance, an EAR file can be deployed to two application servers. In a deployment, this is modeled as multiple deployed CIs.
Sometimes it is desirable to configure a deployable CI differently depending on the container CI or environment it is deployed to. This can be done by configuring the properties of the deployed CI differently.
Configuring the deployed CIs is handled in the Deployit core. Users perform this task either via the GUI or via the CLI. A delpoyit plugin can influence this process by providing default values for its properties.
The result of the Specification stage is a deployment specification, containing deployed CIs that describe which deployable CIs are mapped to which container CIs with the needed configuration.
In the Planning stage, the deployment specification and its subplans that were created in the Orchestration stage are processed.
During this stage, the Deployit core performs the following procedure:
During each part of this procedure, the Deployit plugin is invoked so it can contribute (add) required deployment steps to the subplan.
Preprocessing allows the plugin to contribute steps to the very beginning of the plan. During preprocessing, all preprocessors defined in the plugin are invoked in turn. Each preprocessor has full access to the delta specification. As such, the preprocessor can contribute steps based on the entire deployment. Examples of such steps are sending an email before starting the deployment or performing pre-flight checks on CIs in that deployment.
Dployed CIs contain both the data and the behavior to make a deployment happen. Each of the deployed CIs that is part of the deployment can contribute steps to ensure that they are deployed or configured correctly.
Steps in a deployment plan must be specified in the correct order for the deployment to succeed. Furthermore, the order of these steps must be coordinated among an unknown number of plugins. To achieve this, Deployit weaves all the separate resulting steps from all the plugins together by looking at their specified ordering.
For example, suppose we have a container CI representing a WAS application server called WasServer. This CI contains the data describing a WAS server (things like host, application directory, etc.) as well as the behavior to manage it. During a deployment to this WasServer, the WasServer CI contributes steps with order 10 to stop the WasServer. Also, it would contribute steps with order 90 to restart it. In the same deployment, a deployable CI called WasEar (representing the WAS EAR file) contributes steps to install itself with order 40. The resulting plan would weave the install of the EAR file (40) in between the stop (10) and start (90) steps.
This mechanism allows steps (behavior) to be packaged together with the CIs that contribute them. Also, CIs defined by separate plugins can work together to produce a well-ordered plan.
Deployit uses the following default orders:
Postprocessing is similar to preprocessing, but allows a plugin to add one or more steps to the very end of a plan. A postprocessor could for instance add a step to send a mail once the deployment has been completed.
The Planning stage results in a deployment plan that contains all steps necessary to perform the deployment. The deployment plan is ready to be executed.
This concludes the involvement of the plugin in the deployment planning process.
In addition to extending Deployit plugins using the facilities described above, Deployit plugins can also be written in Java. The UDM concepts are represented in Java by interfaces:
In addition to these types, plugins also specify the behavior required to perform the deployment. That is, which actions (steps) are needed to ensure that a deployable ends up in the container as a deployed. In good OO-fashion, this behavior is part of the Deployed class.
Let's look at the mechanisms available to plugin writers in each of the two deployment phases, Specification and Planning.
All of the CIs in Deployit are part of a namespace to distinguish them from other, similarly named CIs. For instance, CIs that are part of the UDM plugin all use the udm namespace (such as udm.Deployable).
Plugins implemented in Java must specify their namespace in a source file called package-info.java. This file provides package-level annotations and is required to be in the same package as your CIs.
This is an example package-info file:
@Prefix("yak")
package com.xebialabs.deployit.plugin.test.yak.ci;
import com.xebialabs.deployit.plugin.api.annotation.Prefix;
This section describes Java classes used in defining CIs that are used in the Specification stage.
The udm.BaseConfigurationItem is the base class for all the standard CIs in Deployit. It provides the syntheticProperties map and a default implementation for the name of a CI.
The udm.BaseDeployable is the default base class for types that are deployable to udm.Container CIs. It does not add any additional behavior
The udm.BaseContainer is the default base class for types that can contain udm.Deployable CIs. It does not add any additional behavior
The udm.BaseDeployed is the default base class for types that specify which udm.Deployable CI can be deployed onto which udm.Container CI.
Next to these base types, the UDM defines a number of implementations with higher level concepts that facilitate deployments.
When creating a deployment, the deployables in the package are targeted to one or more containers. The deployable on the container is represented as a deployed. Deployeds are defined by the deployable CI type and container CI type they support. Registering a deployed CI in Deployit informs the system that the combination of the deployable and container is possible and how it is to be configured. Once such a CI exists, Deployit users can create them in the GUI by dragging the deployable to the container.
During planning a Deployment plugin can contribute steps to the deployment plan. Each of the mechanisms that can be used is described below
The @PrePlanProcessor and @PostPlanProcessor annotations can be specified on a method to define a pre- or postprocessor. The pre- or postprocessor takes an optional order attribute which defaults to '100'; lower order means it is earlier, higher order means it is later in the processor chain. The method should take a DeltaSpecification and return either a Step or List of Step, the name can be anything, so you can define multiple pre- and postprocessors in one class. See these examples:
@PrePlanProcessor
public Step preProcess(DeltaSpecification specification) { ... }
@PrePlanProcessor
public List<Step> foo(DeltaSpecification specification) { ... }
@PostPlanProcessor
public Step postProcess(DeltaSpecification specification) { ... }
@PostPlanProcessor
public List<Step> bar(DeltaSpecification specification) { ... }
As a pre- or postprocessor is instantiated when it is needed, it should have a default constructor. Any fields on the class are not set, so the annotated method should not rely on them being set.
Deployeds can contribute steps to a deployment in which it is present. The methods that are invoked should also be specified in the udm.Deployed CI. It should take a DeploymentPlanningContext, to which one or more Steps can be added with specific ordering. The return type of the method should be void.
The method is annotated with the operation that is currently being performed on the Deployed CI. The following operations are available:
@Create when deploying a member for the first time@Modify when upgrading a member@Destroy when undeploying a member@Noop when there is no changeIn the following example, the method createEar() is called for both a create and modify operation of the DeployedWasEar.
public class DeployedWasEar extends BaseDeployed<Ear, WasServer> {
...
@Create @Modify
public void createEar(DeploymentPlanningContext context) {
// do something with my field and add my steps to the result
// for a particular order
context.addStep(40, new CreateEarStep(this));
}
}
A @Contributor contributes steps for the set of Deltas in the current subplan being evaluated. The methods annotated with @Contributor can be present on any Java class which has a default constructor. The generated steps should be added to the collector argument context.
@Contributor
public void contribute(Deltas deltas, DeploymentPlanningContext context) { ... }
CIs programmed in Java can also define control tasks. Control tasks allow actions to be executed on CIs and can be invoked from the GUI or the CLI. Control tasks are implemented in Java as methods annotated with the @ControlTask annotation. The method returns a List
@ControlTask(description = "Start the Apache webserver")
public List<Step> start() {
// Should include actual steps here
return newArrayList();
}
A CI representing an Apache webserver could define the above method to start the webserver when invoked.
Next to defining CIs, new validation rules can also be defined in Java. These can then be used to annotate CIs or their properties so that Deployit can perform validations.
A simple property validation rule would look like:
import com.xebialabs.deployit.plugin.api.validation.Rule;
import com.xebialabs.deployit.plugin.api.validation.ValidationContext;
import java.lang.annotation.ElementType;
import java.lang.annotation.Retention;
import java.lang.annotation.RetentionPolicy;
import java.lang.annotation.Target;
@Retention(RetentionPolicy.RUNTIME)
@Rule(clazz = StaticContent.Validator.class, type = "static-content")
@Target(ElementType.FIELD)
public @interface StaticContent {
String content();
public static class Validator
implements com.xebialabs.deployit.plugin.api.validation.Validator<String> {
private String content;
@Override
public void validate(String value, ValidationContext context) {
if (value != null && !value.equals(content)) {
context.error("Value should be %s but was %s", content, value);
}
}
}
}
A validation rule consists of an annotation @StaticContent, which is associated with an implementation of com.xebialabs.deployit.plugin.api.validation.Validator<T>. They are associated using the @com.xebialabs.deployit.plugin.api.validation.Rule annotation. Each method of the annotation needs to be present in the validator as a property with the same name.
When you've defined this validation rule, you can use it to annotate a CI like such:
public class MyLinuxHost extends BaseContainer {
@Property
@StaticContent(content = "/tmp")
private String temporaryDirectory;
}
Or you can use it in synthetic XML in the following way:
<type name="ext.MyLinuxHost" extends="udm.BaseContainer">
<property name="temporaryDirectory">
<rule type="static-content" content="/tmp"/>
</property>
</type>
Plugins are distributed as standard Java archives (JAR files). Plugin JARs are put in the Deployit server plugins directory, which is added to the Deployit server classpath when it boots. Deployit will scan its classpath for plugin CIs and plugpoint classes and load these into its registry. These classes must be in the com.xebialabs or ext.deployit packages. The CIs are used and invoked during a deployment when appropriate.
Synthetic extension files packaged in the JAR file will be found and read. If there are multiple extension files present, they will be combined and the changes from all files will be combined.
This is the schema of the synthetic.xml file used to contribute types and type changes to Deployit.
<?xml version="1.0"?>
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns="http://www.xebialabs.com/deployit/synthetic"
targetNamespace="http://www.xebialabs.com/deployit/synthetic"
elementFormDefault="qualified">
<xs:element name="synthetic">
<xs:complexType>
<xs:choice maxOccurs="unbounded">
<xs:element name="type" type="SyntheticTypeDefinition"/>
<xs:element name="type-modification" type="SyntheticTypeModification"/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:complexType name="SyntheticTypeDefinition">
<xs:sequence>
<xs:element name="generate-deployable" type="SyntheticDeployableGeneration" minOccurs="0" maxOccurs="1"/>
<xs:element name="property" type="SyntheticPropertyDefinition" minOccurs="0" maxOccurs="unbounded"/>
<xs:element name="method" type="SyntheticMethodDefinition" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="rule" type="SyntheticValidationRule" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" type="DeployitTypeName" use="required"/>
<xs:attribute name="extends" type="DeployitTypeName" use="required"/>
<xs:attribute name="description" type="xs:string"/>
<xs:attribute name="virtual" type="xs:boolean"/>
<xs:attribute name="deployable-type" type="DeployitTypeName"/>
<xs:attribute name="container-type" type="DeployitTypeName"/>
</xs:complexType>
<xs:complexType name="SyntheticDeployableGeneration">
<xs:attribute name="type" type="DeployitTypeName" use="required"/>
<xs:attribute name="extends" type="DeployitTypeName" use="required"/>
<xs:attribute name="description" type="xs:string"/>
</xs:complexType>
<xs:complexType name="SyntheticTypeModification">
<xs:sequence minOccurs="0" maxOccurs="unbounded">
<xs:element name="property" type="SyntheticPropertyDefinition" minOccurs="1" maxOccurs="unbounded"/>
<xs:element name="method" type="SyntheticMethodDefinition" minOccurs="0" maxOccurs="unbounded" />
<xs:element name="rule" type="SyntheticValidationRule" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="type" type="DeployitTypeName" use="required"/>
</xs:complexType>
<xs:complexType name="SyntheticPropertyDefinition">
<xs:sequence>
<xs:element name="rule" type="SyntheticValidationRule" minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:attribute name="name" type="JavaPropertyName" use="required"/>
<xs:attribute name="kind" type="KindType"/>
<xs:attribute name="description" type="xs:string"/>
<xs:attribute name="category" type="xs:string"/>
<xs:attribute name="label" type="xs:string"/>
<xs:attribute name="required" type="xs:boolean"/>
<xs:attribute name="password" type="xs:boolean"/>
<xs:attribute name="size" type="SizeType"/>
<xs:attribute name="default" type="xs:string"/>
<xs:attribute name="enum-class" type="xs:string"/>
<xs:attribute name="referenced-type" type="DeployitTypeName"/>
<xs:attribute name="as-containment" type="xs:boolean"/>
<xs:attribute name="hidden" type="xs:boolean"/>
<xs:attribute name="transient" type="xs:boolean"/>
</xs:complexType>
<xs:complexType name="SyntheticMethodDefinition">
<xs:attribute name="name" type="JavaPropertyName" use="required" />
<xs:attribute name="description" type="xs:string" />
</xs:complexType>
<xs:complexType name="SyntheticValidationRule">
<xs:attribute name="type" type="xs:string" default="regex" />
<xs:anyAttribute processContents="lax"/>
</xs:complexType>
<xs:simpleType name="JavaPropertyName">
<xs:restriction base="xs:string">
<xs:pattern value="[a-zA-Z0-9_]*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="DeployitTypeName">
<xs:restriction base="xs:string">
<xs:pattern value="[a-zA-Z0-9-]*\.[a-zA-Z0-9-]*"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="KindType">
<xs:restriction base="xs:string">
<xs:enumeration value="enum"/>
<xs:enumeration value="boolean"/>
<xs:enumeration value="integer"/>
<xs:enumeration value="string"/>
<xs:enumeration value="ci"/>
<xs:enumeration value="set_of_ci"/>
<xs:enumeration value="set_of_string"/>
<xs:enumeration value="map_string_string" />
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="SizeType">
<xs:restriction base="xs:string">
<xs:enumeration value="default"/>
<xs:enumeration value="small"/>
<xs:enumeration value="medium"/>
<xs:enumeration value="large"/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
This example describes some classes from a test plugin we use at XebiaLabs, the Yak plugin.
We'll use the following sample deployment in this example
The YakFile is a deployable CI representing a file. It extends the built-in BaseDeployableFileArtifact class.
package com.xebialabs.deployit.plugin.test.yak.ci;
import com.xebialabs.deployit.plugin.api.udm.BaseDeployableFileArtifact;
public class YakFile extends BaseDeployableFileArtifact {
}
In our sample deployment, both yakfile1 and yakfile2 are instances of this Java class.
The YakServer is the container that will be the target of our deployment.
package com.xebialabs.deployit.plugin.test.yak.ci;
// imports omitted...
@Metadata(root = Metadata.ConfigurationItemRoot.INFRASTRUCTURE)
public class YakServer extends BaseContainer {
@Contributor
public void restartYakServers(Deltas deltas, DeploymentPlanningContext result) {
for (YakServer yakServer : serversRequiringRestart(deltas.getDeltas())) {
result.addStep(new StopYakServerStep(yakServer));
result.addStep(new StartYakServerStep(yakServer));
}
}
private static Set<YakServer> serversRequiringRestart(List<Delta> operations) {
Set<YakServer> servers = new TreeSet<YakServer>();
for (Delta operation : operations) {
if (operation.getDeployed() instanceof RestartRequiringDeployedYakFile && operation.getDeployed().getContainer() instanceof YakServer) {
servers.add((YakServer) operation.getDeployed().getContainer());
}
}
return servers;
}
}
This class shows several interesting features:
restartYakServers() method annotated with @Contributor is invoked when any deployment takes place (also deployments that may not necessarily contain an instance of the YakServer class). The method serversRequiringRestart() searches for any YakServer instances that are present in the deployment and that requires a restart. For each of these YakServer instances, a StartYakServerStep and StopYakServerStep is added to the plan.When the restartYakServers method is invoked, the deltas parameter contains operations for both yakfile CIs. If either of the yakfile CIs was an instance of RestartRequiringDeployedYakFile, a start step would be added to the deployment plan.
The DeployedYakFile represents a YakFile deployed to a YakServer, as reflected in the class definition. The class extends the built-in BaseDeployed class.
package com.xebialabs.deployit.plugin.test.yak.ci;
// imports omitted...
public class DeployedYakFile extends BaseDeployed<YakFile, YakServer> {
@Modify @Destroy
public void stop(DeploymentPlanningResult result) {
result.addStep(10, new StopDeployedYakFileStep(this));
}
@Create @Modify
public void start(DeploymentPlanningResult result) {
logger.info("Adding start artifact");
result.addStep(90, new StartDeployedYakFileStep(this));
}
@Create
public void deploy(DeploymentPlanningResult result) {
logger.info("Adding step");
result.addStep(70, new DeployYakFileToServerStep(this));
}
@Modify
public void upgrade(DeploymentPlanningResult result) {
logger.info("Adding upgrade step");
result.addStep(70, new UpgradeYakFileOnServerStep(this));
}
@Destroy
public void destroy(DeploymentPlanningResult result) {
logger.info("Adding undeploy step");
result.addStep(30, new DeleteYakFileFromServerStep(this));
}
private static final Logger logger = LoggerFactory.getLogger(DeployedYakFile.class);
}
This class shows how to use the @Contributor to contribute steps to a deployment that includes a configured instance of the DeployedYakFile. Each annotated method annotated is invoked when the specified operation is present in the deployment for the YakFile.
In our sample deployment, yakfile1 already exists on the target container CI so a MODIFY delta will be present in the delta specification for this CI, causing the stop, start and upgrade methods to be invoked on the CI instance. Because yakfile2 is new, a CREATE delta will be present, causing the start, and deploy method to be invoked on the CI instance.
Steps are the actions that will be executed when the deployment plan is started.
package com.xebialabs.deployit.plugin.test.yak.step;
// imports omitted...
public class StartYakServerStep implements Step {
private YakServer server;
public StartYakServerStep(YakServer server) {
this.server = server;
}
@Override
public String getDescription() {
return "Starting " + server;
}
@Override
public Result execute(StepExecutionContext ctx) throws Exception {
return Step.Result.Success;
}
public YakServer getServer() {
return server;
}
}