Articles

3 Reasons to Add Asset Tracking to Your CI/CD Pipeline

If you’ve gotten your CI/CD implementation to a good place, you may be introducing over 100 new releases every day. This is great from a productivity standpoint, but not so much from an organizational standpoint. When your applications are updating faster than your records, how do you keep track of what you need? Here are three reasons to add asset tracking to your CI/CD pipeline.

1. Because Spreadsheets are Not Your Friend

You probably already know that spreadsheets aren’t a good source of information when it comes to software development. Almost 90% of enterprise spreadsheets contain errors – and really, when you’re dealing with a complex automated production pipeline, even a 10% error rate would probably be disqualifying.

Spreadsheets accumulate errors for many reasons. First, there’s no good way to perform version control except by mass-emailing the latest update. If someone sends an out-of-date version by accident, then the entire department could find themselves working off obsolete information. In addition, someone could change a file or an application without changing the spreadsheet, making its information worthless.

Why do people keep using spreadsheets for asset tracking if they’re so sub-par? Generally, it’s because they already have an Excel software license and they don’t want to shell out for a dedicated asset tracking solution. Although you might consider automated asset tracking expensive, we’re here to tell you that you can’t afford not to use it.

2. Because You Have Too Many Applications

So, you’ve decided that your spreadsheets are out of date and can’t be trusted. What’s next? Maybe you could try querying your applications directly and getting updated information from them that way.
Stop and ask yourself a few questions. First, how many applications are in your CI/CD pipeline? Next, pick an application at random. Do you know how to get the information you need from it without using Google? If you know without using Google, do you know how long it takes to get the information you need? Can you get information from your application directly, or do you need to open an external tool and run a report?

Our point is that you have many applications to monitor, and that there’s no standardized way for you to get information from any of them. What’s worse, many of these applications have confusing interfaces, or are black boxes unless you run an external report. In other words, getting the information you need may take too long.

3. Because Documentation Takes Too Much Time

The CI/CD pipeline depends on speed. If you insist that your developers document their changes after every release, you’re going to have a rebellion on your hands, because this will force them to alter their workflow and slow down the pace of releases. Adding a manual process to the CI/CD pipeline is also anathema to the CI/CD philosophy. Instead, you nee to adopt an automated solution to a problem that’s also created by automation.

How Do You Automate Record Keeping for Your CI/CD Pipeline

One of the easiest ways to automate record keeping for your CI/CD Pipeline is to create an integration with Device42.

Our solution is designed to mesh with major tools in the CI/CD application stack – via REST API or using a built-in integration – to create a living database of your environment information. Every time your environment changes, Device42 monitors and records the change, placing the necessary information at your fingertips:

  • Jenkins
    Device42 integrates with Jenkins using a RESTful API. Every time a new package is deployed to your repository, Jenkins can use Device42 to create a software object with versioning and a note specifying the URI.
  • Terraform
    The Terraform remote-exec provisioner can use the Device42 API to set static IPs. With the addition of Curl, Terraform can reserve IPs in advance so they can’t be grabbed before provisioning is complete.
  • Chef
    Device42 is available as a Chef cookbook and can be found in the Chef supermarket or on Github. It can be added to the run_list of all Chef convergences in your environment. Device42 ingests data from Ohai and uses it to update its library of device types. You can also use the IPAM features in Device42 to help Chef assign IP addresses during configuration.

By placing an app like Device42 midstream in the CI/CD process, you can dramatically improve your ability to be aware of your environment – without relying on spreadsheets, and without slowing down the pace of releases. For more information about how easy it is to use Device42, download our free demo today!

Share this post

About the author