Before continuous integration came to be, setting up builds was no fun because the complexity and overhead involved in a release cycle was compounded by inflexible, manual processes. The release cycle was slow and often resulted in breaking changes. Continuous integration and continuous delivery (CI/CD) has changed much of that through pipelines that automate how we build and test software—today, we can deploy, have builds fail, and resolve any errors faster than ever.
However, while CI/CD helps us deploy faster, it’s not enough. We need to understand what happens in production when we deploy code so we can quickly find the source of errors and/or optimize our builds. CircleCI’s Senior Solutions Engineer Ryan Pederson joins Honeycomb Principal Developer Advocate Liz Fong-Jones to show how you can bring observability into your CI/CD pipelines with Honeycomb so you can monitor and observe the health and performance of your builds at any time.
Use Honeycomb for observability in your CI/CD deploys
Having observability in your CI/CD deploys means knowing the state of your builds at any point in time. This is super helpful for debugging build errors or troubleshooting builds that take longer than normal.
With the Honeycomb buildevents orb, you can automatically send your build events from CircleCI into Honeycomb so you can visualize them the same way you do your application telemetry data. But Honeycomb helps you do much more.
In the webinar, Liz demonstrated how to use Honeycomb to incorporate observability into your builds using one of our pipelines that run at every code push. By using Honeycomb to further explore builds, she could immediately see how long they took. She found a majority of the builds took less than 15 minutes—except for a particular cluster, on which she ran BubbleUp on to find out some of the properties about it.
By zooming in on the results, Liz could see all the individual steps within the jobs up to the commands in each. According to her, “By being able to visualize this as a trace rather than just as a list of steps or a list of jobs, this really helps us get a good understanding of where a build is slow and how to optimize it.”
Liz also demonstrated how you can compare properties of a build to the same build that ran days or weeks before by setting attributes on your trace. For example, in her demo, Liz wanted to find out the rate of increase of our tarball size. So, with Honeycomb, she was able to view the heatmap of a variable created called asset_size_bytes on the ARM64 architecture and look at the changes over a week. She could see when the tarball size increased, giving her an idea as to what caused the increase.
“Being able to plot any parameter that you can extract from your build and to be able to visualize it inside of the Honeycomb UI is super powerful,” she explained. “Anything that you can run a shell command inside of your workspace to do can be extracted and put as context on your event.”
As Liz and Ryan demonstrated, you can learn a great deal about your build workflows by integrating CircleCI with Honeycomb. Because you can view your builds as a trace instead of a list of jobs, you’re able to visualize every step of a build, understand where a build ran slowly, and determine the reason for it.
Gain visibility into your deploys with Honeycomb
It’s time to do away with statements like “the builds failed, and I don’t know why.” Honeycomb and CircleCI help you gain visibility into your CI/CD deploys. Sign up for a free Honeycomb account today to try it for yourself.
