Monitor your CI Pipelines like a Facebook!
Tags: devops, github, ci, githubactions
Published: 2022-01-13 06:20:12

Using [GitHub Actions](https://github.com/features/actions) provides engineering teams with a quick and reliable way to create a solid CI/CD build process. A per-minute model helps with expanding capabilities well beyond other solutions like customized build agents that may require continued maintenance. One critical piece missing is the ability to view the various aspects of the builds that are executed. This can create extra costs from build steps that could be made more efficient. Optimizing GitHub Actions with [**Meercode**](https://meercode.io/) is simple. And with the results it provides, you can see a possible reduction of up to 30% in costs associated with CI/CD pipelines.

## Operating at status quo.

Our typical approach as automation experts is to go with what we know. Most of the time, that means using tried and true approaches to CD/CD. In that spirit, you will find many of us still rely on in-house build agents to handle running builds. While beneficial as a specialized and static build runner, they come with their own costs in the way of maintenance.

In order to do things right, a build agent typically needs some sort of base image. On top of that image are the tools and frameworks necessary to build the team’s software. Doing so allows for scaling your build environment horizontally or recreating an agent that isn’t operating normally. This was the standard until more source code repository services started providing CI/CD as part of their offerings.

Now we use services like GitHub Actions to handle many of today’s top technology stacks. The maintenance once required to keep build agent images up-to-date are handled automatically. This goes for any build runner image they have available [^1]:

- Windows Server 2019
- Windows Server 2022
- Ubuntu 20.04
- Ubuntu 18.04
- MacOS Big Sur 11
- MacOS Catalina 10.15

[^1]: https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners

All of this is available at no cost for open-source and free projects (up to 2,000 minutes). However, going beyond this may require another subscription level. In any case, you want to ensure you use the build runners as efficiently as possible. While GitHub does provide some detail on storage and build minutes used, it lacks insight into details that may help your team use less of those resources.

## Cost optimization with a view.

When using these build runners at a professional level, It is vital to view things in a way that makes sense. Especially when it comes to those resources that have costs associated with their usage. There are many aspects of **Meercode** that are designed to do just that. The goal is to save money through optimization that you can visualize.

### Cutting costs one build at a time.

Let’s take a look at some of the areas that **Meercode** can help with Optimizing GitHub Actions. Through looking at these elements, a picture can develop of areas of the CI/CD pipeline that can be modified to reduce build times. The way this is done with **Meercode** allows for a better understanding of each part of the process thanks to the various reports available.

When looking at each build, data can be derived to determine what levels would benefit from more optimization. Starting with each step in the workflow, engineers are able to see which of those steps are long-running. From there, we start working upwards.

The data from the workflows comprising those steps is also aggregated to see which of those workflows show similarities (or differences) that can help identify commonalities. These common elements among the workflow steps may identify a speed bump in the build process. But it doesn’t stop from there.

High level views of the projects and organizations are next up. Here we can derive information from specific project build workflows. For example, one project may be using a very small amount of build time in comparison to other projects. While this may be out of necessity, it may also point to a situation where non-standard processes are used that stymie the process. In turn, creating additional cost where it isn’t needed. A view of team members can also help determine who is utilizing these resources the most.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/shrnbvew8xhgjdpdt9eo.png)


### Meercode peeks deep into the process.

**Meercode** is already helping thousands of engineers with a way to look into the details of their CI/CD process. Rather than making your “best guess,” you can view actual data that is relevant to various parts of the process. This is especially important when working with on-demand build agents provided by various platforms.

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/fdaluw6khhobz4tc2kb6.png)

Yes we are talking about **Meercode** as it applies to GitHub, but it doesn’t stop there. For those with multiple build platforms, **Meercode** allows for integrations to allow the same view for each of those products:

- GitHub
- GitLab CI
- Travis CI
- Azure DevOps
- Vercel
- Bitrise
- Buddy

With Jenkins on the horizon! Using this integration, you can be assured you have more ability to look at different parts of the CI/CD process to find ways to save valuable units of time. It’s also important to note that **Meercode** does this without ever accessing source code. Only the run/build metadata from the CI/CD process.

## What does it mean to optimize GitHub Actions?

When we talk about optimization, we’re really talking about how we can shave time off of each step in the build process. This may be done via a variety of means, but the fact remains the same. Anything that can be done, should be done. What kinds of things can you do to optimize your workflows? There are many posts dedicated to this topic, but there are a couple things to look at initially.

### Cache where you can.

Different software stacks have different ways they install prerequisite assemblies and tools used to build the software. This may be a collection of nuget packages that are common among projects. In the case of restoring packages via tools like npm, these packages are often downloaded to the developers machine.

This local build gives the impression that it is completed quickly. Since the files are cached, they don’t require being downloaded every time like they would on a build agent. Build agents are usually “vanilla.” This means they have only the basics needed to complete a workflow. Finding a way to cache the prerequisite packages within the codebase is one way to optimize this common slow-running portion of builds.

### Fix-forward with monitoring.

Monitoring is more than just seeing if a resource is up or down. This is very true when looking at different aspects of build and deploy operations. It has become more important as SaaS offerings become available. Proper monitoring means looking at the right data and setting the right thresholds.

It is important to set thresholds to see when these pay-per-use resources go outside of a baseline. **Meercode** helps provide the data points necessary to look at various monitoring systems to see where thresholds belong. The ongoing information allows for showing trends that equal cost reductions.

## Meercode wants to help.

By recognizing the lack of helpful information in this realm, [**Meercode**](https://meercode.io/) has taken steps to work with developers and many common build packages. The culmination of this work is a product that neatly integrates with your current CI/CD process and adds a missing view of the bigger picture. Try it free by visiting the website. After the simple setup, the critical data needed will be shown in a way that just makes sense.