CI‐CD Pipeline
To follow the agile development principles (thus making the deployment quicker, easier, and fully automatic) we have developed a CI/CD pipeline visible in the diagram below.
We are taking full advantage of the following GitHub Actions workflows:
-
Pull requests to the restricted branches (
mainandsprint-release):- Frontend CI - Runs linting and test checks for the frontend service.
- Backend CI - Runs linting, formatting, and test checks for the backend service.
- Build Docker Compose - Test if the Build of the whole Docker Compose file works.
-
On new
sprint-XX-releaseorsprint-xx-release-candidatetags:- Publish and deploy Production Env. - Build and publish the newest Docker images and deploy them to the production environment Ubuntu server.
- Publish and deploy Test Env. - Build and publish the newest Docker images and deploy them to the test environment Ubuntu server.
-
On push to the
sprint-releasebranch- Publish and deploy Test Env. - Build and publish the newest Docker images and deploy them to the test environment Ubuntu server.
For the deployment of our service (both production and testing), we are using Ubuntu VMs hosted by the Hetzner provider. When a deploy action is started, all Docker Images are built and published to the ghcr.io container images repository of the amosproj/amos2024ss04-building-information-enhancer project. Then, an SSH connection is made, and the appropriate server pulls and deploys the newest container images using the Docker Compose file. The servers are restricted to only allow incoming connections for HTTP, HTTPS, and SSH protocols.
During each sprint development, new features are created on separate development branches and pull-requested to the sprint-release branch. This branch is restricted to only accepting pull requests, including the need for all passed actions and at least a single peer review. When a PR is merged into the sprint-release branch, the workflow for deployment into the test environments is run. This is done to minimize the surprises and test the software inside the Ubuntu servers, before the official releases.
Additionally, the Release Manager creates a new release-candidate tag, automatically starting the aforementioned deploy workflow to the test environment. Therefore, the sprint-release branch contains the newest and latest changes to the product and is tagged as a sprint-XX-release-candidate each sprint. The latest test environment can be viewed here.
One downside of this setup is that when new changes are pushed to the sprint-release branch before the sprint-candidate is released, they can overwrite the tag and push the newest changes to the test environment. This was done by purpose in order to allow the software developers to test their newest changes inside the Ubuntu environment, without needing to re-run the CI-CD pipeline and tagging the candidate.
The production system is located in the main branch. Similarly to the release candidate, when a new sprint-xx-release tag is created, an appropriate workflow is called and the newest code is deployed to the production server. Again, the main branch is restricted to only accepting pull requests, including the need for all passed actions and at least a single peer review. The production system can be viewed here.