`gcloud app deploy` vs. `appcfg.py` [closed]

问题:

I've been a long time user of appcfg.py and I even build some bash scripts on top of it.

1. Should we switch to gcloud app deploy? Will appcfg.py be deprecated? If yes what is the timeline?

2. Why isn't there a grace period for backward compatibility of the yaml file? Switching to gcloud app deploy I get:

The [application] field is specified in file [.../app.yaml]. This field is not used by gcloud and must be removed. Project name should instead be specified either by gcloud config set project MY_PROJECT or by setting the --project flag on individual command executions.

and

ERROR: The [version] field is specified in file [.../app.yaml]. This field is not used by gcloud and must be removed. Versions are generated automatically by default but can also be manually specified by setting the --version flag on individual command executions.

I am saying this as this was possible w/ the module/service field:

WARNING: The "module" parameter in application .yaml files is deprecated. Please use the "service" parameter instead.

3. How do you upload queue.yaml, dispatch.yaml and cron.yaml with gcloud app deploy?

4. What are the differences between the 2 ways of deploying an app?

   I'm interested in caveats & things to watch for like:

FLAGS --promote Promote the deployed version to receive all traffic. True by default.

That means w/ gcloud app deploy the app will be deployed and the new version will be set as the active one... this is exactly the reverse way appcfg.py did things as there you would have to call set_default_version to mark a version as active.

This raises my last question: if I opt to NOT make it active by using either

$ gcloud config set app/promote_by_default false

or

Use --no-promote to disable.

will I have to redeploy w/ default value so I can make it active?

回答1:

Long story short:

1. gcloud app deploy is going to be the preferred path for deployments going forward, and is currently supported. You'll have about a year after we declare deprecation to transition.
2. Before we deprecate appcfg.py, we'll have a full migration guide with all of the changes. We don't want full backwards compatibility, because we're seizing this chance to fix some warts with the old tooling.
3. You can run gcloud app deploy cron.yaml and so on to deploy the alternate YAML files.
4. Again, we're planning on writing a migration guide before we want to force you over to the new tooling.

So I think you can punt on this until we've officially deprecated the appcfg tooling–gcloud app is really meant for brave explorers who want the newest and shiniest for now.