Analogue's Blog


Continuous Deployment with Google App Engine and CircleCI

08 Oct 2015

I love CircleCI for its speed and parallelization of containers, allowing us to split our test suite in as many containers as we want, effectively reducing our test suite runtime, and I love Google App Engine for its low cost and high constraints, making it ideal to host little tools for our team.

The problem is that they don’t like each other that much, especially if you are a fan of Continuous Deployement. The only official way to do CD to GAE on CCI is to put your Google user login and password. Perfect if you want your teammates to be able to check your emails. No, seriously, this solution is insane.

As I could not find any working satisfactory solution, I made my own, and I hope it will help others in their quest to automate everything.

Here’s a working circle.yml that you can use to enable CD on CCI and GAE:

    version: 2.7
    # Set to your App Engine project name
    GCLOUD_PROJECT: "qa-history"

    # Create a service account in the credentials page of your App Engine
    # project and save the given key pair json file as .gcloud-key-file.json
    GCLOUD_KEY_FILE: ".gcloud-key-file.json"

    # Set it to the version of the application that is running in production
    GCLOUD_VERSION: "stable"

    - ~/google-cloud-sdk
    - if [ ! -d ~/google-cloud-sdk ]; then curl | bash; fi:
    - ~/google-cloud-sdk/bin/gcloud --quiet components update app
    - ~/google-cloud-sdk/bin/gcloud auth activate-service-account --key-file $GCLOUD_KEY_FILE
    - ~/google-cloud-sdk/bin/gcloud config set project $GCLOUD_PROJECT
    - pip install flake8

    - flake8:
          - "**/*.py"

    branch: master
      - ~/google-cloud-sdk/bin/gcloud --quiet preview app deploy app.yaml --version $GCLOUD_VERSION --promote

The actual tests under the test section are just checking the syntax of some python files, for the sake of putting something easy to understand (and useful ;) ).

The only things you need to modify are the top environment variables, along with the service account key file which you can generate in your cloud console.

You still need to store your service account key file in your git repository, but you could also set an env var and dump it into a file when CI happens. I find it more cryptic and cumbersome, and not more secure as someone with repo access can create a branch to dump the env var anyway.

The service account is way less problematic to share than my Google username and password, as it only has access to the application it was generated for.

Hope it helps someone!