The CI/CD and DevOps Blog

There have been several requests on our support forum on how to customize environments to specific branches while running Continuous Integration (CI) builds for a repository that has multiple branches. In this tutorial, I'll go over a common scenario and review the multiple ways we can configure branch-specific actions during the CI build. 

The scenario I use for this tutorial is, to pull a Docker image in the CI process and upon completion, use different tags for the branches when pushing the Docker image to Docker Hub. The Docker tags should be customized to the specific branch where the CI was processed and should include the build number. The final results of successful CI process tagging different branches looks as shown.

Continuous Integration (CI) helps developers to speed up the application development life cycle by automating build, test and deployment of the application. Continuous Delivery (CD), helps developers in shipping code from source control systems to the production environment.

You can have both CI and CD, for free, by using Shippable.In this tutorial, I'll go over what's available for free, when you need to upgrade and how to upgrade.

There are few occassions when Continuous Integration (CI) builds timeout. This means, a CI build failed to complete within the expected time and is now in a timeout or in an incomplete state. Until the timed out build remains in that state for 60 minutes (for free subscription plans on Shippable) or 120 minutes (for paid subscription plans on Shippable) or it is manually canceled, it can block CI build queues.

Changing the default timeout of 60 minutes (for free plans) or 120 minutes (for paid plans) will help you address this problem. In this tutorial, I'll walk you through changing the default timeout for a CI project so that you have more control over the build queues blocked due to build timeouts. 

Web hooks on source control providers, such as GitHub and Bitbucket, are commonly used to trigger actions. This is achieved by setting up integrations that listen to specific events on the source control provider, where the source control provider sends a HTTP POST payload to the web hook's configured URL. Examples include notifying a user or a channel of an event, updating an external issue tracker, deploying code to a production server and triggering Continuous Integration builds. 

In this tutorial, I'll go over configuring web hooks to trigger for five scenarios - commits, pull requests, tags, releases and temporarily pausing all web hooks to the project.

Software applications are regularly updated primarily to add new features, resolve bugs in the code and for security enhancements. A development language is no exception and each major update is called as a version. While it is a great advantage to have newer features, lesser issues and stronger security, the challenge arises when complexity creeps in. With multiple versions of a language, applications that depend on them have to be compatible with many versions. Moreover, when the applications themselves have to be updated, the combination of different versions of the language and the application makes it a challenge to write and test code.

Testing code against multiple versions of a language early in the application delivery life cycle helps in fixing errors quickly and makes testing more efficient in the downstream of the life cycle. In this tutorial, I'll go through testing a Node.js application against multiple versions of Node.js for every code commit during the continuous integration phase of the software development life cycle.