Configuration of a continuous integration pipeline

Configuration and testing of a Continuous Integration (CI) pipeline in GitLab to automate the packaging, testing, releasing, publishing, and deployment of your R code.

€1,000 (excluding 21% VAT) per repository

What do you get?

GitLab provides great infrastructure to automate everything there is to getting your R code to a production environment. This includes the following stages:

  • Packaging
  • Testing
  • Releasing
  • Publishing
  • Deployment

As part of this service, I will create a new CI/CD configuration file (i.e. the .gitlab-ci.yml file) in your GitLab repository. If you use Slack, Teams, or Google's chat, I can also help you configure a webhook to let GitLab send messages with an update on the status of the CI/CD pipeline to your team's development chat room.

So let's look at the various stages in the CI/CD pipeline and how they relate to software written in R.


Most R code should ideally be contained within an R extension package. The first stage in the CI/CD pipeline is then to build the R package using the R CMD build command. This will create a package tarball (i.e. a file with the tar.gz extension) which becomes an artifact and is passed to the next stages in the pipeline.


Running tests on the R package is the most important function of the CI/CD pipeline and it should be run whenever changes are pushed to the repository and not only when the package should be released. The testing stage uses the R CMD check command which performs a whole range of quality checks on your package's sources and executes all the unit tests. If there are any critical issues or if one of the unit tests doesn't pass, the pipeline stops.


Releasing an R package is essentially just setting a version on the package. There are various strategies which can be used for versioning a package so part of this service is to choose a strategy which best fits your needs.

Releases can be completely automatic, for example if changes are pushed to the main (or release) branch and all tests pass, or they can be initiated using a tagged commit.


Publishing an R package makes the package generally available within your organization. This means that it is stored in a location where it is accessible to people in your organization, even if they do not have access to the repository in GitLab. They can install the package using R's install.packages() command. With a proper configuration of the CI/CD pipeline you can do this all within GitLab.


Once an R package is published within your organization, then deployment is probably not necessary. However, you may have a Shiny application on a production server or your model running in a Docker container somewhere, which requires a bit more work besides just publishing the package.

What don't you get?

A Dockerfile which is bespoke to your testing and production environments.

I can help you select a suitable Docker image to start with, but any modifications to adapt this image to your unique environment are outside the scope of this service.

Request a quote

Click on the button below to pick a time in my calendar to discuss your needs and I will put together a quote for you!


When and how much Value Added Tax (VAT) do we charge on our services?

We charge no VAT if your organization is based outside of the European Union (EU).

We reverse charge the VAT to you if your organization is based in one of the EU countries, except the Netherlands, and you provide us with a valid VAT registration number for your organization.

We apply 21% VAT to our services if your organization is based in the Netherlands or if it is based in the European Union and you do not provide us with a valid VAT registration number for your organization.