Automatic Drupal instances per Git branch under your control, on your own server or your Kubernetes cluster.
When working with a (remote) team and/or for your sprint review, it is essential that your colleagues, product owners or stakeholders can easily try out your software, that is, not only see, but also make use of what you have implemented. Preferably, this should be possible for each branch in your repository.
GitLab’s CI/CD comes with a built-in feature that allows for enabling just that: (Auto) Review Apps!
Basically, Review Apps are dynamic environments that are built when a new branch is pushed to GitLab and removed when the branch is deleted from GitLab. In order to implement this functionality on your own server, you need to install GitLab Runner, which creates, updates and deletes your Review Apps. The setup is very flexible. You do not have to host your own instance of GitLab Server, you can run GitLab Server and Runner on the same machine or on different machines, and also have complex setups with multiple Runners on multiple machines. As long as you can register your GitLab Runner with a GitLab Server, you can deploy Review Apps. Alternatively, you can use Gitlab's recently introduced Auto DevOps and automatically deploy your Review Apps to a Kubernetes cluster.
In this talk I will show you how we at Reinblau use Review Apps in our Drupal projects. Our basic setup/workflow is usually as follows:
- There is one Drupal instance that is tied to the development branch and a corresponding static environment named ‘develop’.
- When a new feature branch is created from the development branch and pushed to GitLab, a new Drupal instance is automatically created in a dynamic environment, using database and public/private files from the static develop environment.
- Further commits to the feature branch are automatically deployed to the corresponding dynamic environment. Database and public/private files are not redeployed from the develop environment.
- In situations where the redeployment of database and public/private files is desired, the dynamic environment can be stopped manually from within the GitLab Web UI. Upon the next commit, the dynamic environment is automatically rebuilt with a current copy of database and public/private files from the develop environment.
- When the feature branch is merged into the development branch and removed from GitLab, the corresponding dynamic environment is also removed and the static develop environment is updated with the commits from the feature branch.
This talk will give a general overview of GitLab's CI/CD functionality and show the components involved when setting up Review Apps on your own server. The whole workflow can be demonstrated "live" with two virtual machines (GitLab Server and GitLab Runner) and a dev environment on the presentation computer and also with a pre-recorded screencast. Additionally, GitLabs's new Auto DevOps feature, which allows Review Apps to be automatically deployed on a Kubernetes cluster, will be discussed.
