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

时间:2018-04-23 23:01:36

标签: azure tfs webforms continuous-integration azure-devops

我有一个asp.net Web表单应用程序。实施持续集成/部署过程:

TFS

  • Dev branch
  • Master branch

Azure:应用服务

  • Dev Slot
  • 分段插槽
  • PROD

生命周期是:

  1. 开发人员添加一些功能并将其提交给Dev branch ==>提交将自动部署到Dev slot
  2. 请求者或客户端查看,测试和验证修改
  3. 如果是,则==>开发人员将他的变更集合并到主分支
  4. 当变更集合并成功时,它将是==>
    • 部署到临时插槽
    • 在分段插槽中测试一些重要的Url
    • 如果可以==>交换舞台和制作插槽
  5. 所以最后,我们将有应用程序的版本:

    1. 开发槽中的版本N + 1
    2. 分段插槽中的版本N-1
    3. 制作中的版本N
    4. 此过程正常。由于csproj文件,在某些文件中它没有

      示例:

      • 开发人员添加子网站A和B
      • 网站B由客户验证,但网站A没有
      • 当站点B的变更集合并到主分支时,csproj文件将包含A和B页面引用
      • 所以我们在master中会有一个编译错误,因为在csproj中提到了站点A的页面,但是在这个主分支中它不存在!

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

      谢谢,

1 个答案:

答案 0 :(得分:3)

您有一个持续集成的开发分支。在部署方面,你会发现自己在问这个问题,"我如何提供目前分支机构中的一部分?"此时,您正在尝试基本上不合并。你永远不想" unmerge"。

相反,请考虑采用功能切换模式。这是以开发人员为中心的活动,而不是分支/合并活动。您的开发人员将任何新功能包装在可以有条件地启用或禁用的切换​​后面。如果站点B被批准部署且站点A不是,那就很好 - 部署了站点A的功能切换功能已禁用。它仍在代码中,但您的最终用户无法访问它。

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

以上两个想法来自现代应用设计的地方。回到过去的思维方式:如果你需要" unmerge",这意味着你过早地合并。您可能需要独立维护多个开发分支和QA功能,只有在批准更改后才将它们合并在一起。当然,这需要更长的QA周期,因为在合并之后,您必须第二次QA这两个功能。