Our story so far: Island Training took on a challenge to create an interesting and engaging live demo of an end-to-end DevOps process. We set a 10-minute limit for the full demo cycle, from requirement to deployed personalized tickets. In Part 1, we took advantage of links between DOORS Next Generation (DNG) and Rational Team Concert (RTC) to create work items from requirements. In Part 2, we used the REST API to generate our deliverable text file.
In this chapter, we’ll explain how UrbanCode Deploy played a key role in meeting the 10-minute demo deadline.
UrbanCode Deploy (uDeploy) is a deployment automation tool. It takes build results and configuration details from RTC build management functionality or other continuous integration tools like Jenkins, and applies those build results into a number of environments.
If you have no experience with uDeploy, the following definitions provide the background you’ll need to follow this blog:
- Components represent deployable artifacts: files, images, databases, configuration materials, or anything else associated with a software project. Components have versions which ensure that proper component instances are deployed.
- Component processes operate on components, usually by deploying them. Each component must have at least one component process defined for it.
- An application brings together all deployment components by identifying its components and defining a process to move them through a target environment (by running component processes, for instance).
- An environment is a collection of resources that represent deployment targets—physical machines, virtual machines, databases, J2EE containers, and so on. Each application must have at least one environment defined for it.
- Agents are distributed processes that communicate with the uDeploy server and perform the actual work of deploying artifacts. Generally, an agent is installed on the host where the resources it manages reside. Agents are associated with applications at the environment level.
To understand how we use uDeploy for automation in our 10-minute demo, we’ll take a look at each of the following:
- What to deploy
- Where to deploy
- How to deploy
- When to deploy
What We Deploy
We start with a text file from our RTC repository, copy that file in several locations, copy its contents to a web page, and display that web page. We use a single application in uDeploy. Because our simple application consists of a single file, we create a single component called Tiki inside that application.
Where We Deploy
The development of our demo is no different from developing any application. We set up a “proof of concept” environment on a single Linux machine. This Linux machine serves our CLM applications (DNG, RTC) as well as uDeploy.
To make sure that the demo behaves properly, we create an environment called Test in uDeploy. Our Test environment contains the resource to which our component deploys. This resource subsequently maps to an agent that connects the logical resource to a physical or virtual machine. For our Test environment, we set up the agent on our Linux machine, so it effectively acts as the server as well as the client for uDeploy deployment. The screen shot below shows the mapping from resource to agent to component.
Once we are satisfied with the proof of concept environment, we install a client on a Windows virtual machine. Creating a second environment is a breeze. We install the agent software on the Windows VM and convert the deploy steps from Linux commands and conventions to Windows-style commands and conventions. (More on that in the next section.)
The screenshot below shows our application with two environments, our initial Linux-based Test environment and the Demo environment we would use at InterConnect. You can see that different components are associated with each environment.
How We Deploy
In describing our application and its components, we outline how a deployment happens by setting up the process for a component as well as the overall process for an application. We keep the installation process for the overall application generic; all it has to do is install the applicable component by calling its applicable installation process.
This leaves the bulk of the deployment work to the component process, which is responsible for several steps:
- Receiving the download that comes from the RTC build process.
- Copying that file so that the website and the machine attached to the ticket printer each receive the file.
- Applying the contents of the file to our web page.
- Displaying the updated web page.
We implement each of these steps as a separate process step, which allows easy debugging of the overall component process. We use the graphical editor to create our component process. Creating the process involves dragging the necessary process steps from the Step Palette and connecting the steps in the order desired by drawing arrows from one step to the next. If a step involves commands, opening up the process step lets you to set those commands and necessary parameters. Are you deploying your component to a specialized server such as WebSphere Application Server? You can download and apply plugins to make the deployment process easier. Below is a view of the component process in the graphical editor.
When We Deploy
To demonstrate the automatic interaction between RTC and uDeploy, we make the deployment of our file the last step of the RTC build process. This allows RTC to invoke the deployment upon successful completion of the build.
To set up the post-build deploy in the RTC build process, we need the following information:
- uDeploy server information (server URL)
- uDeploy credentials (User ID, password)
- Application to deploy including process and environment
- Component the build result is changing, including new version and where to place the build result.
Once all the pieces are in place, every time we request a build, RTC calls uDeploy to place the results in an updated component version, and calls the application process to install the new component. uDeploy records the results of the deployment and shows the success or failure in logs. The logging is quite detailed, allowing you to go to an individual deployment attempt, see which component process step failed, and improve the component process. An example showing the history of component deployment follows:
What we learned from developing and running our 10-minute demonstration can be applied to developing “real” products. We found power in using automation present in DNG, RTC, and uDeploy, which allowed us not only to save time, but also to make sure the demo performance was consistent each time we presented. Automation also eliminated any introduction of human error and rework. If leveraging automation makes a difference in producing a 10-minute demo, imagine the time and work that you can save when developing production applications.