`gcloud app deploy` 与 `appcfg.py`

Question

我是 appcfg.py 的长期用户，我什至在其上构建了一些 bash 脚本。

1. 我们应该切换到 gcloud app deploy 吗？ appcfg.py 会被弃用吗？如果是，时间表是什么？

2. 为什么没有向后兼容yaml文件的宽限期？切换到 gcloud app deploy 我得到：

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.

和

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.

我这么说是因为在 module/service 字段中这是可能的：

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

3. 如何上传queue.yaml,dispatch.yaml和cron.yaml 与 gcloud app deploy?

4. 这两种部署应用程序的方式有什么区别？

   我对注意事项和注意事项感兴趣，例如：

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

这意味着 w/ gcloud app deploy 将部署应用程序并将新版本设置为活动版本...这完全是相反的方式 appcfg.py 做了一些事情，因为你必须调用 set_default_version 才能将版本标记为活动。

这提出了我的最后一个问题：如果我选择不使用

$ gcloud config set app/promote_by_default false

或

Use --no-promote to disable.

我是否必须使用默认值重新部署以便激活它？

Answer 1

长话短说：

1. gcloud app deploy 将成为未来部署的首选路径，目前已受支持。在我们宣布弃用到过渡后，您将有大约一年的时间。
2. 在弃用 appcfg.py 之前，我们将提供包含所有更改的完整迁移指南。我们不想要完全向后兼容，因为我们正在抓住这个机会用旧工具修复一些瑕疵。
3. 您可以 运行 gcloud app deploy cron.yaml 等来部署备用 YAML 文件。
4. 同样，我们计划在强制您使用新工具之前编写迁移指南。

因此，我认为在我们正式弃用 appcfg 工具之前，您可以对此下注——gcloud app 确实适用于现在想要最新最闪亮的勇敢探索者。