Google Cloud Platform – Building CI/CD Pipeline For Package Delivery
When TCS was just a prototype, bundling up their app and sharing it with the testing team was fairly simple. The coders could just email a link to the application running on their dev machines. But as the application and its development team grew, that was no longer feasible. Manually testing and deploying changes to the codebase became a bottleneck for the team. Without having a reliable, mostly automatic process to build tests and update their microservice-based application, TCS just wasn’t going to be able to scale to the level they dreamed of. So they implemented a CI/CD pipeline using Cloud Build, Google’s serverless CI/CD platform, and Spinnaker, an open-source continuous delivery platform.
TCS had to solve this packaged delivery using the CI/CD pipeline. Once they made a change to code, how would it get deployed to users in a scalable fashion?
So TCS implemented a gated, tag-based CI/CD pipeline. This allowed them to rapidly iterate and test the codebase. The high-level steps of this pipeline are as follows. A developer changes the code and pushes it to a repository. Cloud Build detects the changes, builds a Docker image, tests the image, and pushes the image to the artifact registry. Spinnaker detects that image, deploys it to a staging environment, and tests the deployment. After all, tests have passed, the release manager can manually approve the build and deploys the image to production.
Let’s look at each of these steps. First, the team was already using Git to manage its source code. As is common in game dev, they store binary assets elsewhere and pull those when a build occurs.
Using Git allows devs to check out a new branch of the codebase to do their work before merging it back to the main branch after it’s tested. This lets developers easily work with other developers and gives them a lot of flexibility in the workflow.
TCS took advantage of Git tags to create a CI/CD pipeline that kicks off whenever a new tag is pushed into the Git repository. They use Cloud Build to produce application binary and set up a trigger to watch for any commits with a Git tag prefixed with the letter “v.”In addition, to commit with a specific tag, triggers can look for commits on a branch or pull request. It then automatically starts to build and tests a new Docker image and pushes it to the artifact registry–which is a single place for your organization to manage container images and language packages.
And the final leg of reprocessing is kicked off once Spinnaker detects the new image in the artifact registry. From there, Spinnaker would deploy the image into a scaled-down staging environment for integration testing. These preliminary tests allow TCS to have the best chance at minimizing failures.
Once those tests pass, a building engineer is allowed to flip a bit and push the new image out to production where TCS’s audience can access the new feature.
Between Git, Cloud Build, artifact registry, and Spinnaker, TCS was able to develop an automatic, gated, tag-based, continuous-integration and deployment pipeline that allowed for faster iterations, more flexibility, and reliability for their containerized environment. This pipeline allowed TCS to smoothly scale up and quickly add new features as their game gained more audience and acclaim.