Getting a handle on CI cost and duration using an internal developer portal

Introduction

Port’s software engineering team is always on the lookout for new ways to use Port. While we’re aware of the possibility to integrate Port with FinOps tools to create a shared responsibility for the organization's cloud computing infrastructure and costs, we wanted to take a slightly different approach and use Port as the FinOps tool itself.

Our goal is to get a view on CI costs and CI duration, from a job, workflow, branch and feature perspective. This approach can bring a lot of insight to developers and teams.

But first, let’s begin with a few words about FinOps in the internal developer portal.

FinOps in the internal developer portal

In the world of FinOps, time is money, and money is time, it all comes down to who you ask. Different personas in an organization need access to different types of resolutions when looking at the organization’s investments in the project management lifecycle.

Internal developer portals are a perfect solution to the problem, since they are built to contain all the relevant data about the SDLC and any other relevant app, from AppSec to incident management and more, and to abstract that data for developers. Adding FinOps cost data to the internal developer portal creates a real time snapshot of everything cost in the engineering environment, and allocates the cost to the right microservice and developer in a fraction of a second, based on the definitions in Port’s blueprints. Once data is unified into the portal, data can be presented to developers in a way that is relevant to their flow of work and that reduces cognitive load. Just like developers track bugs in one central place, they can see the cost implications of their work. 

In this example, we’ll show FinOps data coming from an internal table, but the same can be achieved with an integration with a FinOps tool (e.g. cloud costs).

CI costing and duration

Can we extend the same benefits of using FinOps in the developer portal to understand CI costing and duration at all levels that matter to developers, team leads and management? The answer is yes, and this is the central point of this blog.

In this blog, we will showcase a practical example of connecting Jira and GitHub to the internal developer portal to provide developers and teams with insights about the cost of CI. These principles can also be implemented when looking at adding FinOps data to your internal developer portal. 

Let’s dive in.

How much does a Jira feature cost us in terms of CI/CD runtime costs?

To answer this question, let’s first begin with the views we would need to provide developers and teams so that they can easily understand CI costs and duration. Our internal developer portal would need information about:

1. All CI/CD jobs related to a specific branch, and their duration.
2. All CI/CD jobs, related to each different branch related to a Jira ticket, and their duration.

To do that we also would need:

• A convenient way to calculate the cost of a job, in accordance with all of the different types and costs of different runners.
• A convenient way to aggregate costs related to each branch scope and Jira ticket.

To achieve this, we will:

• First, build our software catalog by connecting our CI/CD and Git platforms to our Jira environment. This will provide us with the information about the relevant entities for which we’d like to track CI cost and duration data.
• Second, for aggregations and cost calculations, we will make use of Port’s relations and calculated properties so that the CI cost and duration will be calculated by entity. As for the source of the cost data, we just added a static table with costs to GitHub.

Our use case uses the GitHub Actions CI/CD platform, but the same logic can be applied to any CI/CD solution.

Setting up the software catalog

In Port, setting up a software catalog begins with defining the metadata that needs to be brought into it, and this is done with blueprints. Blueprints are the foundational building blocks of the internal developer portal. They hold the schema of the entities you wish to represent in the software catalog.

Let’s look at the blueprints we’ll use to realize this use case:

• The Job blueprint provides information about specific tasks or sets of tasks that need to be performed within a GitHub Actions workflow with properties such as duration.
• The Runner Type blueprint provides information about the specifications, capabilities, and associated costs of the machines used to execute workflow runs in GitHub Actions with properties such as Cost per minute
  (Note: The Runner Type blueprint contains cost data for each specific type of machine dedicated to each job that ran.)
• The Workflow blueprint provides information about specific workflows in your GitHub repository. This could include information such as code owners, creation dates etc...
• The Workflow Run blueprint provides information about the execution of defined sets of automated tasks within GitHub Actions workflows with properties such as Run Attempts, Triggering Actor, Starting Time.
• The Branch blueprint provides information about git branches with properties such as name, lastUpdate and url.
• The Jira Issue blueprint provides information about issues in Jira with properties such as status, creator, reporter.

The lines between the blueprints are the relations between them, so that developers get CI cost data related to each job, workflow, branch. 

Once we connect the portal to GitHub and Jira - the blueprint schemas will be populated with metadata and the software catalog will be automatically created, using autodiscovery. Once the data is populated, we’ll see the data we want about  our CI/CD runs for each one of the blueprint types.

Here is the view of a Jira Issue entity - our New Awesome Feature - for which we want to gain insight with regards to the CI cost and duration. At the bottom of the image we can also see its related entities, the backend and the frontend of the feature. We can get data about their CI cost and duration too.

This visualization offers a clear view of how much each feature has cost in terms of the CI process, enabling better cost analysis and decision-making.

Analyzing total Workflow Run duration

Understanding the time taken by specific workflow runs over a defined period is crucial for identifying bottlenecks and optimizing processes. To do this we’ll add data to the workflow run blueprints. We can then filter for completed workflow runs (using the “success” or “failed” status). Once we do this, we can create a calculated property in Port that will display the total duration of all workflow runs of this type.

CI cost and duration data can be presented to teams, users, or any other custom blueprint you want. This integration opens doors to a comprehensive understanding of the financial impact of CI as well as duration (which is a blocker of sorts) enabling better decision-making, resource allocation, and processes.