Modern Frontend CI/CD Architecture — The Missing Guide (Part. 1): The CI.
When building modern frontend Web applications involving large teams and a “gitflow” branching model (or a similar workflow), being able to preview the changes introduced by a particular Pull Request before merging them is a great asset and can be a good productivity boost. For this, you will need to set up a complete CI/CD — a Continuous Integration and a Continuous Deployment — pipeline.
In this post, we’re going to tackle this challenge and set up a complete CI/CD using:
- GitHub as our main source repository;
- Google Cloud Build as our CI pipeline;
- Kubernetes as our CD pipeline.
We structured this article into three separate sub-articles:
- The 1st part will be dedicated to setting up the CI pipeline;
- The 2nd part will address the CD pipeline;
- The 3rd part will add some extra feature to our CI/CD pipeline;
Make also sure to edit the Cloud Build service account which looks like PROJECT_ID@cloudbuild.gserviceaccount.com, then add the Kubernetes Engine Admin role so you can run the
kubectl command from the Cloud Build steps:
And here is the Kubernetes Engine Admin role that needs to be added:
This should be all for the GCP part. Let’s configure the GitHub project.
Next, create your GitHub project or use an existing one and add the Google Cloud Build GitHub app:
That’s it! Your GitHub project is now using the Google Cloud Build as a CI pipeline. Let’s now configure that CI pipeline for our project.
Google Cloud Build as our CI pipeline
In order to build and test our code using the Cloud Build CI, we will create a cloudbuild.yaml configuration file at the root of our GitHub project containing the following steps:
What this file does is describe all the build steps that the Cloud Build will run on each opened PR on GitHub. It will (in order):
- Install the NPM dependencies using the
- Test the project using the
npm run test:cicommand;
- Build the project using the
npm run build -- --output-path dist/htmlcommand.
You can add other steps depending on your needs.
In addition to testing and building our project, we will also build and push—on the fly—two new containers that we will use in the CD part (read the next part):
- A first container labeled with the current commit SHA ($SHORT_SHA);
- A second container labeled with the tag
latest, which will always point the “latest” artifact built by our CI.
These containers are built using this minimalistic Dockerfile available at the root of our project:
We are basically running a simplistic nginx server that will serve the content of our app. Also, we are giving it a custom nginx.conf file (see below) and copying the output build to the nginx default html root (in the container):
So with this, we have a working CI that tests, builds and stores snapshots of each execution:
And that's it for the CI part! Here is what we have accomplished so far…
To read more about the CD pipeline, head over to the part 2 of this article.
Follow @manekinekko for more updates about Web and Cloud technologies.