Restful 版本控制 - 如何在版本控制中进行版本控制以及如何部署？答案

【问题标题】：Restful Versioning - How to version in Version Control and how to Deploy?Restful 版本控制 - 如何在版本控制中进行版本控制以及如何部署？
【发布时间】：2014-10-29 02:19:31
【问题描述】：

如果我要在 .NET 中创建版本化的 RESTful API（我的版本化方式并不重要，但为了争论，可以说我正在做 api/v1/users）-我'我对人们如何处理版本控制和代码方面的问题感兴趣。在我的情况下，它是一个私有 API，但它会被 iOS 应用程序使用，所以我不能保证所有客户端都会同时升级，所以我必须让旧 API 运行一段时间。

假设我决定对用户返回的数据进行重大更改，因此我创建了一个 v2 的 api - 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，经常发布的版本将是分支

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

后者要简单得多处理，因为在任何时候都只有一个项目可以部署到前端。然而，这让我感觉很乱，而且超出了代码版本控制的核心价值。

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

谢谢大家

【问题讨论】：

你检查过nvie.com/posts/a-successful-git-branching-model 吗？也许这可以为您的问题提供不同的想法。我个人不喜欢从分支交付，而是让 Jenkins 为任何非主分支构建，他们将一些东西推广到生产中。希望这能有所帮助。
感谢 Lovato 的评论，它有帮助 :) 我对类似问题的唯一问题是 Jenkins 如何知道它是哪个版本以及它的去向 - 即，如果我发布 v3 但仅在主干上，詹金斯不知道它应该在 /v3/ 下 - 如果我在一个分支下做，至少我可以告诉詹金斯每个分支的含义。我不知道：/
也许您可以尝试赋予版本控制意义，例如 1.2.3.4。 Twitter 做到了这一点，并启发了我。 Twitter API 是 1.1。时期。但在内部，它可能是 1.1.244，这意味着它自发布以来的修订版 244（也可以使用来自 jenkins 的 build_version）。然后，您可以在预构建步骤中在 Jenkins 上解析您的产品版本。如果您使用 gitlab/github 和 WebHooks，它会发送一个有效负载，其中包含有关推送内容的所有详细信息，因此您可以检查您想要的分支，做任何您想做的事情，构建和部署。
也就是说，你得到了更改的分支，获取当前版本，增加最后一位，提交回来（注意不要再次触发 jenkins）并正确部署它。
如果你看看这个帖子会很好：stackoverflow.com/questions/972226/how-to-version-rest-uris

标签： c# git rest jenkins versioning

【解决方案1】：

在我看来你有两个选择：

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

【讨论】：