The management of artifacts using a separate repository managers such as Artifactory, Nexus, or TFS, is generally an accepted practice. These repositories provide a clean, safe, and redundant location to store your deployment files. However, some important services, such as IBM DataPower, InfoSphere DataStage, Business Process Manager (BPM), do not always play nicely with typical source control. As a result, this can make it hard to import artifacts into IBM UrbanCode Deploy.

In my experience, I have seen clients generate complex scripts to migrate artifacts into IBM UrbanCode Deploy. Unknown to them, IBM UrbanCode Deploy can also retrieve these artifacts through a design process they already understand. No scripting required. With IBM UrbanCode Deploy, one can skip third-party source control and save artifacts directly to IBM UrbanCode Deploy’s CodeStation. Then, the deployment request is triggered following a successful import. All of which can occur automatically or with the push of a button.

This documentation focuses on how to import artifacts without a build or continuous integration tool. While the outlined strategy is explained in the context of IBM DataPower, its overall process can be applied to any tool with a similar use case. Our suggested approach will not require any major restructuring of a predefined deployment process. If you already have a deployment process defined, then you are already fifty percent of the way there. This guide will walk you through setting up a repeatable import process that will then initiate the previously defined deployment process.

The basic import and deploy process outlined below will be as follows:

1. Retrieve the artifacts from the server. (e.g. IBM DataPower’s export.zip)
2. Create a new Component Version based on the downloaded artifacts.
3. Deploy the artifacts using a previously created Application Process.

Import Artifacts

The suggested component process below outlines the initial process of retrieving the artifacts and importing them into IBM UrbanCode Deploy’s CodeStation.

1. Delete Files and Directories: Similar to other processes that use artifacts, we want to clean the working directory. This way, during the Create Version step, we do not accidentally add invalid or old files.
2. Export Artifact from Server: This step will download artifacts from the IBM DataPower server. I am using Export Object step as its retrieved artifacts match the required artifacts for the Basic Import process I use in my previous blog. These exported objects must match the expected artifacts for your following deployment process. If using IBM InfoSphere DataStage, substitute this step for the Export ISX Project or Export DSX Project steps. If using IBM BPM, substitute this step for the Create Generic Install Package or Generate Offline Package.
3. Generate Version Name: In this example, I generate a timestamp and use it as the version name for the DataPower artifacts. In other use cases, this step could be removed and the version name is instead a required runtime property.
4. Create Version and Add Files: The Create Version step will take the downloaded artifacts and create a new component version. After this step, the artifacts are in CodeStation. Notice the version name is resolved from the previous Generate Version Name step’s output properties.
5. Run Deploy Application Process: Lastly, the Run Application Process step will initiate the second application process. In my configuration, it will start the Deploy Basic application process which deploys the artifacts into my development DataPower instance. This is where you would specify your specific deployment’s application process. This final step is slightly misleading as it initiates and waits for the second application process to complete.

Component Process Configuration

Not shown in this configuration is the Process Type of the component process. In a typical component process, the version must be specified. Our strategy however, creates the version at runtime. Therefore, in the component processes Configuration tab, set the Process Type to Operational (No Version Needed). You will see this take affect at deployment time. When you configure the deployment process request, you will see that IBM UrbanCode Deploy does not prompt you for a version.

Application Process

The application process is a simple one step configuration containing the Run Operational Process for Multiple Components step. This step will allow you to run an Operational (No Version Needed) process request. As a caveat however, you must tag your component. Once configured, all of the application’s components will run that possess the specified tag and component process.

Deploy Artifacts

What I have outlined above covers the process importing the artifacts and then initiating the deployment application request. I did not show how the artifacts are actually deployed. I have chosen to forgo this process as the configuration of a complete deployment process is out of scope for this blog. Fortunately, there is plenty of documentation elsewhere in the context of Hello World and IBM DataPower. However, recognize that any previously defined application process can run following the creation of a component version. Simply update the above component process’s Run Application Process step with your specific deployment process.

The described integration strategy is an Import first, Deploy second application process. However, should not be a limitation. The same deploy process can still run separately from the Create Component Version component process. Just like any other process, navigate to the application’s environments page, select the environment you wish to deploy to, and specify the application process and versions. Comparatively, the application process and version assignment is done automatically. The strategy defined here is perfect for simultaneously recording artifacts and deploying them into a development environment with a single click or setting a weekly backup process.

Results

Here you can see the application process after completion:

The last step, Run Deploy Application Process, will wait for a completion response from the secondary deployment process. Find the secondary execution results (not shown here) by navigating to the application’s history tab and view the running deployments. In my logs, we can see the deployment process took approximately one and a half minutes.

This is one approach of handling artifacts directly from the tool’s server to IBM UrbanCode Deploy. While source control repositories are common, this strategy proves they are not required for your successful deployments. Feel free to post any questions below.