Designing a Distributed System for an Online Multiplayer Game — CI/CD (Part 8)
This is part number eight of the Garage series, you can access all parts at the end of this post.
Now we have a Kubernetes cluster and need to make a pipeline for continuous integration and continuous deployment (CI/CD).
Continuous Integration (CI)
The main branch is protected and nobody can push to it directly, thus a pull request must be created for each merge and a test job is run for it. Only the pull requests that have passed the test job are mergeable to the main branch.
When a pull request to the main branch of the game manager repository has been closed (merged), a Github action starts a job to build the docker image and publishes the artifact with the commit-hash tag to the GitHub container registry.
When a new version of the game manager is released (tagged with semantic version), a GitHub action starts a job to build the docker image and publishes the artifact with the tag to the GitHub container registry.
After publishing the image to the ghcr, an event with the artifact’s tag (commit sha hash) is dispatched from the game manager's repository to update the image version in the staging environment. On the other side, the k8s repository GitHub action receives the event and starts a job to install
kubectl and update the image of the game manager k8s deployment resource.
Same as the staging environment, after releasing the game manager package, an event is dispatched to the k8s repository. this event runs a job to install
kubectl and update the image of the game manager k8s deployment resource in the production environment.
Game Server CI/CD
The same pipeline exists for the game server but with a different event in deployment. After publishing the artifacts to the ghcr, an event is dispatched in the k8s repository to run a job to install
kubectl and update the game server image environment variable for the game manager instances.
Game Manager CI/CD action
This is the final Github action to build and deploy the game manager image:
Now we have a pipeline to automate the integration and deployment of our applications.
Our little journey has been completed. These blog series are the outcome of my afford to design a distributed system for an online multiplayer game. I’ll be appreciated your comments.
After some improvements, I’ll open-source the game server, game manager, and DevOps repositories in the future.