Building a CI/CD pipeline for a Google App Engine site using CircleCI
In this article, we will build a CI/CD pipeline for a Google App Engine Site using CircleCI.
Prerequisite
- Python installed on your system
- Google Cloud CLI installed
What we are building
- Documentation site and connect it to GCP (Google Cloud Platform)
- Using CircleCI for automation
What is CircleCI?
CircleCI is a popular choice for software engineers, particularly DevOps engineers when working on automation and overall CI/CD integrations. The CI/CD platform helps software teams automate the process of building, testing, and deploying code. As a cloud-based platform, CircleCI allows you to seamlessly integrate with any version control system you choose, such as GitHub, Bitbucket, or GitLab. However, we will be working with GitHub on this article.
One cool thing about CircleCI is that it lets developers define pipelines that automate the process of building, testing, and deploying code. Pipelines are composed of jobs, which are individual steps in the CI/CD process. Jobs can be configured to run on various platforms, including Linux, macOS, and Windows.
Why Circle CI?
CircleCI is a friendly tool for teams of all sizes, ranging from small startups to large enterprises. No wonder the tool is usually “top of the ladder” during CI/CD integrations. It is a powerful tool that can help teams improve the quality and speed of their software development process.
- Improved code quality: CircleCI can help enhance code quality by automating the testing process.
- Reduced deployment time: CircleCI can help reduce the time it takes to deploy code by automating the process of building and deploying.
- Increased confidence in releases: CircleCI can help increase confidence in releases by ensuring that code is thoroughly tested before deployment.
- Improved team communication: CircleCI can help to improve team communication by providing a central location for monitoring the progress of builds and tests.
Relevant CircleCI features
Some of the core features of CircleCI include:
- Parallelism: Jobs can be run in parallel to improve the speed of the CI/CD process.
- Caching: CircleCI can cache build artifacts and test results to improve the speed of subsequent builds.
- Notifications: CircleCI can notify team members when builds fail or pass.
- Monitoring: CircleCI provides a dashboard that allows teams to monitor the progress of their builds and tests.
Getting started
To get started, we first need to create a free GitHub repo (I assume you already know how to do that). The next step is to clone the empty repo. After this, let’s create a Python virtual environment by running the following command on your terminal:
pipenv shell
This is what it should look like after a successful installation:
Next is to run the command:
pip install sphinx
Sphinx is a popular documentation generator written in Python that is widely used for creating high-quality documentation for Python projects. It is known for its ease of use, comprehensive features, and extensive support for various output formats.
The next step is to get a Sphinx quick start. To do this, head over to the get started section of Sphinx’s official site and run this command:
sphinx-quickstart
Once you run the command, you get asked a series of questions, exactly the ones in the image below:
Respond to these questions until the whole process is complete.
This whole process creates a build and source directory. We are also going to install Sphinx make files by running this command:
make html
After running the command, your project should look like this in your code editor:
Within the build
directory, we have our website files, which look this:
📦build
┣ 📂doctrees
┃ ┣ 📜environment.pickle
┃ ┗ 📜index.doctree
┗ 📂html
┃ ┣ 📂_sources
┃ ┃ ┗ 📜index.rst.txt
┃ ┣ 📂_static
┃ ┃ ┣ 📜alabaster.css
┃ ┃ ┣ 📜basic.css
┃ ┃ ┣ 📜custom.css
┃ ┃ ┣ 📜doctools.js
┃ ┃ ┣ 📜documentation_options.js
┃ ┃ ┣ 📜file.png
┃ ┃ ┣ 📜language_data.js
┃ ┃ ┣ 📜minus.png
┃ ┃ ┣ 📜plus.png
┃ ┃ ┣ 📜pygments.css
┃ ┃ ┣ 📜searchtools.js
┃ ┃ ┗ 📜sphinx_highlight.js
┃ ┣ 📜.buildinfo
┃ ┣ 📜genindex.html
┃ ┣ 📜index.html
┃ ┣ 📜objects.inv
┃ ┣ 📜search.html
┃ ┗ 📜searchindex.js
When we run our project on localhost:8000
, this is what it looks like on the browser:
Congratulations, we have our documentation site live!
Creating a GCP project
In this section, we will create a brand new GCP project to figure out which settings need to be tweaked or updated from the base. The next thing is to create our app engine app.yaml
. Google provides a walkthrough on how to host a static website using GAE. Here, we can copy this YAML file:
runtime: python27
api_version: 1
threadsafe: true
handlers:
- url: /
static_files: www/index.html
upload: www/index.html
- url: /(.*)
static_files: www/1
upload: www/(.*)
Create an app.yaml
file on your editor and paste this code. We then have to edit the YAML file to point it to the proper location where the website files live. To point your Gcloud command line install to this project, use this command:
gcloud init --project=<"project ID">
Here, you will prompted to log in to Google Cloud like this:
Follow the link provided to get your authorization code.
On the GCP dashboard, navigate to “App Engine” and run the command shown there on your terminal:
glcloud app deploy
You will get a prompt asking you to choose the location you would like your app to be deployed:
Choose anyone! and your app will successfully deploy. It’s time to push our code to Github! Alternatively, you can clone my GitHub repo here.
Link Github repo to CircleCI
The first thing you need to do is create a CircleCI account and link your Github to it. The process is pretty straightforward. Our dashboard should look like this after creating and connecting our project to CircleCI.
Next, in our code editor, we will create a folder named .circleci
and a config.yaml
file inside it which contains a code that works like this: first, it defines a workflow, then, the workflow will say; each time we push to the main branch, run this set of jobs. We will also define that job, which will contain the logic of where we build our documentation site and deploy it to the Google App engine.
workflows:
version: 2
build_and_deploy:
jobs:
- build_and_deploy:
filters:
branches:
only:
- main
CircleCI will only run this workflow when we push to the main branch. Now, to define the job:
jobs:
build_and_deploy:
docker:
- image: busybox
steps:
- run:
name: hello world
command: |
echo "Hello world"
You can check our formatting with CircleCI. To do this, first install CircleCI CLI and run this command:
circleci config validate
Response:
In our CircleCI, you can see the tests, processes, and workflows whenever we push to the main branch on GitHub:
Awesome! We have successfully created a CI/CD pipeline. Now, whenever we make changes to our code base or documentation, we can just push to the main, and CircleCI will pick up that change (as demonstrated in the image above) and the job or workflow and make deployments a few minutes later.
Conclusion
This article provided a step-by-step guide on building a CI/CD pipeline for a Google App Engine site using CircleCI. We covered setting up a Python environment, using Sphinx for documentation, and integrating the project with Google Cloud Platform.
The process demonstrated the benefits of automating deployments via CircleCI, including enhanced code quality, reduced deployment time, and improved team communication. This guide highlights the efficiency and effectiveness of CircleCI in streamlining development processes, making it an invaluable tool for modern software development teams.
Aviator: Automate your cumbersome processes
Aviator automates tedious developer workflows by managing git Pull Requests (PRs) and continuous integration test (CI) runs to help your team avoid broken builds, streamline cumbersome merge processes, manage cross-PR dependencies, and handle flaky tests while maintaining their security compliance.
There are 4 key components to Aviator:
- MergeQueue – an automated queue that manages the merging workflow for your GitHub repository to help protect important branches from broken builds. The Aviator bot uses GitHub Labels to identify Pull Requests (PRs) that are ready to be merged, validates CI checks, processes semantic conflicts, and merges the PRs automatically.
- ChangeSets – workflows to synchronize validating and merging multiple PRs within the same repository or multiple repositories. Useful when your team often sees groups of related PRs that need to be merged together, or otherwise treated as a single broader unit of change.
- TestDeck – a tool to automatically detect, take action on, and process results from flaky tests in your CI infrastructure.
- Stacked PRs CLI – a command line tool that helps developers manage cross-PR dependencies. This tool also automates syncing and merging of stacked PRs. Useful when your team wants to promote a culture of smaller, incremental PRs instead of large changes, or when your workflows involve keeping multiple, dependent PRs in sync.