TFS Intranet 自动部署策略
TFS Intranet Automated Deploy Strategy
我已经向我的团队介绍了 branching/merging，并且之前已经讨论过自动构建和部署签入 staging/master 分支的代码是多么棒，但我是一名初级开发人员，不是很 ops-y。
我遇到的问题是，我们创建了 Intranet 应用程序并将它们存储在我们自己可以访问的 VM 上，但我们也有负载平衡，这让我很伤心！
我可以让构建自动化（好吧，我还没有找出所有的错误，但我正在努力解决它们）- 我什至可以让构建自动创建一个 zip 文件准备就绪用于部署。
是否可以配置多个服务器进行部署？
即.E
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).
***
也许值得注意的是我们目前有我们的 TFS 服务器 运行ning Visual Studio 所以代码是在同一台服务器上构建的，它全部存储，但这不是我们 运行 活码来自。
任何针对我的设置的帮助或教程都将不胜感激，我真的很想扭转这个部门的发布策略！
我将只讨论部署方面的问题。有很多不同的方法可以处理这个问题，例如：
- 自定义构建模板
- 编写自定义 .Net 代码并将其插入构建模板（这也涉及自定义模板）
- 在构建完成后创建设置为 运行 的 Batch 或 Powershell 脚本
- 使用 OctoDeploy 或 Release Manager 等单独的工具来处理部署
您需要做的第一件事是在脑海中分离构建和部署步骤。虽然它们在您的模型中紧密耦合，但它们是两个完全不同的任务，需要以不同的方式处理。
第二件事是在涉及部署部分时停止像开发人员一样思考。虽然可能会有程序化解决方案，但您需要先确定手动步骤。
你说你不是很 ops-y，我认为你的意思是你更多的是开发人员而不是系统分析师。如果是这种情况，那么您需要做的第三件事就是找人参与，例如您当前的发布团队。
接下来需要做的主要有3件事情：
- 一切都需要标准化。如果你不能标准化某些东西，那么标准化它是非标准的方式（例如：你有大量需要部署到的服务器列表，你需要根据它们的名称来确定要部署到哪些，哪个可以是任何东西。在这种情况下，需要制定一条规则，即所有 QA 服务器的名称中都需要有 QA，用户验收服务器需要 UAT，生产需要 PROD，等等）。
- 弄清楚您将如何从构建到部署进行通信，将部署哪些构建，部署到哪些服务器，以及将从何处获取代码
- 您需要记录每个手动步骤、这些步骤的每个异常，以及这些异常的每个异常。
一旦您准备好所有这些部分，您就需要完成每个手动步骤并使其自动化，无论是通过 Batch、Powershell 还是自定义构建的应用程序。将所有步骤自动化后，您将完成构建和部署部分。
在您能够对单个环境执行单个 "manual" 自动部署后，您就可以准备好如何 运行 将其部署到多个环境。这可能与迭代遍历的 XML 文件一样复杂，只需使用不同的参数多次调用相同的命令。
关于我在当前工作中如何完成此操作的快速总结（无法选择使用第三方部署工具）：
- 使用 .Net WinForms 创建了一个工具，使我们能够 "manually" 运行 自动构建（我们使用界面来确定输入参数，并在后台自定义 类完成所有繁重的工作。这些自定义 类 位于一个单独的项目中，该项目构建到它们自己的 dll。这也允许我们在将其推出到我们的生产构建之前在测试环境中测试对流程的调整和更改服务器）
- 为每组环境（QA、UAT、Prod 等）设置一个 XML 文件，其中包含需要部署到该环境中的所有服务器，包括目标路径、预定任务和 Windows 服务
- 自定义 TFS 构建模板并包含为自定义工具创建的自定义 类，它将读取 XML 文件并遍历每个服务器条目以执行部署
我非常乐意提供更具体的示例和协助，我看待事物的方式与大多数人略有不同，这在发布管理方面很有帮助。
我已经向我的团队介绍了 branching/merging，并且之前已经讨论过自动构建和部署签入 staging/master 分支的代码是多么棒，但我是一名初级开发人员，不是很 ops-y。
我遇到的问题是，我们创建了 Intranet 应用程序并将它们存储在我们自己可以访问的 VM 上，但我们也有负载平衡，这让我很伤心！
我可以让构建自动化（好吧，我还没有找出所有的错误，但我正在努力解决它们）- 我什至可以让构建自动创建一个 zip 文件准备就绪用于部署。 是否可以配置多个服务器进行部署？ 即.E
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).
***
也许值得注意的是我们目前有我们的 TFS 服务器 运行ning Visual Studio 所以代码是在同一台服务器上构建的，它全部存储，但这不是我们 运行 活码来自。
任何针对我的设置的帮助或教程都将不胜感激，我真的很想扭转这个部门的发布策略！
我将只讨论部署方面的问题。有很多不同的方法可以处理这个问题，例如：
- 自定义构建模板
- 编写自定义 .Net 代码并将其插入构建模板（这也涉及自定义模板）
- 在构建完成后创建设置为 运行 的 Batch 或 Powershell 脚本
- 使用 OctoDeploy 或 Release Manager 等单独的工具来处理部署
您需要做的第一件事是在脑海中分离构建和部署步骤。虽然它们在您的模型中紧密耦合，但它们是两个完全不同的任务，需要以不同的方式处理。
第二件事是在涉及部署部分时停止像开发人员一样思考。虽然可能会有程序化解决方案，但您需要先确定手动步骤。
你说你不是很 ops-y，我认为你的意思是你更多的是开发人员而不是系统分析师。如果是这种情况，那么您需要做的第三件事就是找人参与，例如您当前的发布团队。
接下来需要做的主要有3件事情：
- 一切都需要标准化。如果你不能标准化某些东西，那么标准化它是非标准的方式（例如：你有大量需要部署到的服务器列表，你需要根据它们的名称来确定要部署到哪些，哪个可以是任何东西。在这种情况下，需要制定一条规则，即所有 QA 服务器的名称中都需要有 QA，用户验收服务器需要 UAT，生产需要 PROD，等等）。
- 弄清楚您将如何从构建到部署进行通信，将部署哪些构建，部署到哪些服务器，以及将从何处获取代码
- 您需要记录每个手动步骤、这些步骤的每个异常，以及这些异常的每个异常。
一旦您准备好所有这些部分，您就需要完成每个手动步骤并使其自动化，无论是通过 Batch、Powershell 还是自定义构建的应用程序。将所有步骤自动化后，您将完成构建和部署部分。
在您能够对单个环境执行单个 "manual" 自动部署后，您就可以准备好如何 运行 将其部署到多个环境。这可能与迭代遍历的 XML 文件一样复杂，只需使用不同的参数多次调用相同的命令。
关于我在当前工作中如何完成此操作的快速总结（无法选择使用第三方部署工具）：
- 使用 .Net WinForms 创建了一个工具，使我们能够 "manually" 运行 自动构建（我们使用界面来确定输入参数，并在后台自定义 类完成所有繁重的工作。这些自定义 类 位于一个单独的项目中，该项目构建到它们自己的 dll。这也允许我们在将其推出到我们的生产构建之前在测试环境中测试对流程的调整和更改服务器）
- 为每组环境（QA、UAT、Prod 等）设置一个 XML 文件，其中包含需要部署到该环境中的所有服务器，包括目标路径、预定任务和 Windows 服务
- 自定义 TFS 构建模板并包含为自定义工具创建的自定义 类，它将读取 XML 文件并遍历每个服务器条目以执行部署
我非常乐意提供更具体的示例和协助，我看待事物的方式与大多数人略有不同，这在发布管理方面很有帮助。