This article is now outdated! We have prepared a new set of demo projects with full source code, public CI/CD pipelines and Kubernetes integration. Please visit https://gitlab.com/appuio and let us know how you like them! Issues and Merge Requests welcome!
“Deploy early and often” is one of the core principles of agile development. One solution to this problem are automated build and deploy pipelines.
This project uses such a pipeline, based on GitLab CI and OpenShift. A sample PHP application is built and deployed to APPUiO.
Three environments in form of OpenShift projects are used:
production. Those are the most commonly used setups but can be configured and extended. The idea is to build and deploy every commit from the master branch to the
test environment automatically. If a git tag is created, the previously built docker image is tagged with the git tag name and automatically deployed to
qual. The deployment to
production is a manual step and can be invoked on GitLab.
There are two pipelines setup in
.gitlab-ci.yml: One is run on every commit to the master branch and consists of the stages
lint stage starts a docker container in which the PHP code is verified for correct syntax. The
build stage starts a new OpenShift build (S2I), waits for its completion and shows the log output of the build. The last stage automatically deploys the built image to the
The second pipeline is started upon creation of a git tag. It consists of the stages
deploy-production. The first stage tags the docker image that was built for the respective git commit with the name of the created git tag. The
deploy-qual stage deploys the tagged docker image automatically to the
qualenvironment. The stage
deploy-production needs to be started manually and deploys to the
The application and the build is run on APPUiO which allows us to use the concepts and solutions OpenShift provides to work with builds and deployments. The directory
os contains the yaml-files which describe all the used OpenShift resources. These files live together with the code in the same git repository, which guarantees that the same version of the code is always built and deployed using same version of the OpenShift resources.
The build consists of an OpenShift
BuildConfig which uses a PHP source-to-image builder and builds a docker image containing the application. The image is tagged with the git commit hash and stored on the OpenShift docker registry.
DeploymentConfig is used to run the application. With the help of rolling deployments, zero downtime deployments are possible and the end user won’t experience any service disruption during updates. The liveness and readiness probes enable OpenShift to see if the container is running properly (liveness) and able to accept incoming traffic (readiness). Additionally an OpenShift service and route are set up to route traffic from outside the cluster to the application. The URL is specific for each environment and can be opened from within GitLab.
To see the pipeline in action you need three things:
- Your own fork of the repository on GitLab with GitLab CI enabled
- A project on APPUiO for each stage:
- A ServiceAccount with
editmembership in all projects
Step by step
- Set up Kubernetes/OpenShift integration in GitLab: https://docs.gitlab.com/ce/user/project/clusters/index.html#adding-an-existing-kubernetes-cluster
.gitlab-ci.yamlwith your APPUiO projects
- Commit & push the changes
- Watch the automated pipeline build the application and deploy it to the
- Create and push a git tag
- Watch the automated pipeline create image tags and deploy it to the
- Manually run a deployment to the
productionenvironemnt by visiting the pipeline on GitLab and click “play” on the
To further extend this setup, feature branches could be built and deployed to OpenShift. With this in place every merge request is built and a live version of the application is available to test the introduced changes. This ensures that only buildable changes are merged into the master branch and changes can be easily reviewed.