To build this facility, you will use the following services:
Source repository—GitHub
The source code is the raw materials and blueprints for building containerized services. As you would expect, these are stored in a source code repository. Google Cloud has its own source code repository, Google Source Repositories, which is Git-based. But for many people, GitHub will be the first choice. Fortunately, there are mechanisms for connecting to other Git providers in the Google Cloud ecosystem.
These include mirroring the GitHub repositories in Google Source Repositories, but you can also connect the build pipeline directly to several Git service providers, including GitHub and BitBucket. These connections can only be created via the console on Cloud Build (1st gen) but can be connected programmatically with the 2nd gen. Therefore, you will be using 2nd gen.
Build automation—Cloud Build
Cloud Build is the mechanism for creating a continuous integration pipeline, the automated assembly line for building and testing containerized services to store, ready for deployment. You have come across Cloud Build before, but this time you will be automating how it is triggered rather than using Cloud Run.
Container storage—Artifact Registry
When containers are assembled, they will automatically be stored in Artifact Repository until the automated deployment is ready for them. Think of Artifact Repository as the warehouse storing the containers ready for delivery. At this point, you can also publish a message saying a new container is available.
Deployment automation—Cloud Build or Cloud Deploy
When a container is ready for deployment, you need something to pick it up and deploy it into the citadel. In this chapter you will use Cloud Build again, but for more complex deloyments Cloud Deploy is also an option. Think of it as a skilled installer with a truck delivering and installing the new washing machine.
Implementation
You are now going to use the completed SkillsMapper code that accompanies this book as an example. The code is available on GitHub at SkillsMapper Repo. If you have not already done so, you should fork the repository into your own GitHub account if you want to make any changes, but you can also use the original repository if you prefer, as it is public.
Creating the factory
The first step is to create the “factory,” and for this, you will create a separate project from the one that is used for running the applications, the “citadel.” All automation will be in a separate project from the applications themselves. Refer back to Chapter 4 if you need a reminder of how to create a project.
A suggested naming convention is to use the same name as the citadel project but with -management appended. For example, if the citadel project is skillsmapper the management project would be skillsmapper-management.
Having a separate project for management is a good idea for several reasons. It allows you to:
- Separate the billing and budgeting for the citadel and the management infrastructure.
- Give different people access to the citadel and the management infrastructure.
- Delete the management infrastructure without affecting the citadel.
- Have multiple citadels for different environments (e.g., skillsmapper-development, skillsmapper-test, skillsmapper-production) and a single management project.
For the rest of this chapter, we will assume that the management project is called skillsmapper-management and refer to it as the management project, and the citadel project is a citadel project named skillsmapper-development and refer to it as the target project.
