Octopus Deployment 基础知识

引言

一切都始于 NuGet。Octopus 将应用程序视为 NuGet 包进行处理，并将它们分发到相应的服务器。PowerShell 也同样重要，它是实现我们部署过程所有自定义功能的粘合剂。任何 Octopus 内未包含的功能都可以通过 PowerShell 添加到 Octopus 中。NancyFX 和 RavenDB 对 Octopus Deploy 的成功也至关重要，但它们是幕后组件。所有这些组件都用于 Octopus Deploy，为每个人带来好处，而且到目前为止（截至今日），每一个设计决策都得到了回报。让我们来概览一下部署应用程序的高层流程。

请记住，您不必一定使用 Visual Studio，但在本示例中，我们将假定使用 Visual Studio 和 TFS。无论具体细节如何，从这个高层工作流程中 takeaway 的关键点是，有四个主要步骤：

1. 配置您的 IDE
2. 生成您的 NuGet 包
3. 将您的 NuGet 包推送到 NuGet 服务器
4. 配置您的部署流程

Octo.exe 是一个实用程序，可用于自动化您的部署，即持续部署。您不一定需要使用 Octo.exe 才能进行部署。Octo.exe 还有其他您可以利用的实用程序功能，但对于我们的主题，我们将专注于 Octopus 中的基本部署。我们将在另一篇文章中更详细地介绍 Octo.exe，但您会发现在 Octopus Deploy 中，许多功能都是可选的，并且在本例中，Octo.exe 被省略了。

配置 Visual Studio

让我们从 Visual Studio（2010 或更高版本）和 CI（持续集成）服务器开始。在本例中，我将专注于 TFS，因为我对此比较熟悉，但请记住，Octopus 与其他解决方案兼容，例如 Team City、Atlassian Bamboo、Cruise Control .NET 等。Octopus 如何能够与如此多的供应商产品兼容？简单来说——没有集成。

当我开始研究 Octopus Deploy 时，我曾想过为什么没有直接的客户端集成或 CI 组件安装。在使用 Octopus 和 NuGet 后，我意识到使用 NuGet 的好处在于，Octopus、Visual Studio 和 TFS 之间不需要任何直接集成。Octopus 不关心您使用哪个 NuGet 服务器，也不关心您如何生成解决方案的 NuGet 包。您负责将项目创建为 NuGet 包，作为回报，您可以选择如何做到这一点。由于任何项目都可以有任意数量的项目或配置，因此这种灵活性是一个优势。

对于使用 TFS 的用户来说，最快的入门方法是使用 OctoPack。在 NuGet 包管理器中，只需搜索 OctoPack 并将其安装到需要通过 NuGet 传输到相应服务器的项目中即可。请注意，OctoPack 实际上并没有在您的解决方案中添加任何 dll。OctoPack dll (Octo.Tasks) 位于您的 packages 文件夹中，并在 MSBuild 完成编译应用程序后被调用。

现在 OctoPack 已为您的项目安装好，我们需要为每个要创建 NuGet 包的项目创建 nuspec 文件。Nuspec 文件允许您向 NuGet 包添加元数据，并包含或排除 NuGet pack 命令可能会附加或省略的文件。创建 nuspec 文件是一个非常简单的过程。确保您已下载 nuget.exe。

使用 DOS 命令提示符，转到您的项目目录，其中包含 *.csproj 或 *.vbproj 文件。执行命令“<path>\nuget.exe spec <yourprojectname>.csproj”。这将创建一个 .nuspec 文件，您需要将其包含在您的项目中。

一旦 nuspec 文件创建完成，您需要将其添加到您的项目中并编辑默认值。您可能会注意到 nuspec 文件中的版本号。版本控制本身就是一个主题，但为了简单起见——在您的项目 AssemblyInfo.cs 文件中，将 AssemblyVersion 值从“1.0.0.0”更改为“1.0.*”。

这将为每次生成动态生成一个新数字，并更改 NuGet 包的版本号。这种版本控制技术的优点在于它很简单，并且随着生成号实际上是日期引用，修订号是生成当天的相对时间，它将始终递增。这使得排序变得容易，如果您使用 Octo.exe，您可以将其配置为使用最新版本的 NuGet 包，这非常适合持续部署。您可以在我关于 Octopus Deploy 中的版本控制（第一部分） 的深入文章中阅读更多关于版本控制的内容。

生成您的 NuGet 包

有了 OctoPack 和 nuspec 文件就绪，我们现在就可以开始生成 NuGet 包了。您选择如何生成应用程序包（再次）取决于您。为了本示例的方便，我假设您正在使用 TFS。对于 TFS，您的生成模板是传递参数给 OctoPack 的地方。在“Process”选项卡中查找 MSBuild Arguments 字段。该字段在不同 TFS 版本中的模板位置可能有所不同。下面的示例是我 TFS Online 帐户中的一个生成模板。

OctoPack 至少需要三个参数：

/p:RunOctoPack=true
/p:OctoPackPublishPackageToHttp=<http://yournugetserver.com>
/p:OctoPackPublishApiKey=<your API Key>

就是这样。OctoPack 提供了更多参数选项，但这三个参数是最低要求，它们指示 OctoPack 运行 NuGet pack 命令，该命令将生成 NuGet 包，然后将这些包上传到目标 NuGet 服务器。

注意： OctoPack 是开源的！随着时间的推移，贡献者添加了许多更改和功能。如果您真的想了解发生了什么，请自行查看源代码！

您应该通过浏览相应的 URL 来查看 NuGet 服务器上的 NuGet 包。每个 NuGet 服务器可能有不同的 URL 路径或方案来访问您的特定源，但大多数（如果不是全部）都有某种方式来查看可用的包。

正如您所见，OctoPack 非常易于使用，但如果您更倾向于使用 .proj 文件和 XAML 或 PowerShell 脚本，那也是可以的。我可以另找时间介绍该主题，但就 Octopus Deploy 而言，它不参与您的项目如何编译和打包。仅仅将 NuGet 包传输到服务器是一个关键步骤；Octopus 不需要知道它，除非您想进行持续部署，这需要 Octo.exe。这种与 Visual Studio 和/或 TFS 的缺乏集成似乎是一个负担，但实际上它是一个巨大的优势，因为它提供了创意的选择，而不是强制执行僵化和压抑的流程。并非每个人都使用 TFS，也不是每个项目都适合相同的模式，因此虽然这个过程看起来很麻烦（而且确实可能如此），但它也非常适合多种情况。

注意： Octopus 的当前 路线图（截至本文撰写时）建议与 Bamboo、Jenkins、TFS 和 TeamCity 等 CI 解决方案进行更多集成。我没有使用过 TeamCity，所以无法评论当前可用的插件，而且我没有关于其他解决方案的太多信息，因此在它们发布之前，很难确定这些插件产品有多“集成”。

将您的 NuGet 包推送到 NuGet 服务器

一旦您的解决方案能够编译、生成项目 NuGet 包并将其上传（在 NuGet 术语中也称为“推送”包）到 NuGet 服务器，Octopus Deploy 就开始处理剩余的事情。剩余的事情就是将您的应用程序及其所有精彩组件移动到您想要的任何服务器上的环境中。

NuGet 服务器，就像 Visual Studio 一样，并没有真正集成到 Octopus 中。NuGet 服务器上没有需要安装的客户端或组件。您只需通过 URL 源注册一个 NuGet 服务器。如果需要身份验证，您可以输入用户名/密码。

如果您选择将包直接存储在服务器本身上，Octopus 有自己的内部 NuGet 服务器。同样，就像我们在 Octopus Deploy 的其他方面看到的那样，使用内部 NuGet 服务器不是强制性的。您可以使用 Octopus 服务器可以访问的任何 NuGet 服务器，无论是在您的组织内部（本地）还是 Web 上的服务，例如 MyGet.org。一些商业 NuGet 服务器，如 ProGet，提供基于 NTLM/Active Directory 的身份验证与 NuGet 源，您也可以使用用户名和密码进行连接。

虽然 Octopus Deploy 与 NuGet 服务器之间这种松散耦合似乎是一个奇怪的选择，但它这种轻量级的方法是一个巨大的好处，因为您可以创造性地利用这种弱联系，而这种联系乍一看并不明显。例如，备份、二级站点，如 MyGet.org 或 Azure VM。这可能需要更多的 PowerShell 脚本，但配置并不难设置和自动化。

配置您的部署流程

现在来到我们晚餐的主菜：部署流程。部署流程的核心是您项目中的“Process”（进程）选项卡。

您可以为您的部署流程添加任意数量的步骤。在新的 2.4 版本中，可以在 http://library.octopusdeploy.com 下载步骤模板。我们将在另一篇文章中回顾步骤模板。

作为部署流程自定义的一部分，您可以选择任何内置模板。所有模板都提供一定程度的灵活性。Deploy NuGet package 步骤类型提供了关于安装路径、IIS 服务器配置选项、AppPool 配置等的选项。

现在，您可能已经注意到，在 Octopus 的每个项目中，都有一个 Deployment Process 选项卡。嗯……只有一个？怎么回事？选项什么的去哪了？为什么只有一个？答案是：您只需要一个。

您可能会说：“但是我有些东西只能在特定环境中发生！”别担心。您项目中的每个步骤都有一个特定的条件，规定在哪些环境中运行。这适用于 Octopus Deploy 部署流程中的所有步骤。因此，有些步骤可能只适用于 Dev 和 Staging。其他一些步骤可能只适用于 Production。这完全取决于您。

现在您的 NuGet 包已经制作完成，存储在 NuGet 服务器中，并且您的部署流程已准备就绪，是时候手动创建一个发布版本并进行部署了。在本篇文章中，我将不介绍变量。我将在另一篇文章中讨论这个问题，因为该主题（像许多其他主题一样）在这个讨论中相当难以解释。

注意：我接下来提供的步骤是手动创建新发布版本和部署的。您可以使用 Octo.exe 自动化所有这些步骤。

在您项目的每个页面上，右上角都有一个绿色的按钮，标有“Create Release”（创建发布版本）。请注意，所有发布版本本身都是版本化的，因此您可以对同一个发布版本进行多次部署。这有助于为所有部署保持一定的逻辑组织。此外，请记住，对于每个发布版本（而不是部署），Octopus 都会对所有变量、步骤、设置和值进行快照。仅仅因为您更新了一些信息，并不意味着更改会生效。快照对于能够运行以前的发布版本，并保持所有变量值和设置与最初保存时相同非常有用。对于您对部署流程所做的每一次更改和保存，都需要创建一个新的发布版本才能获取最新的更改。

点击“Create Release”后，您将进入一个屏幕，选择在您的进程选项卡中请求下载的 NuGet 包的特定版本。在这里，您可以轻松导航您想要的 NuGet 包，因为您可以选择最新包、上一次部署的包或搜索特定包。

点击放大镜将查询配置了部署流程步骤的 NuGet 服务器，并显示已上传的 NuGet 包列表。

保存发布版本后，您就可以进行部署了。在保存后点击“Deploy Release”（部署发布版本）按钮，将带您进入另一个屏幕，询问您要部署到哪个环境。您为项目配置的任何环境都应在下拉菜单中可见，供您选择。

注意：所有部署（默认情况下）都是跨服务器并行进行的。您可以通过设置一个 Rolling Deployment（滚动部署）数字来告诉 Octopus 一次部署多少台服务器。您可以将滚动部署提供的数字视为要部署到的服务器的批次大小。现在，每个服务器内的部署流程是串行的（在 2.6 版中，步骤可以并行运行）。路线图上正在计划让服务器上的进程也并行运行。

在部署运行时，您可以查看“Task Log”（任务日志）选项卡，实时观察部署过程。这些信息会保留在发布版本中，因此您不必保存任何内容。如果您删除了发布版本，您显然会丢失相关的任务日志。

这种用于整个部署的“任务日志”一体化视图是 Octopus Deploy 的一个出色功能。您无需配置任何内容。这一切都是默认的，您选择手动添加到部署流程中的任何 PowerShell 脚本也会被记录下来。此任务日志视图以简单、逻辑的格式显示所有服务器上正在发生的所有事情。

毫无疑问，您现在应该能看到我为什么称赞 Octopus Deploy；它的灵活性和独特的方法使其适用于各种项目和配置。我希望您到目前为止已经喜欢 Octopus Deploy 系列。我将在本周晚些时候再写一篇文章来总结我们对 Octopus Deploy 的高层覆盖。之后，我将开始一个新的“深入研究”系列，以真正了解如何在 Octopus Deploy 中为您的项目运用特定功能。