Automatic Dependency Management 

January 15, 2020 10:38 am | Published by


How to solve code problems with code solutions  

As Infrastructure as Code (IaC) enables us to deploy faster and more reliably, we are leaning on more and more dependencies, but who keeps them up to date? The developers would be the first guess, but if the developers are checking for new artefacts, releases or new Git tags they could also write new Code. That of course would be much more satisfying but normally customers do not ask for or want to pay for updating dependencies in your code anyway.

I am going to describe how to overcome the flood of code dependencies introduced by Infrastructure as Code (IaC) and microservices alike. 


RenovateBot – isn’t there an app for that?   

RenovateBot is an implementation of a bot pattern, which will scan Git repos for dependencies and checks if there are new versions. If a new version of a dependency has been found, RenovateBot will open a new branch, commit the version change to the branch and finally open a new Merge Request on Gitlab and a Pull Request on Github.   

Sounds good so far, but what dependencies can RenovateBot update and on which platforms? The spectrum is very broad. Some of the supported dependency types are:

  •  ansible  
  •  dockerfile  
  •  git-submodules  
  •  maven  
  •  npm  
  •  nuget  
  •  ruby  
  •  swift  
  •  terraform, etc.


Platform wise the SaaS and self-hosted options for, and Bitbucket are supported. That pretty much includes all big players and languages!

Now we have MRs/PRs for every dependency we have not updated. But who is testing the changes? Here comes the tool category into play which every developer should already be using in 2020, CICD pipelines.


GitlabCI – a poem to lazy people  

What do Developers and DevOps Engineers have in common? Correct, they are lazy!

Developers try to keep their code DRY (“Do not Repeat Yourself”) and DevOps Engineers try to automate every step. But both are profiting from CICD pipelines, the first ones get instant feedback on their code and the second ones have an abstraction layer to automate deployments and introduce governance.

To simplify this, a CICD pipeline runs command line commands as a user would, but every time the same ones, regardless how often it has executed the commands already. Usually a pipeline is triggered when new code has been pushed to the server, but pipelines can also be started manually, on a schedule or other external dependencies.


We use GitlabCI in combination with RenovateBot in two ways: 

First, the pipeline is a hosting platform, we are running the bot image as schedule with autodiscover enabled. Doing so we have no external dependencies except hosting the CI pipeline which has been already present. You can find an example repo here.

The second use case is that we automatically test the changes which RenovateBot has pushed on its branches. This branch is by default prefixed with ‘renovate/’.   

In our use case, we are using the bot to test if Terraform provider updates are breaking anything. We have implemented this as a special test with ‘terraform plan -detailed-exitcode’, which is used to plan out IaC changes, which fails if any infrastructure changes are suggested. The pipeline fails as the [terraform exit code]( will not be 0. Should this CI job run successfully we auto merge the MR to the master branch using the auto-merge feature of ‘RenovateBot’.    

This is a short example of how to use a combination of a bot and CICD pipelines. 



If you have questions or are interested to improve your DevOps Journey you can contact us here. Regardless of the industry sector – retail, insurance, banking, … – large enterprises which trust in cloud services invest in the scalability of their cloud. 




Tags: ,

This post was written by Sebastian Poxhofer