The CI/CD and DevOps Blog

Learn about various tried-and-tested strategies that will help you ship code faster

Extend your CI workflows using Assembly Lines

Do more with less - No one disagrees with this famous quote, but how often do we really take a step back to think about pushing the envelope with what we have right now ? At Shippable, we've tried to constantly ask this question with every feature we've built. This ideology manifests itself in the capabilities the current Shippable workflows have, compared to what they used to a few years back. All this while keeping things simple and with zero additional costs to the customers. A lot of our customers started using Assembly Lines after the launch, a year go. Most of them didn't need much help but we do admit that some steps in extending traditional CI with the new Assembly Lines are a bit complicated. The objective of this post is to provide a detailed, step by step guide, to enable any CI job on Shippable to use the power of Assembly Lines 

REST API best practice: One Database call per Route

Shippable has been on a roll for the last 8 months. We scaled our team by 3X, had the best-ever release of our continuous integration and delivery platform on February 29, and we’ve continued launching 10+ features every month since then. 

As we scaled our development team, every new developer joined us with preconceived ideas about how software is developed. Unfortunately, software development is pretty inefficient at most places, and this is one of the main reasons we started Shippable. We at Shippable do things differently. We focus on shipping code faster and faster, and we hold some principles very close to our heart. 

One of our strongest beliefs is in pure REST APIs. This means we follow the cardinal rule: thou shalt not make multiple calls to DB objects from inside a single RESTable route. So when any new developer joins our team, his first question is : Why do we call our API from within our API?

Triggering a custom webhook after continuous integration

Even with the best continuous integration platform on the planet, you will still have scenarios when you want to trigger custom workflows after your CI finishes. These workflows could be very targeted and should have the ability to be customized based on whether CI passed.

Today, I am going to introduce you to a very versatile feature we added recently - the ability to add a custom webhook to your CI workflows that will be triggered after your build finishes. You can configure this trigger based on several factors, including build result, branch, etc and also include one or more parameters.  

This new feature is documented here in greater detail

Let's look at a simple example to see how this works. I have a project manishas/sample_nodejs and I want to open a GitHub issue in the repository if my build fails. I also want to customize the issue title and description to include a the project name, build number, commit message, and build URL.