How to use GAE's dispatch.yaml with multiple development environments?

Question

I am trying to understand the dispatch.yaml file for Google App Engine.

We have a vanilla web app with a frontend and a backend. We also have a development and a production environment. Both environments have two services on GAE - frontend and default, which is the backend.

We have a vanilla web app with a frontend and a backend. We also have a development and a production environment. We have two services on GAE - frontend and default, which is the backend. We have two projects on GAE - staging, which is our dev environment, and production, which is our production environment. The staging environment is built from our dev branch in both our frontend and backend. The production environment is built from our master in both our frontend and backend.

We want to use custom routes for both the staging and production environments.

I have tried using dispatch_staging.yaml and dispatch_prod.yaml to differentiate the files but GAE won't recognize those file names. I guess we could rename the frontend service but it looks like there is no way getting around default.

How do you use dispatch.yaml to specify the environment being built?

Wickerwork

Why use different filenames if you already have different branches? – Radiomicrometer

Answer 1

The way I approached this problem is by using different repo branches for the application code.

• the master branch version is deployed to my_app-dev - the development environment app
• the production branch version is deployed to my_app - the production environment app

This way the file is always named dispatch.yaml. The service names don't change between environments, but the custom domain names associated to them do - and that's reflected in the content of the dispatch.yaml file in the 2 branches:

$ git diff production master -- dispatch.yaml
diff --git a/dispatch.yaml b/dispatch.yaml
index 0768a6a..c1326cf 100644
--- a/dispatch.yaml
+++ b/dispatch.yaml
@@ -1,14 +1,14 @@
-application: my_app
+application: my_app-dev
 dispatch:
-  - url: "service1.my_app.com/*"
+  - url: "service1-dev.my_app.com/*"
     module: service1
-  - url: "service1-dot-my_app.appspot.com/*"
+  - url: "service1-dot-my_app-dev.appspot.com/*"
     module: service1
   - url: "*/service1/*"
     module: service1
-  - url: "service2.my_app.com/*"
+  - url: "service2-dev.my_app.com/*"
     module: service2
-  - url: "service2-dot-my_app.appspot.com/*"
+  - url: "service2-dot-my_app-dev.appspot.com/*"
     module: service2

Note: I'm implementing the different environments at the app level (as opposed to the service level, see Advantages of implementing CI/CD environments at GAE project/app level vs service/module level?). A service-level implementation cannot use this approach.

Radiomicrometer

Thanks, I see how you're doing it, Dan. Your setup is very similar to ours. We have the two environments in different projects. To confirm, you never merge the dispatch.yaml from dev to master? That makes sense, except, how do you remember to omit that from your merges every time? Apologies for what may be obvious - I'm a noob – Wickerwork

Ignore that, Dan. I just learned about git attributes. Thanks for the answer :) – Wickerwork

After the initial merge the file appears in the branch merge only if it was changed in the parent branch. Otherwise it doesn't. – Radiomicrometer

Answer 2

I know this is an old question, but I just discovered something interesting that will help everyone wanting to deploy to different environments. After a lot of trial and error, I figured out that gcloud requires the dispatch file given as parameter to be called dispatch.yaml. If you call it anything else, like dispatch-staging.yaml or dev-dispatch.yaml it won't work. However, and this is the trick I found, the file doesn't have to be in your project's root folder. So, in our project I did this:

1. <project_root>/dispatch.yaml - for production
2. <project_root>/deploy-staging/dispatch.yaml - for staging

And now I can do cd <project_root> and then:

1. gcloud --project <production> app deploy ./dispatch.yaml
2. gcloud --project <staging> app deploy ./deploy-staging/dispatch.yaml

In other words, gcloud doesn't care in what directory the dispatch.yaml file is located as long as it is called dispatch.yaml.

Asylum

As of 2021 at time of writing, I discourage from sticking dispatch.yaml in a env-named directory, as the commands stated above will not pick any changes in any of the source directories that are sitting under the app root. It will just update what it calls "routing_rules", and display something like this: Waiting for operation [apps/<project_id>/operations/<uuid>] to complete...done. Updating config [dispatch]...done.. You can verify that no deployment was made by checking the "Last version deployed" timestamp on App Engine Services tab. – Tarratarradiddle

Answer 3

I also had the same problem as you and I come to offer you a 3rd solution. If you have several development environments, you may have an automatic deployment (for my part, with Gitlab-CI). I proceed as follows during my deployment internship, I copy (or rename) the dispatch file:

• Testing: ./gcp.dispatch.testing.yml => ./dispatch.yml
• Production: ./gcp.dispatch.production.yml => ./dispatch.yml

Here is an example of a stage from my gitlab-ci.yml file (for testing):

testing__deploy__gcp_dispatch:
  stage: dispatch
  image: google/cloud-sdk:alpine
  script:
    - cd ${CI_PROJECT_DIR}
    - gcloud auth activate-service-account --key-file ${GCP_SERVICE_KEY_FILE}
    - cp ./gcp.dispatch.testing.yml ./dispatch.yml
    - gcloud --quiet --project ${GCP_PROJECT_ID} app deploy ./dispatch.yml

There you go !

PS: I understood that after, where the error Unexpected attribute 'dispatch' for object of type AppInfoExternal. came from. gcloud does not accept that the file is named differently than dispatch.yml...

Compete