在当前项目中，我们使用 Teamcity 和 Octopus 来构建和部署我们的 IIS 应用程序。
我们有 4 个环境。 CI 环境（在签入时自动构建、运行单元测试和自动 QA 测试），以及 QA、UAT 和 Prod 环境（我们使用 Octopus 手动推送）。
在本地 (dev) 构建中，默认构建脚本会直接推送到本地 Octopus 实例以进行测试。
让 CI 构建（运行相当频繁）遵循与本地构建类似的模型（并直接推送到 Tentacle 实例，而不是通过主服务器）或通过 Octopus 服务器会更好吗？ （每次构建时都需要创建一个新版本）。
【问题讨论】：
标签： continuous-integration octopus-deploy
您的问题似乎相关，但我认为它们不相关，因此我将把这个答案分成两部分。
第一部分
我想说，根据你的包的大小和每次构建的时间量（包括自动化的单元/qa 测试），你有两个选择：
我认为至少要部署到您的 CI 和 QA 环境。只有测试人员将测试最新的部署才有意义。
我提到包大小的原因是，如果您每天进行 15-20 次构建并生成包含所有单元测试的 50MB+ 包，如果您不小心，最终可能会排队构建。及时性是一个因素。如果每次签入需要 20 分钟来构建、nuget 打包、推送和部署，那可能没问题。但是每天 20 分钟 x N # 次签入，您可能会在一天中排队构建。更不用说存储可能（慢慢地）成为一个问题（或缺乏存储）。我不知道有关您项目的所有细节，但请记住这些因素。
无论您想做什么，都必须使用 Octo.exe。如果您想做 #1（持续部署），您可以编写一个简单的 Powershell 脚本来在构建步骤和包被推送到您选择的 nuget 服务器之后执行 Octo.exe 命令。对于命令，您只需告诉 Octopus 获取最新的软件包。
如果您想执行每晚构建选项，您将执行相同的操作（脚本方面），除了更改 TeamCity 以运行另一个脚本，您将在 Windows 服务器上安排一个任务以运行该脚本某个时间。这将是最谨慎的选择，但从这个切换到持续部署选项并不难。
第二部分
就直接从服务器或直接从 NuGet 服务器获取包而言，这无关紧要。我会考虑一些可以指导您选择其中一个的事情。
考虑到您的包大小 - 出于对 Octopus IO 负载的担忧，我认为直接到 nuget 服务器的包越大只有。很可能，这没什么大不了的。
每个环境的服务器数量 - 特别是在每个环境中有多个服务器的情况下。默认情况下，Octopus 会尝试进行并行部署，但您可以切换到“滚动”部署（一次设置要部署的特定服务器数量）。如果您为每次签到都进行持续部署，则每个触手都必须下载最新的包。同样，根据包裹大小和要推送的触手数量，您可能会遇到一些带宽问题。同样，我不知道您的环境中有多少台服务器，所以您真的知道什么是最好的。
还有其他团队在使用八达通服务器吗？我问只是因为如果您是唯一的团队，那么您真的不必担心每个触手如何获得包裹。直接从 nuget 服务器与 Octopus 服务器真的无关紧要。
这里是 Octo.exe 文档的 URL：http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596 它是您在任何环境中完全自动化构建的最佳朋友。
无论您选择什么，我都强烈建议您自动化部署。时期。将其自动化后，您会想知道为什么要为手动部署而烦恼。请记住，octo.exe 不需要需要在章鱼服务器本身上运行！
Octo.exe 使用 Octopus API 并与上述 API 进行通信以实现一切。因此，您可以在任何可以访问您的八达通服务器的机器上测试 Octo.exe 命令。最好在您的桌面上试用它，一旦你得到它恰到好处，然后将它放入脚本并测试它。
因此，为了向 OP 澄清“何时”需要创建一个版本，这是非常主观的，并且由于 Octopus 中的项目可以部署一个或多个 NuGet 包，因此它会因具体情况而异。也就是说，我认为需要对您的版本进行版本控制，这不可避免地会将您的二进制文件和 Nuget 包的版本控制带入舞台。
示例：如果您的测试人员严重依赖 TFS 变更集编号，那么最好将该变更集编号嵌入到您的二进制文件中（通过 AssemblyVersionInfo）并让您的 NuGet 包反映该版本（在您的 NuSpec 中），然后让 Octopus 使用 NuGet 包版本控制为您的发布。甜的。您的发布版本可以显示您的变更集编号！惊人的。好吧，除非您的项目部署了更多 个 NuGet 包。那么哪个包充当整个部署的 版本？当每个项目和部署过程有多个 NuGet 包时，事情就会变得很棘手。这就是为什么 Octopus 中的其他版本控制机制（又名变量模板）通常最适合所有人。
请记住，八达通推广背后的概念也是一项重要功能，尤其是在您考虑最佳做法时。最好在环境之间促进发布，不仅是为了在部署过程、NuGet 包版本和变量值方面保持一致，而且版本号（无论是 NuGet 还是变量模板）在您的环境中都是一致的。在所有环境中查看版本 1.0.2 并发布 1.0.2 已经过彻底测试，而不是为每个部署创建一个新版本——看起来像这样：1.0.1、1.0.2、1.0 .3、1.0.4 等，尤其是在代码完全相同的情况下。促销允许您（有效地）将发布重新部署到具有所有相同 NuGet 包版本、变量设置和部署过程的另一个环境 - 都在同一个发布版本中。作为一个无耻的自塞，这里是my blog post关于这个版本的问题。
是否有关于“何时”创建版本的最佳做法？我会说对于任何代码更改，都需要一个新版本。您无需创建新版本即可将相同代码移动到不同的环境。但如果您关心版本，您也应该关心版本控制。
总结（TL;DR）：
目前我能想到的就是这些了。希望这可以澄清事情。
【讨论】：
这是我的最佳实践 - 祝你有美好的一天 :-)
首先创建一个 AutoDeploy 用户@OctopusDeploy。生成一个 API 密钥并保留它。我们使用它从您的构建应用程序服务器连接到 OctopusDeploy。
打开您的试点选择 Octopus 项目的流程选项卡。编辑现有的 nuget 包部署步骤。将项目的 nuget 提要更改为“Octopus Server (built-in)” 禁用 Octopus 上的任何自动发布和部署触发器。
将 octopack 添加到您的解决方案文件中，即您的工作 csproj。
将 nuspec 文件添加到解决方案的 csproj 文件中。它必须与 csproj 同名。
Nuspec 文件部分可以这样。不要忘记 nuspec 文件中的包 ID..
<files>
<file src="obj\**\*.*" exclude="obj\octopacking\**\*.*;obj\octopacked\**\*.*;obj\Release\Package\**\*.*;**\*.pdb;**\*.ps1;**\*.dll.config;**\*.loadtest;_DeveloperNotes;_PublishedWebsites" target="obj"/>
<file src="Deploy.ps1" />
</files>
还将 deploy.cmd(msdeploy) 和 deploy.ps1（自定义脚本）文件添加到您的 csproj。
Deploy.ps1 可能如下所示
[string[]]$params = @(
"-setParam:name='IIS Web Application Name',value='" + $iisapplicationname + "'",
"-skip:Directory=^" + $iisapplicationname + "\\App_Data",
"-skip:File=.config$",
"-skip:File=.cmd$",
"-skip:File=.ps1$"
)
$msdeployArgs = [string]::join(' ', $params)
if ($OctopusEnvironmentName -ceq 'Development')
{
.\obj\Release\Myproject.Deploy.cmd /Y /M:localhost ($msdeployArgs) | Write-Output
}
else
{
.\obj\Release\Myproject.Deploy.cmd /Y /M:localhost ($msdeployArgs) | Write-Output
}
将“iisapplicationname”添加到您的 OctopusDeploy 项目并为您的每个环境设置值。
我们添加到 sln 的文件，打开每个文件的属性。像这样更改属性。复制到输出目录不要复制，构建操作无。
你需要一个像 Jenkins 这样的构建服务器。
将插件添加到您的构建服务器，您必须将其用于项目构建和打包操作。 (Git, TFS, Change Assembly version plugin, Msbuild, Nunit, Version number plugin)
在您的构建服务器中添加一个文件夹，例如“C:\Scripts”。并将 Octo.exe、nuget.exe、nuget.config 文件复制到这个位置。稍后，您应该将自定义批处理 (.bat) 文件添加到此位置。
为您的 X 项目创建一个空项目并添加构建分支的开发代码存储库。（您应该将开发分支命名为“develop”）您必须为存储库连接设置凭据。
触发作业并检查您是否确定将正确的分支代码下载到构建服务器工作区。
编辑同一个项目并将“执行 windows 批处理命令”步骤添加到您的构建项目中。在构建服务器上添加以下命令以恢复 nuget 包。
“C:\Scripts\NuGet.exe”恢复“%WORKSPACE%\Myproject.sln”
触发作业并检查包还原是否在构建任务控制台上运行。
编辑同一个项目。添加“使用 MSbuild 构建 Vİsual Studio 项目或解决方案”确保最新的 MSbuild 版本已安装在构建服务器上。 MSbuild 文件名：
$WORKSPACE\Myproject.sln
命令行参数：
/t:重建 /p:AutoParameterizationWebConfigConnectionStrings=False /p:DebugSymbols=false /p:DebugType=None /p:IsAutoBuild=True /p:CreatePackageOnPublish=true /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\Myproject.zip";PackageAsSingleFile=True /p:RunOctoPack=true /p:OctoPackPackageVersion=%VERSION%-dev /p:OctoPackPublishPackageToHttp=http://octopus.yourdomain.com/nuget/packages /p:OctoPackPublishApiKey=API-xxxxxxxxxxxxx
在您的开发构建和部署项目中添加“执行 windows 批处理命令”。并编写带有参数的followig批处理文件。
call "C:\Scripts\JenkinsciDeploy.bat" Myproject %VERSION%-dev OctopusProjectName Development %BUILD_NUMBER% %JOB_NAME%
将以下文件复制为此位置“C:\Scripts”
cd C:\Scripts
Octo.exe create-release --project %3 --version %2 --packageversion %2 --server http://octopus.yourdomain.com --apiKey API-xxxxxxxxxxx --deployto %4 --progress --force --guidedfailure=False --waitfordeployment --deploymenttimeout=00:30:00 --releaseNotes "Jenkins build [%5] http://jenkins.yourdomain.com:8080/job/%6/%5"
修改您的 Jenkins 项目。选中“创建格式化的版本号”选项。环境变量名称必须命名为“VERSION”。版本号格式字符串应为"${BUILD_YEAR}.${BUILD_MONTH}.${BUILD_DAY}.${BUILDS_TODAY}"
为您的 Jenkins 项目添加“更改程序集版本”步骤。程序集版本必须命名为“$VERSION”
使用 Poll CSM 为每次签到构建 jenkins 项目。在您的代码存储库中，必须为项目启用 Hook。或者您应该安排构建/部署设置。
添加后期构建步骤“电子邮件通知”
最后你应该会看到结果。
您应该为不同的分支和不同的环境克隆这个构建作业。 将版本控制格式从“%VERSION%-dev”更改为“%VERSION%”或“%VERSION%-hotfix” 将分支从“/develop”更改为“/master”“*/hotfix”
在“JenkinsciDeploy.bat”批处理参数中更改部署目标环境。
您应该将它用于将要部署的任何 Web 应用程序..
【讨论】：