The Shippable Blog

Provisioning AWS infrastructure with Terraform

Provisioning and updating infrastructure is a the first step in setting up your development, beta, or production environments. Hasicorp's Terraform format is fast becoming very popular for this use case.  We love Terraform at Shippable due to its easy declarative syntax, similar to our pipelines syntax. Other advantages are: 

  • Infrastructure as Code: Infrastructure is described using a high-level configuration syntax. This allows a blueprint of your datacenter to be versioned and treated as you would any other code. Additionally, infrastructure can be shared and re-used.

  • Execution Plans: Terraform has a "planning" step where it generates anexecution plan. The execution plan shows what Terraform will do when you call apply. This lets you avoid any surprises when Terraform manipulates infrastructure.

  • Resource Graph: Terraform builds a graph of all your resources, and parallelizes the creation and modification of any non-dependent resources. Because of this, Terraform builds infrastructure as efficiently as possible, and operators get insight into dependencies in their infrastructure.

  • Change Automation: Complex changesets can be applied to your infrastructure with minimal human interaction. With the previously mentioned execution plan and resource graph, you know exactly what Terraform will change and in what order, avoiding many possible human errors.

At Shippable, we use Terraform to provision all our environments and automate the provisioning using our Pipelines feature. If you're interested in taking a look at our terraform scripts and pipelines config, we have made our repositories public so you can check them out:  

Interested in trying it yourself? The following example walks you through a sample project that provisions two t2.micro instances on AWS. We've kept it simple for easy understanding, but you can also automate provisioning of complex environments as seen in our beta infra scripts above.

Customize environments for different branches of a Continuous Integration project

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.

Upgrading your Continuous Integration/Continuous Delivery subscription

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.

Changing the default timeout for a Continuous Integration project

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. 

Configure web hooks to trigger Continuous Integration builds

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.