Modern Frontend CI/CD Architecture — The Missing Guide (Part. 1): The CI.

tl;dr: The complete diagram of the Frontend CI/CD architecture pipeline.

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:

1. GitHub as our main source repository;
2. Google Cloud Build as our CI pipeline;
3. Kubernetes as our CD pipeline.

We structured this article into three separate sub-articles:

1. The 1st part will be dedicated to setting up the CI pipeline;
2. The 2nd part will address the CD pipeline;
3. The 3rd part will add some extra feature to our CI/CD pipeline;

GCP setup

First things first, create a new project (or use an existing one) in GCP. We are going to use xLayers.app as our example project.

Then, you need to enable both the Kubernetes Engine API and Cloud Build API:

The Cloud Build API

The Kubernetes Engine API

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:

Editing the PROJECT_ID@cloudbuild.gserviceaccount.com service account

And here is the Kubernetes Engine Admin role that needs to be added:

Adding the Kubernetes Engine Admin role

This should be all for the GCP part. Let’s configure the GitHub project.

GitHub setup

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):

1. Install the NPM dependencies using the npm install command;
2. Test the project using thenpm run test:ci command;
3. Build the project using the npm run build -- --output-path dist/html command.

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):

1. A first container labeled with the current commit SHA ($SHORT_SHA);
2. 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…

The Continuous Integration pipeline.

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.