The CI/CD and DevOps Blog

Abhijit Kini

Abhijit Kini
Find me on:

Recent Posts

Notifying Continuous Integration failure/success status on Email & Slack

Notifications are particularly useful when you start hitting scale with the number of software projects that are being worked on in parallel. Having the flexibility to configure the Continuous Integration platform to be notified for different scenarios becomes critical, in my opinion, in helping to reduce technical debt

At Shippable, we use Slack extensively for our internal communications. It allows us to be more efficient, communicate faster and have targeted discussions. One of the scenarios we use Slack is to monitor and discuss build issues based on the build status of critical projects. An example shown below.


In this tutorial, I'll pick three scenarios and go over configuring notifications for a Continuous Integration project status on email and Slack. First I'll go over the basics of the shippable.yml file configuration for email/Slack notifications. Then I'll cover the scenarios for email and Slack.

Setting up code coverage for tests in Continuous Integration

I set up Continuous Integration (CI) test results visualization, in the previous tutorial. In this one, I'll set up code coverage visualization for the CI project.

What is Code coverage and why is it useful?

Code coverage is a measure used to describe the degree to which a source code of a program is tested using a particular test suite. In other words, it tells you the percentage of your code that is being tested. It is used as a guide to write more comprehensive tests to parts of your code. 

In practice, developers use it as part of exit criteria for milestons, to write tests for untested parts of  code, review developers have written good unit tests, etc.

While it is useful, one should remember not to use it as the only value to determine the quality of your code. In the words of Martin Fowler "Test coverage (also called code coverage) is a useful tool for finding untested parts of a codebase. Test coverage is of little use as a numeric statement of how good your tests are."

Create visualizations of your continuous integration test results

In this tutorial, I'll show you how to configure visualizations of Continuous Integration test results. This visualization not only looks good, but also helps a developer to drill down on tests that failed and find the root cause much quicker.

Here's how a successful Continuous Integration test result would look.

Configuring a build badge for a Node.js project status

I have gone through the steps of running  basic Continuous Integration (CI) on a Node.js app hosted on a private repository. Now I'll configure a visual indicator to display the status of the Node.js app when CI is run, using build badges. As shown below, I use it to update my team mates about the latest build status of my project in a convenient way.

First, what is a Badge and where is it used?

Badges, in the context of continuous integration, are used to display the meta-data of a build. For example, at the completion of a build, a status is displayed on whether a build succeeded or failed. This build status is incorporated into a build badge and can be displayed to viewers in different ways and in different locations. Badges are used to display different meta-data such as build status, code coverage percentage, status of third party dependencies, release versions, etc.

In this tutorial, I'll configure the Node.js app on Shippable to embed build status in two ways and show few examples of the outcome.

Running CI on a Node.js application hosted on a private repository

In my previous blogs, I completed running a basic Continuous Integration (CI) on a Node.js app hosted on a public repository. Next, I configured a simple unit test for the Node.js app to check for errors each time I did a code commit. 

In this tutorial, I'll cover running CI for the same Node.js application, if it were hosted on a private repository. Hosting code on a private repository source control system is the common way developers/teams operate during software development. The overview of the work flow is to sign in using source control provider credentials, authorizing a one-time access to private repositories, enabling the project, configuring the shippable.ymlfile, completing a successful CI run for the Node.js app.