c# - Restful Versioning - 如何在版本控制中进行版本控制以及如何部署？

Question

如果我要在 .NET 中创建一个版本化的 RESTful API(这对我进行版本控制的方式无关紧要，但为了争论起见，假设我正在做 api/v1/users)——我我对人们如何处理版本控制和代码方面的问题很感兴趣。在我的情况下，它是一个私有(private) API，但它会被 iOS 应用程序使用，所以我不能保证所有客户端都会同时升级，所以我必须让旧 API 运行一段时间。

假设我决定对用户返回的数据进行重大更改，因此我创建了 API 的 v2 - api/v2/users。我是否在 GIT 中进行这些更改，例如，为 V2 创建一个新分支，然后在工作副本之上进行这些更改，然后分别构建每个分支并将每个分支项目部署到 v2 文件夹

喜欢:

/branchV1/user.cs -> Built by Jenkins -> Deployed to V1/user
/branchV2/user.cs -> Built by Jenkins -> Deployed to V2/user

还有 Git 分支:

MASTER ====v1========================v2==========================
            \               \          \
             \               \         BRANCH V2 =================
              BRANCH V1 ===========================================
                                            \                     /
                                             BRANCH V1 Bug Fix ===

显然，这带来了开销，因为在创建分支时必须将每个分支添加到 Jenkins，然后更新 AWS 上的 Deploy 过程以在正确的位置安装相关的 WebDeploy 包。同样在这种情况下，MASTER 将不是持续可交付的，它将是 Dev，可持续交付的版本将是 Branches

或者人们只是在项目中使用不同的版本，例如 v1/Users.cs v2/Users.cs - 具有不同的命名空间，然后处理路由到的代码。

后者处理起来多简单，因为在任何时候只有一个项目可以部署到前端。然而，这对我来说感觉很困惑，并且超出了代码版本控制的核心值(value)。

我看到很多关于 REST 版本控制的 URL 命名与 header 命名等的讨论，但没有关于人们如何在他们的代码库中实现版本控制和版本控制的讨论。

谢谢大家

Answer 1

在我看来你有两个选择:

• 分支 v1 并为 v2 创建一个单独的项目。在这种情况下，您可以复制粘贴错误修复，或者可以通过 pull 请求共享修复。
• 为 v1 和 v2 创建单独的发布分支，这样您就可以将错误修复 merge 到它们。