azure - 在 CI/CD 过程中管理 csproj 文件

Question

我有一个 ASP.NET Web 表单应用程序。实现持续集成/部署流程:

TFS

• 开发分支
• 主分支

Azure:应用服务

• 开发槽
• 暂存槽
• 产品

生命周期是:

1. 开发者添加一些功能并提交到Dev分支==>提交将自动部署到Dev slot
2. 请求者或客户查看、测试和验证修改
3. 如果没问题==>开发人员将他的变更集合并到主分支
4. 当变更集合并成功时，将会是==>
   • 部署到暂存槽
   • 在暂存槽中测试一些重要的网址
   • 如果可以==>交换暂存和生产槽位

最后，我们将获得应用程序的版本:

1. 开发槽中的版本 N+1
2. 暂存槽中的版本 N-1
3. 生产中的版本 N

这个过程运行良好。由于 csproj 文件的原因，有些文件没有

示例:

• 开发者添加子网站 A 和 B
• 网站 B 已得到客户验证，但网站 A 未经过验证
• 当站点 B 的变更集合并到 master 分支时，csproj 文件将包含 A 和 B 页面引用
• 因此我们在 master 中会出现编译错误，因为站点 A 的页面在 csproj 中提到，但在该 master 分支中并不存在!

所以我需要知道如何解决这个问题？

谢谢

Answer 1

您有一个持续集成的开发分支。在部署时，您会发现自己会问这样的问题:“我如何交付分支中现有内容的子集？”此时，您正在尝试从本质上取消合并。你永远不想“取消合并”。

相反，请考虑采用功能切换模式。这是一项以开发人员为中心的事件，而不是分支/合并事件。您的开发人员将任何新功能包装在可以有条件启用或禁用的切换​​开关后面。如果站点 B 已获准部署，而站点 A 未获批准，那也没关系 - 在禁用站点 A 的功能切换的情况下进行部署。它仍然在代码中，但您的最终用户无法访问它。

另一种可能性是采用硬依赖较少的微服务架构。相反，您的应用程序由许多较小的、独立版本化和部署的服务组成。当然，这最终可能也会涉及功能切换。

以上两个想法来自现代应用程序设计的地方。回到旧的思维方式:如果您需要“取消合并”，则意味着您合并得太早了。您可能需要独立维护多个开发分支和 QA 功能，只有在更改获得批准后才将它们合并在一起。当然，这需要更长的 QA 周期，因为您必须在合并后对这两个功能进行第二次 QA。