How GitLab Review apps helped us shift testing left, into the development cycle!

4 min readJun 9, 2023

Introduction

As a QA professional, finding bugs is a great thing. However, discovering them during the traditional testing phase can be costly. By that time, developers have often moved on to different user stories, switched gears and context. Consequently, the user story is handed back to the developer, resulting in inefficiency and added expenses. This challenge has plagued teams for a long time, leading to the question: How can testing be moved as far left as possible in the sprint cycle? How can we ensure that the features created are thoroughly tested on multiple levels before merging? And, importantly, how can we reduce costs?

GitLab Review apps to the rescue!!

What is a Review app?

A review app is a dynamic environment that runs the developers’ branch code in a Kubernetes cluster on your hosting provider.

How does it work?

In our case, GitLab and Jira are connected. Once a developer creates a branch or merge request in Jira, a Review app is generated. This triggers an event in GitLab, deploying the feature branch into a namespace in Kubernetes using HELM.

Here’s an example of the deployment script:

deploy_review_application:
  extends:
    - .k8s:rules:review
  stage: deploy
  tags:
    - docker-build
  interruptible: true
  script:
    - TAG=$(bash -c "echo ${CI_COMMIT_TAG:-${CI_MERGE_REQUEST_IID:-${CI_COMMIT_BRANCH:-${K8S}}}}")
    - helm upgrade --debug --install $TAG ./.k8s/review-deployment --create-namespace --set images.tag=$TAG --namespace $TAG
    - kubectl rollout restart deploy -n $TAG
    - URL=$(bash -c "echo ${CI_MERGE_REQUEST_IID}")
    - |
      curl -H "Content-Type:application/json" -d '{"text": "Your review app will be ready in 5 minutes. Visit this link: https://'$URL'.whatever.youspecify.url.in.gitlab.com"}' $REVIEW_APP_WEBHOOK
  environment:
    name: k8s-review-deployment-$CI_MERGE_REQUEST_IID
    url: https://$CI_MERGE_REQUEST_IID.whatever.youspecify.url.in.gitlab.com
    on_stop: stop_review_application
    auto_stop_in: 2 weeks
  allow_failure: true

For instance, if the merge request ID is 4850 in GitLab, the created environment will be called: https://4850.whatever.youspecify.url.in.gitlab.com.

This link is available in GitLab, under the same merge request ID, labeled “View app,” which takes you to the provided URL.

Gitlab link that goes to the review app

To streamline the process, we have integrated MS Teams with GitLab so that messages from GitLab pipelines can be sent to any channel in MS Teams. After the trigger event, a notification is sent to MS Teams, informing team members that the environment is up and running. The notification includes a clickable link that takes you directly to the dynamic review environment.

MS teams notification with the Review app url

Initiate the test automation fun!

What are the benefits and why should you use it?

GitLab Review Apps offer several advantages. They allow designers, product managers, product owners, and developers to view changes without having to check out branches or run changes in a sandbox environment. Even worse, they eliminate the need to merge changes and deploy them to staging without proper testing.

In our case, we can test and automate various client configurations during the development phase of a user story. This ensures that the newly created feature functions correctly and is automated across different configurations, guaranteeing quality before the user story is merged!

Another benefit is that any merge request can be deployed into the Kubernetes cluster at any time.

Test automation for the win

QA’s now work in parallel with developers, and testing has shifted left. This means that all necessary tests on different levels (unit and integration by the developer, API/UI by QA) are created before the user story is merged. The newly created test automation scenarios are automatically added to the daily regression suite, and the test results are sent to Datadog, where they are visualized on different test levels (unit, integration, API/UI).

Once the merge is completed, the Review app environment is destroyed and deleted from the Kubernetes namespace and GitLab. If a merge request remains open for an extended period, the Review app is closed after a specified duration in your .gitlab-ci.yml file. This helps keep the Kubernetes nodes clean by removing old merge request IDs and associated environments.

Final thoughts

Review Apps are fantastic collaborative tools that assist different disciplines within a team in aligning the features created in a sprint. They ensure that all specified requirements in the user story are met. This is a significant improvement compared to the old sandbox times or when the user story was moved to traditional QA testing after being merged (waterfall approach).

In addition to speeding up the sprint, Review Apps enhance the overall quality of the application, as automation is delivered alongside the feature.

Review Apps take quality to the next level!

How GitLab Review apps helped us shift testing left, into the development cycle!

Written by Rody Bothe