Automation in Branch Name Convention

How to set branch name convention in your CICD pipeline, and how to develop simple automations to your pipeline from your branch name

how to automate your CICD pipeline

Background — from Jenkins to GitLab

We at Via 💙 our Jenkins Jobs, we have been using Jenkins for a long while and most of our CICD pipelines were built on Jenkins Jobs.

A few months ago the R&D team decided to start a migration to GitLab from GitHub, which is also an interesting story, in a few words, we decided that we care more for a feature-rich CICD than its availability. As part of the migration to GitLab we decided to leave behind most of our Jenkins jobs and build a new pipeline that is based on GitLab runners.

As migration to the new CICD pipeline ended we were very happy with the results, pipeline run much faster, new features were added, the pipeline fails if a critical step fails, and much more. but with all this greatness there was one thing that was missing. In Jenkins setting an environment variable to the pipeline is a very simple task, but in GitLab, it is a tedious one.

The downsides — from 2 clicks to 30

In our case at Via, we use an environment variable of the pipeline to deploy to private stacks, small dev environments for feature testing. Building these private stacks is a very common day-to-day task so it is important for us that we will be able to set it seamlessly.

After a few weeks of struggling with this, really struggling!! we were used to setting this variable in 2 clicks (~1 second) to around 30 clicks (~40 seconds), worth mentioning that there is also a way to override the variable for the whole pipeline, which is 8 clicks but could take 2–3 minutes because the pipeline will start again from zero, and some more cost of computation time.

Yes, you are correct, a few clicks and 1 minute of waiting is not that much, but I believe that wherever we can automate mundane tasks will cause higher productivity, fewer trivial errors, and an overall happier work environment (I like to focus on developing not mundane tasks)

Gitlab on the left vs Jenkins on the right (GitLab vs Jenkins)

Automating by branch naming convention

A branch naming convention is a common practice that enforces developers to name their git branches in a certain way. Here are the top branch name conventions we are using

1. feature vs fix — is this branch a new feature or a bug fix
2. ticket or issue number — what ticket is related to this git branch for context
3. environment variable — set some pipeline environment variable from your branch name

I guess the first 2 are very common and obvious, when you look at some git branches it is a very nice idea to have some context on what is going on in that branch, especially if that branch is a few years old. Attaching the branch name to a Jira ticket is a very common and important practice that solves this issue.

Let's dive deeper into point number 3. To solve the issue that arose from our migration to GitLab we added the following branch name convention feat/RAC-123-great-feature-for-caching.cache will set our STAGE environment variable to cache.

This is the code in our gitlab-ci.yaml file

.set_stage_deploy_private: &set_stage_deploy_private
  - echo "Please note that deploy private does not set the STAGE env var by 
            default"
  - echo "You can set it manually or follow Branch Name Convention 
            (See README.me file)"
  - echo "Your branch name is $CI_COMMIT_REF_NAME"
  # using Shell Parameter Expansion to extract STAGE after the . sign
  - if [ -z "$STAGE" ] || [ -z "${STAGE// }" ] ; 
      then echo "STAGE was not set-will set STAGE from Branch Name Convention" ;
      STAGE="${CI_COMMIT_REF_NAME##*.}" ; 
    fi
  - echo "Your STAGE is $STAGE"
  - echo "Verifying the STAGE is properly set ... "
  # if STAGE is empty (was not set as env var and not with Branch Name 
  # Convention) abort build
  - if [ -z "$STAGE" ] || [ -z "${STAGE// }" ] ; 
      then echo "STAGE is empty! STAGE was not set properly exiting..." ; 
      exit 1 ; 
    fi
  # if STAGE is "sandbox" or "prod" abort the build
  - if [ "$STAGE" = "$CI_COMMIT_REF_NAME" ] || [ "$STAGE" = "sandbox" ] || 
          [ "$STAGE" = "prod" ] ; 
        then echo "STAGE is not allowed! STAGE was not set properly 
            exiting..." ; 
        exit 1 ; 
    fi
  - echo "Deploying service $SERVICE with stage $STAGE"

# Matrix deployment job for all 8 services to private stack 
deploy_private:
  extends:
    - .deploy-dev
  variables:
    AWS_ACCOUNT_ID: $AWS_ACCOUNT_ID_DEV
    AWS_REGION: $AWS_REGION_DEV
  environment: private/${SERVICE}
  parallel:
    matrix:
      - SERVICE:
          - rabo
          - rai
          - rams
          - raop
          - ras
          - raw
          - rps
          - school
  before_script:
    - *set_stage_deploy_private    # will set STAGE env var to cache
  script:
    - *deploy_private              # rest of deployment logic

I hope the code is pretty self-explanatory, The before_script will run set_stage_deploy_private which extracts the text after the “.” sign in the branch name and will set it as the STAGE environment variable. After that deployment will continue regularly.

I searched for a similar solution to this for a while, I hope this will help some of the readers in a similar situation to this.