Five Things to Log in Your CI Pipeline: Continuous Delivery

Logs in continuous delivery pipelines are often entirely ignored, right up until something goes wrong. We usually find ourselves wishing we’d put some thought into our logs, once we’re in the midst of trawling through thousands of lines. In order to try to prevent this, we can add DevOps metrics into our logs, which will provide us with greater CI/CD observability, and give insight into anything going wrong in our pipelines. To help you add in these metrics to improve your CI/CD logs, here are five helpful tips.

1. Application Info

Some simple, yet vital, information to output is basic application metadata. This might include the application name, current version number(s), and any other important app-specific information you think may help out during later debugging. This metadata is important for more than just adding observability, it also provides context to the logs in case you might need to remove them from their original platform.

2. Code Commit Time

It is best to know when any changes were committed to the repository. Git makes this easy for us. Simply fetch the date of the latest commit:

git --no-pager log -1 --format=%cd

We can also add a specific commit hash or tag name to this command. Below, we fetch the latest tag in the repository through a subcommand:

git --no-pager log -1 --format=%cd $(git describe --exact-match --abbrev=0)

This will give us something like Fri Jun 12 12:48:02 2020 +0100, allowing us to work out how long it’s been from code commit or release creation to either the current time or one of the other values we’ll output below.

3. Build Times

Tracking the time from build start to end might not seem like it would be something too useful, especially if your continuous delivery pipeline already tracks total durations; however, this information can be very helpful when you’re troubleshooting a spike in total duration as you can quickly identify which section of your pipeline caused the increase.

You may also choose to be a little more specific and not only log out total build durations, but also durations for each step – this will allow you to identify which steps are causing spikes or the largest delays in your process. The time command on UNIX systems makes this easy.

4. Deploy Times

Deployment can face delays from time to time, and we need to be able to quickly identify any such issue. On top of this, a delay in a CDN deployment may be out of our control. We need to understand when we should and shouldn’t act. Logging each step of a deployment can very quickly alleviate these troubles, and just as with build timings, this can be done trivially with the time command.

5. Inconsistencies

If anything “out of the ordinary” is to happen during build or deploy, we’re going to want to know about it when we scan through our deployment logs. To make sure of this, when planning our CI/CD steps, we want to be careful not to accidentally hide warnings or errors outputted by any of our commands, and we want to make sure these are all directly outputted or redirected somewhere so that we can output them later on.

One good example of inconsistency might be a build whose duration deviates too far from the average. This can be a clear sign of something going wrong. Otherwise, inconsistencies may be things such as warnings from a compiler or linter that won’t stop the build. We should observe them to make sure they’re resolved at some point. Coralogix supports this feature out of the box, using our error anomaly and flow anomaly detection.

Your Continuous Delivery Pipeline is Crucial

Your pipeline is a constant font of new and important information. Each new release is a potential market-changing innovation, or a reputation tarring outage. These insights will give you a far better understanding of which change is which.