How Inventory and Compliancy work together in IBM DevOps Deploy

Overview

One of the most beloved features of IBM DevOps Deploy is the way it can track inventory of what component versions are deployed to each of your target environments for a given application.   This product was one of the first on the market to do a really good job of providing users with visibility of versions that had been deployed to each environment.

Prior to a product like IBM DevOps Deploy, people would have to track inventory manually in spreadsheets or come up with their own homegrown solution to do this type of tracking.    What happens if a deployment fails?    This is where compliancy comes in to the picture to help you understand if the intended version that was deployed is compliant with what we would expect in the environment.

The purpose of this document is to try and document how inventory works in IBM DevOps Deploy along with the concept of compliancy that is used by the product.

The Fundamentals: Codestation

To understand inventory in DevOps Deploy, you must first understand the built-in version repository that comes with the product called Codestation.   Codestation is the name of the service that manages and stores artifacts.   Deploy Agents invoke it when downloading component versions.    Codestation provides a secure and tamper-proof artifact repository which helps to ensure that deployed components are identical to those tested in pre-production environments.   Without a repository like Codestation, artifacts would have to be pulled from network shares or some other system, increasing both security risks and the potential for error.

As new artifacts are added to Codestation, they typically are given a version label that corresponds to the build tag of your build system for traceability.    The best practice is to have your build system “push” the new component version to DevOps Deploy so that this new immutable artifact can then be deployed to your target environments.    Here is an example of a Jenkins pipeline that builds a broker archive (.bar) and then pushes it as a new component version in Deploy:

Notice the build tag of ‘3.0.126’.   In DevOps Deploy, we can now see this new component version as shown below:

If you were to drill into this version by clicking on the version label, you can see the deployable artifacts that were packaged with this new component version.   In this case, we have a broker archive (BAR) which is the immutable deployable artifact as shown below:

This version is stored in the Codestation repository and is on the filesystem of the DevOps Deploy Server.   It cannot be tampered with or modified in any way.  

If you have multiple component versions that you are deploying, you can create a snapshot of those versions so that you know what you have tested together will be promoted together to the next target environment.

This diagram helps to describe what we have covered so far:

NOTE: The best practice is to setup a 'build once, deploy many' approach so you are not having to perform separate builds for the DEV, QA, and PROD environments.

The Fundamentals: Environments and the Resource Tree

The next fundamental topics that must be discussed are the concepts of:

•         Environments
•          Resource Model or Resource Tree

Environments

An application that is deployed goes through a software development lifecycle (SDLC) that usually starts with a DEV environment, then can be promoted to QA, and then promoted to UAT, and then ultimately promoted to PROD.   This lifecycle varies for each client, but it will look similar to what is shown below:

In order to deploy your application components to each environment, you typically install a Deploy Agent on a host in that environment.   The Deploy Agent can run on a mainframe LPAR, a Linux host, or a Windows server as examples.

You might ask, how do you map your components to the Deploy Agent?   To do this, you leverage the Resource Tree in IBM DevOps Deploy.   The environments shown above are linked to the Resource Tree.  

Resource Tree (or Resource Model)

The resource tree (or sometimes referred to as the resource model) offers an Ops-centric view of resources and can show the full stack.   Every logical deployment target is organized into a single tree.   The resource tree allows you to use inheritance for properties and security.

Here is an example of a resource tree for the PizzaApp example application shown above:

Notice that we added a folder for the target environments (DEV, QA, and PROD).   Under each target environment folder, you add the agent which is running in that environment.   Finally, if you want to deploy your component to that resource, you map the component under the agent as shown above.  

Once the resource model is configured, you can then link your application environment to the appropriate node in the resource tree.   Here is an example for my DEV environment where I clicked the ‘Add Base Resources’ button as shown below and then added the linkage to the DEV environment specified in the Resource Tree:

The following diagram helps to summarize 'The Where' we have covered in this section:

How Inventory is Tracked with Compliancy

The inventory for an environment lists the component versions that are intended to be deployed to that environment.   Compliance shows whether the environment contains those component versions or not.   The following diagrams help to depict this process.  

Prior to your first deployment to a fresh target environment, your inventory will be empty as well as your compliancy:

When you initiate a deployment to the target environment, the inventory is updated to the desired inventory you selected.   In this case, we selected version 1.0 of both the WEB component and the DB component:

When the deployment completes, the compliancy information is updated based on success or failure of the deployment.    What happens if a deployment fails?   See the screen below for an example:

Compliance shows whether the environment contains those component versions.   In this case, we are missing a component on one of the WEB hosts.

Here is an example for the PizzaApp I showed you earlier:

Notice the compliance highlighted above (1/1).   Since the deployment was successful, it reflects a green dot.  

If the deployment was unsuccessful, you would see a red dot and a compiancy of 0/1.   Here is an example of what it looks like on a failed deployment:

On a failed deployment, the resource tree inventory is not updated for the component you tried to deploy.   Here is the example for the failure above with our PBW-EAR component:

In the case of a failure, you can retry the deployment.   By default, DevOps Deploy will review inventory of your target environment prior to the deployment.   By default, if a target is already compliant with the version selected, it will not re-deploy that same version.

NOTE: you can override this behavior if you like to deploy the same version again.

In this case, we only deploy version 1.0 of the WEB component to the jpetstore.w2.prod host.   If the deployment is successful on the next attempt, compliancy will be updated to reflect 2/2 for the WEB component as shown below:

In this example, I retry the deployment to my QA environment for PlantsByWebSphere and this time the deployment is successful:

When the deployment completes, IBM DevOps Deploy will then update inventory in your resource tree as well.  In our example above, the inventory in the resource tree which looks like this:

In the next section, we will explain what drives the out of box inventory and compliance features described above.  By default, the server will manage the environment inventory and compliance for you automatically as described above.  

What Drives the Out-of-box Inventory and Compliance

The application process that you create is what will drive the out-of-box inventory and compliance features of the DevOps Deploy product.   The following steps are specifically what initiate the update to inventory and compliance as described above:

•         Install Component
•        Uninstall Component

Here is an example of an ‘Install Component’ step added to an application process.   This is what will cause inventory and compliance to be updated when the process is run:

If you edit this step by clicking the pencil icon, this is what the step looks like:

Here is an example of an ‘Uninstall Component’ step:

The properties for the ‘Uninstall Component’ process step looks like this:

In our final section, we will cover a technique for finding missing inventory versions should a failure occur in a install or uninstall deployment request.

How to Find Missing Inventory Versions

The following steps describe how one can find the compliant and non-compliant component versions in an environment:

1.        In IBM DevOps Deploy, navigate to the application you are interested in reviewing compliancy details.

2.        Expand the target environment to view the component(s) inventory details.

3.        To the right of the component, click the layer cake icon (three dots) pull down menu and select the ‘View Deployment Request’ option as shown below:

4.        Scroll to the bottom of the page and you can find the non-compliant resources as shown below:

5.        You can expand the non-compliant resource component to get a list of the versions that are missing as shown below:

This is helpful in triage of issues to better understand what versions are missing so you can remediate it on a subsequent deployment.

Summary

IBM DevOps Deploy has built in inventory and compliance features that you can leverage in your CI/CD pipelines which brings a lot of value to our clients.    The ability to see which versions are deployed across all of your environments is valuable as shown below:

The inventory and compliance for an environment are updated each time that you run an application process or deploy a snapshot to the environment.   If there is a compliance issue, you can quickly diagnose and remediate.

When you combine these great features with component statuses, gates, and other governance features, IBM DevOps Deploy is a top performer and solution in the application release automation space.

In a future blog, we will cover more advanced inventory concepts for other use cases like a rollback from a mainframe deployment perspective.   Many thanks to our loyal customers across the globe using IBM DevOps Deploy and I hope you found this blog informative.