Deployment TFS内部网自动部署策略

Deployment TFS内部网自动部署策略,deployment,version-control,tfs,intranet,Deployment,Version Control,Tfs,Intranet,我已经向我的团队介绍了分支/合并,并在前面讨论了自动构建和部署签入登台/主分支的代码是多么的棒,但是我是一名初级开发人员,不太擅长ops-y 我遇到的问题是,我们创建了内部网应用程序,并将它们存储在我们自己的虚拟机上,我们可以访问这些虚拟机,但我们也有负载平衡,这让我很伤心 我可以让构建自动化(我还没有弄清楚所有的bug,但我正在努力解决它们)——我甚至可以让构建自动创建一个zip文件,为部署做好准备。 是否可以为部署配置多个服务器? 即 也许值得注意的是,我们目前有运行VisualStudio

我已经向我的团队介绍了分支/合并,并在前面讨论了自动构建和部署签入登台/主分支的代码是多么的棒,但是我是一名初级开发人员,不太擅长ops-y

我遇到的问题是,我们创建了内部网应用程序,并将它们存储在我们自己的虚拟机上,我们可以访问这些虚拟机,但我们也有负载平衡,这让我很伤心

我可以让构建自动化(我还没有弄清楚所有的bug,但我正在努力解决它们)——我甚至可以让构建自动创建一个zip文件,为部署做好准备。 是否可以为部署配置多个服务器? 即

也许值得注意的是,我们目前有运行VisualStudio的TFS服务器,因此代码构建在存储所有代码的同一台服务器上,但这不是我们运行实时代码的服务器


非常感谢任何针对我的设置的帮助或教程,我真的很想扭转这一局面

我将只讨论部署方面。有很多不同的方法可以处理这一问题,例如:

  • 自定义生成模板
  • 编写自定义.Net代码并将其插入到生成模板中(这还需要自定义模板)
  • 创建批处理或Powershell脚本集以在生成完成后运行
  • 使用单独的工具(如OctoDeploy或Release Manager)来处理部署
  • 您需要做的第一件事是在头脑中分离构建和部署步骤。虽然它们在您的模型中紧密耦合,但它们是两个完全不同的任务,需要以不同的方式处理
    第二件事是在部署部分不要像开发人员那样思考。虽然可能会有一个编程解决方案,但您需要首先确定手动步骤
    你说你不太会操作,我想你的意思是你更喜欢开发人员而不是系统分析师。如果是这样的话,那么你需要做的第三件事就是找一个参与其中的人,比如你当前的发布团队

    接下来需要做三件大事:

  • 一切都需要标准化。如果你不能标准化一些东西,那么就标准化那些非标准的东西(例如:您有一个需要部署到的服务器的大容量列表,您需要根据它们的名称确定要部署到哪些服务器,这些名称可以是任何内容。在这种情况下,需要制定一条规则,所有QA服务器的名称中都需要QA,用户验收服务器需要UAT,生产需要PROD,等等)
  • 弄清楚您将如何从构建到部署进行通信,将要部署哪些构建,将要部署到哪些服务器,以及从何处获取代码
  • 您需要记录每个手动步骤、这些步骤的每个异常以及这些异常的每个异常
  • 一旦所有这些步骤就绪,您就需要完成每个手动步骤并将其自动化,无论是通过批处理、Powershell还是定制应用程序。一旦所有步骤都自动化,您就可以完成构建和部署部分。
    在您能够在单个环境中执行单个“手动”自动部署之后,您就可以了解如何在多个环境中运行它了。这可能像一个XML文件被迭代一样复杂,只需使用不同的参数多次调用同一命令

    快速总结我在当前工作中是如何做到这一点的(使用第三方部署工具是不可取的):

  • 使用.Net WinForms创建了一个工具,允许我们“手动”运行自动生成(我们使用接口来确定输入参数,后台的自定义类完成所有繁重的工作。这些自定义类位于一个单独的项目中,构建到它们自己的dll。这还允许我们在测试环境中测试流程的调整和更改,然后再将其推出到生产构建服务器)
  • 为每组环境(QA、UAT、Prod等)设置一个XML文件,其中包含需要在该环境中部署的所有服务器,包括目标路径、计划任务和Windows服务
  • 自定义TFS构建模板并包含为自定义工具创建的自定义类,该工具将读取XML文件并遍历每个服务器条目以执行部署

  • 我非常乐意提供更具体的示例和帮助,我的观点与大多数人有点不同,在发布管理方面也很有帮助。

    感谢所有这一切-很遗憾TFS不能提供一个非常简单的“这里有一些直接的文件路径可供部署”,但我想它不是为intranet构建的这么多。我们目前有4个主要业务部门,都有自己的QA/UAT/生产(主要业务部门有3个生产用于负载平衡)。如果我能让TFS自动化构建,(即开发人员合并到QA)-是否没有“自动”/“一键式”方法可以轻松地将这些更改发布到所有QA服务器上?实际上,考虑一下,允许使用“一键式”方法控制哪些服务器可能更可取……我相信较新版本(2013年以上)具有更好的部署管理(我最熟悉2010年).由于所有环境都不同,很难有现成的简单工具。有第三方工具(好吧,现在发布管理是第一方)这可以用来扩展TFS功能,使部署更加容易,没有TFS,这有点棘手,需要自定义代码或脚本。您可以查看ClickOnce发布,这可能可以满足您的需要,但它有自己的时髦限制,我从未尝试过实际构建。
    1) I check in some code to stage
    ***Automatically***
    2) Code builds
    3) Build completes, Unit tests run and they complete
    4) Code is packaged into a .zip
    5) .Zip is deployed across the three load balancing servers (all with the same file path).
    ***