Ruby on Rails Continuous Integration with Azure DevOps

In this post we'll walk you through the basics of using Azure DevOps Services to create a Ruby on Rails Continuous Integration pipeline.

Quick Refresher on Continuous Integration (CI)

Continuous Integration is the process used to evaluate the addition of new code to a main branch. Basically, to make sure that the code in progress isn't causing major issues with where the rest of the project is at. This process typically involves things like linting, running tests and security scanning.

We will configure our projects to execute our CI in two distinct places: first anytime code is pushed to an active pull request and second before a pull request is able to be merged.

This allows developers to have a clear understanding of the state of their branch and their ability to merge into main when the time comes.

Azure DevOps Services (ADO) Overview

Azure DevOps Services is a full-feature development platform like GitHub and Jira/Bitbucket. It includes things like work items, source code management, test artifacts and pipelines.

This service existed before Microsoft acquired GitHub so it is unclear what the longevity of it will be. We do have a fair number of projects within Azure DevOps services, although going forward we'll continue to move towards consolidating on GitHub.

Creating a CI Pipeline

Creating a new pipeline in ADO is easy enough, which is easy to say after creating dozens of them. The whole process does leave a little to be desired.

The first step is to create a file in your repository to store the pipeline configuration. This is a YAML file and we'll reference it later when creating the pipeline. Below is a sample of the YAML file:

trigger:
- main

# containers required to lint / scan / build and test the services
resources:
  containers:
  - container: build
    image: krsyoung/rails-build:3.3.1

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self
- script: |
    # install gems with 4 parallel jobs
    bundle install --quiet --jobs=4
    # run pr.sh script (standard, test, bundle audit)
    bash utils/scripts/pr.sh
  displayName: 'PR validation'
  target: build

Once the above is committed and merged to main, the next step is to create the pipeline within ADO:

1. New Pipeline - Within your project, select "Pipelines" and then click the "New Pipeline" button. Next you'll need to select where your code is stored. If it is within ADO, pick "Azure Repos Git" and then the repository name.
2. Configure your Pipeline - For our projects we always elect to store a pipeline configuration file within the repo. This file can be referenced in the pipeline by selecting "Existing Azure Pipelines YAML File". We generally name it .azure_pipeline.yml or ci.yml
3. Review and Run - The pipeline wizard will show you the contents of the file and then present a button to "Run" it.

At this point you now have a CI pipeline defined with a trigger on main, but we want to also configure it to run whenever code is pushed to a branch. Next up we'll look at how to configure that within ADO.

Triggering the Pipeline on Branch Push

You need to dig in the UI in order to configure the pipeline run on push. To do this, navigate through ADO as follows:

1. Project Settings
2. Repos > Repositories
3. click the repo for your project
4. Policies
5. Branch Policies > main
6. Build Validation
7. click the + button
8. select the pipeline you just created, customize the other fields to your needs

Upon saving, you will now have a working pipeline definition that triggers anytime a push is made to a branch that is associated with a pull request. The status of the pipeline shows under the "Checks" section of the pull request.

Now you have the basics in place, you can easily expand what the pipelines do by adding steps directly to the script section of the yaml file, or by creating a shell script with the commands that you want.