如何处理 Web 服务和后端/基础结构源代码版本控制

本文关键字：后端 结构 版本控制 源代码 服务 何处理 处理 Web | 更新日期: 2023-09-27 18:21:00

我的解决方案中有一个">类库"，我的">WebService"正在使用它。此网络服务由外部站点客户端使用。(我现在的解决方案下有 2 个项目(

最近，类库有一些增强功能。我想在这个库上实现版本控制(不太确定如何做。

假设我当前的">类库 v1"应该仍然处于活动状态，因为我们的一些使用">Web 服务"的客户端仍然需要">类库 v1"实现。但是对于少数新客户端，我的">Web 服务"应该实现">类库 v2"逻辑。

我开始复制我的"类库 v1"，并在我的解决方案">类库 v2"中创建新项目，并根据请求源在我的">Web 服务"项目中处理它。(我现在的解决方案下有 3 个项目(

出于某种原因，我觉得这是非常业余的实现方式。任何人都可以指导我以正确的方式对库进行版本控制并适当地调用它们。

如何处理 Web 服务和后端/基础结构源代码版本控制

通常这是使用版本控制分支实现的。

    有一个 main 分支表示最新的

  • 代码(以及独立于产品版本或里程碑发展的分支(。

  • 如果要发布新版本或修订，第一步是使用版本标记标记源代码管理版本项。例如："我的产品 2.2"。

    • 此外，如果整个产品版本或修订版

  • 将与较新版本并行维护，则需要创建一个版本/修订分支，以便在那里实施特定的补丁、修复或功能，而不会影响更新版本或旧版本。如果要在不同的分支中共享功能，则需要合并整个 changset。这样做的主要问题是，有时旧版本中的代码库不支持合并，但您需要为特定版本再次开发修复程序......

    • 子，子子，子子分支

  • 可能会发生。例如，您可能有 2.x 分支，以及 2.1.x、2.2.x 的子分支...这完全取决于您如何处理版本控制和产品发布。

  • 每个分支都是不同的Visual Studio解决方案。不应在同一解决方案中混合使用附属库。使用特定的代码文件版本在自己的解决方案中单独管理它们。

归根结底，所有代码分支都位于单独的源代码管理存储库中，并且分别开发每个版本，然后合并更改(或实现特定版本的更改(。

现在，您需要选择一个源代码管理提供程序。您有很多选择：

  • GIT(我找到了本指南，它可能是您在 GIT 上的良好开端(
  • 善变。
  • 颠覆(太旧了(。
  • 别人。。。

源代码管理提供程序的比较超出了本问答的范围，它非常注重意见，这不符合 StackOverflow 约定，但由您来查看其中的一些甚至找出其他约定！

关于网络服务

在为向使用者公开多个版本的 Web 服务提供服务方面，您可能需要考虑基本 URI 包含 Web 服务版本的 URI 方案：

  • /api/v1/resourceA
  • /api/v2/resourceA
  • /api/v2.2/resourceA
  • 。

根据一些OP的评论进行更新

[...]我更想知道你回答的最后一部分你在哪里 Web 服务 API 的示例 URL。假设我保持不同的结局 所有客户端的 V1、V2 和 V2 等点，现在我的困惑是 当请求来自 v1 URL 和 V2 URL 时，我应该调用我的单曲 类库或两个不同的类库。

正如我在上面的回答中指出的那样，您需要单独维护解决方案的每个版本，并且需要将每个版本部署为不同的 IIS 应用程序。

也许您需要稍微学习一下 WebDeploy，以便更轻松地部署解决方案。

如果您采用一种解决方案和 v1、v2、v3 类库方法，您将来会遇到很多问题，因为您将修改一些在最新版本中工作的代码，这些代码在以前的版本中可能不起作用。

想象一下，您的 v1 API 适用于 .NET 3.5，v2 适用于 .NET 4.x 和 v3 .NET vNext (5？(。您将无法将 Web 服务解决方案构建/编译为单个应用程序，该应用程序可以在同一 IIS 应用程序中使用多个 .NET CLR(*这是可能的问题之一，我们可以继续下一个问题;P！

相关文章：