Octopus 和持续集成 - 何时创建发布的最佳实践是什么? [英] Octopus and Continuous Integration - What's the best practice around when a release should be created?
问题描述
在当前项目中，我们使用 Teamcity 和 Octopus 来构建和部署我们的 IIS 应用程序.
On a current project we are using Teamcity and Octopus for building and deploying our IIS app.
我们有 4 个环境.CI 环境(在签入时自动构建、运行单元测试和自动 QA 测试)，以及 QA、UAT 和 Prod 环境(我们使用 Octopus 手动推送).
We have 4 environments. The CI Environment (automated build on checkin, runs unit tests, and automated QA tests), and the QA, UAT, and Prod Environments (which we push to manually using Octopus).
在本地 (dev) 构建中，默认构建脚本会直接推送到本地 Octopus 实例以进行测试.
On local (dev) builds, the default build script pushes directly to a local Octopus instance for testing purposes.
让 CI 构建(运行相当频繁)遵循与本地构建类似的模型(并直接推送到 Tentacle 实例，而不是通过主服务器)或通过 Octopus 服务器会更好吗?(每次构建时都需要创建一个新版本).
Would it be better practice to have the CI build (which runs quite frequently) to follow a similar model as the local build (and push directly to a Tentacle instance, instead of through the master), or go through the Octopus server (requiring the creation of a new release every single time a build is made).
推荐答案
您的问题似乎相关，但我认为它们不相关，所以我将把这个答案分成两部分.
Your questions seem related but I don't think they are so I'll break this answer up into two pieces.
第一部分
我会说，根据您的软件包大小和每次构建的时间量(包括自动化单元/qa 测试)，您有两种选择:
I'd say, depending on the size of your packages and the amount of time for each build (including automated unit/qa tests), you have two options:
- 对每个构建进行持续部署，并使用 Octo.exe 自动部署每个构建.
- 再次使用 Octo.exe 在给定时间进行夜间构建，例如，在本地时间 7p 或 8p.
我认为至少要部署到您的 CI 和 QA 环境.只有测试人员将测试最新的部署才有意义.
I'd argue at a minimum deploying to your CI and QA environment. It only makes sense that the testers will test the latest deployment.
我提到包大小的原因是，如果您每天进行 15-20 次构建并生成包含所有单元测试的 50MB+ 包，如果您不小心，最终可能会排队构建.及时性是一个因素.如果每次签入需要 20 分钟来构建、nuget 打包、推送和部署，那可能没问题.但是每天 20 分钟 x N # 次签入，您可能会在一天中排队构建.更不用说存储可能(慢慢地)成为一个问题(或缺乏存储).我不知道有关您项目的所有细节，但请记住这些因素.
The reason I mention package size is because if you're doing 15-20 builds a day and generating 50MB+ packages with all the unit tests, you may end up queuing builds if you're not careful. Timeliness is a factor. If each check-in takes 20 minutes to build, nuget pack, push and deploy, that might be alright. But 20 minutes x N # of check-ins a day and you might be queuing builds by the middle of the day. Not to mention storage may (slowly) become an issue (or lack of storage). I don't know all the details about your project but just keep these factors in mind.
无论您想做什么，都必须使用 Octo.exe.如果您想做 #1(持续部署)，您可以编写一个简单的 Powershell 脚本来在构建步骤和包被推送到您选择的 nuget 服务器之后执行 Octo.exe 命令.对于命令，您只需告诉 Octopus 获取最新的软件包.
No matter what you want to do, you'll have to use the Octo.exe. If you want to do #1 (continuous deployment) you could write a simple Powershell script to execute the Octo.exe command AFTER the build steps and package is pushed to the nuget server of your choice. For the command, you'll just tell Octopus to get the latest package.
如果您想执行每晚构建选项，您将执行相同的操作(脚本方面)，除了更改 TeamCity 以运行另一个脚本，您将在 Windows 服务器上安排一个任务以运行该脚本某个时间.这将是最谨慎的选择，但从这个切换到持续部署选项并不难.
If you want to do the nightly build option, you'd do the same thing (script-wise) except instead of changing TeamCity to run another script, you'd schedule a task on your Windows server to run that script at a certain time. This would be the most prudent option, but it's not difficult to switch from this to the continuous deployment option.
第二部分
就直接从服务器或直接从 NuGet 服务器获取包而言，这无关紧要.我会考虑一些可以指导您选择其中一个的事情.
As far as fetching the packages directly from the server or directly from the NuGet server, it should not matter. I would take a few things in mind that would guide you in picking one over the other.
考虑到你的包大小 - 包越大，我认为直接到 nuget 服务器更可取仅 考虑到 Octopus IO 负载.很可能，这没什么大不了的.
Take your package size into consideration - the larger the package, I'd argue going to direct to the nuget server is preferable only out of concern for the Octopus IO load. Odds are, this won't be a big deal.
每个环境的服务器数量 - 特别是在每个环境中有多个服务器的情况下.默认情况下，Octopus 会尝试进行并行部署，但您可以切换到滚动"部署(一次设置要部署的特定服务器数量).如果您为每次签到都进行持续部署，则每个触手都必须下载最新的包.同样，根据包裹大小和要推送的触手数量，您可能会遇到一些带宽问题.同样，我不知道您的环境中有多少台服务器，所以您真的知道什么是最好的.
Number of servers per environment - especially if you have multiple servers in each environment. By default Octopus tries to do parallel deployments but you can switch to "rolling" deployments (setting a specific # of servers to be deployed to at a time). If you're doing continuous deployments for EVERY check-in, each tentacle will have to download the latest package. Again, depending on package size and number of tentacles to push to, you may run into some bandwidth issues. Again, I don't know how many servers you have in your environments so you really know what's best.
还有其他团队在使用八达通服务器吗?我问只是因为如果您是唯一的团队，那么您真的不必担心每个触手如何获得包裹.直接从 nuget 服务器与 Octopus 服务器真的无关紧要.
Are there any other teams using the Octopus Server? I ask only because if you're the only team then you really don't have to worry how each tentacle gets the package. Direct from the nuget server vs. the Octopus server really won't matter.
这是 Octo.exe 文档的 URL:http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596它是您最好的朋友，可以完全自动化构建到您想要的任何环境.
Here's the URL to the Octo.exe documentation: http://docs.octopusdeploy.com/pages/viewpage.action?pageId=360596 It's your best friend for fully automating your builds to whatever environments you want.
无论您选择什么，我都强烈建议您自动化部署.时期.将其自动化后，您会想知道为什么要为手动部署而烦恼.请记住，octo.exe 不需要需要在章鱼服务器本身上运行！
No matter what you choose, I'd highly recommend automating your deployments. Period. After you've automated it, you'll wonder why you bothered with manual deployments. Keep in mind, the octo.exe does not need to run on the octopus server itself!
Octo.exe 使用 Octopus API 并与上述 API 进行通信以实现一切.因此，您可以在任何可以访问您的八达通服务器的机器上测试 Octo.exe 命令.最好在您的桌面上试用它，一旦你得到它恰到好处，然后将它放入脚本并测试它.
The Octo.exe uses the Octopus API and communicates with said API for everything. So you can test out the Octo.exe command from any machine that can access your Octopus Server. It's best to try it out on your desktop and once you get it just right, then put it into a script and test it.
因此，为了向 OP 澄清何时"需要创建一个版本，这是非常主观的，并且由于 Octopus 中的项目可以部署一个或多个 NuGet 包，因此它会因具体情况而异.也就是说，我认为需要对您的版本进行版本控制，这不可避免地会将您的二进制文件和 Nuget 包的版本控制带入舞台.
So to clarify to the OPs point of "when" a release needs to be created, it's highly subjective and since projects within Octopus can deploy one or more NuGet packages it's going to vary on a case by case basis. That said, I think there needs to be some acknowledgement of versioning your releases which inevitably brings your versioning of your binaries and Nuget packages into the arena as well.
示例:如果您的测试人员严重依赖 TFS 变更集编号，那么最好将该变更集编号嵌入到您的二进制文件中(通过 AssemblyVersionInfo)并让您的 NuGet 包反映该版本(在您的 NuSpec 中)，然后让 Octopus 使用 NuGet 包版本控制为您的发布.甜的.您的发布版本可以显示您的变更集编号！惊人的.好吧，除非您的项目部署了更多 个 NuGet 包.那么哪个包充当整个部署的 版本?当每个项目和部署过程有多个 NuGet 包时，事情就会变得很棘手.这就是为什么 Octopus 中的其他版本控制机制(又名变量模板)通常最适合所有人.
Example: If your testers heavily rely on TFS changeset numbers then it's best have that changeset number embedded in your binaries (via AssemblyVersionInfo) and have your NuGet packages reflect that version (in your NuSpec) and then have Octopus use NuGet package versioning for your releases. Sweet. Your release versions can show your changeset number! Awesome. Well except when your project is deploying more than one NuGet package. So which package acts as the version for the entire deployment? Things get pretty sticky when you have more than one NuGet package per project and deployment process. That's why the other versioning mechanism in Octopus (aka variable template) works typically best for everyone.
请记住，八达通推广背后的概念也是一项重要功能，尤其是在您考虑最佳做法时.最好在环境之间促进发布，不仅是为了在部署过程、NuGet 包版本和变量值方面保持一致，而且版本号(无论是 NuGet 还是变量模板)在您的环境中都是一致的.在所有环境中查看版本 1.0.2 并发布 1.0.2 已经过彻底测试，而不是为每个部署创建一个新版本——看起来像这样:1.0.1、1.0.2、1.0.3、1.0.4 等，尤其是在代码完全相同的情况下.促销允许您(有效地)将发布重新部署到具有所有相同 NuGet 包版本、变量设置和部署过程的另一个环境 - 都在同一个发布版本中.作为一个无耻的自插件，这里是 我的博文 关于这个版本控制问题.
Keep in mind the concept behind promotion within Octopus is also an important feature - especially if you're addressing best practices. It's best to promote a release between environments not only for consistency in the deployment process, NuGet package versions and variable values, but the version number (whether NuGet or variable template) being consistent across your environments. It's visually much easier to see release 1.0.2 across all environments and release that 1.0.2 has been thoroughly tested, rather than creating a new release for EACH deployment - which would look something like this: 1.0.1, 1.0.2, 1.0.3, 1.0.4, etc. especially when the code is the all the same. Promotions allow you to (effectively) redeploy a release to another environment with all the same NuGet package versions, variable settings and deployment process - all within the same release version. As a shameless self-plug, here's my blog post on this issue of versioning.
是否有关于何时"创建版本的最佳做法?我会说对于任何代码更改，都需要一个新版本.您无需创建新版本即可将相同代码移动到不同的环境.但如果您关心版本，您也应该关心版本控制.
Are there best practices on "when" to create a release? I'd say for any code change, a new release is necessary. You don't need to create a new release for moving the same code to a different environment. But if you're concerned with releases, you should also be concerned with versioning as well.
总结(TL;DR):
- Octopus Deploy 发布最佳实践绑定到 NuGet、NuGet 版本控制和发布版本控制.从相关代码的角度来看，您的版本号很重要.您选择哪种类型的发布版本(nuget 或变量模板)，只需意识到所有可以和可能都应该链接 - 取决于您项目的需要.
- 始终将版本推广到另一个环境 - 不要为部署在另一个环境中的相同代码创建新版本.确定什么代码在哪个环境中是令人困惑的，这就是存在提升按钮的原因.
- 如果您在部署过程中有一个 NuGet 包 - 您可以依赖 NuGet 包版本控制来进行发布.不止一个，切换到可变模板版本.
- Octopus Deploy release best practices are bound to NuGet, NuGet versioning and release versioning. The version number of your release matters from a relative code perspective. Which type of release version you choose (nuget or variable template), just realize that everything can and probably should be linked - depending on your project's needs.
- Always promote a release to another environment - don't create a new release for the same code deployed in another environment. It's confusing to determine what code is in which environment and that's why the promotion button exists.
- If you have one NuGet package in your deployment process - you can rely on NuGet package versioning for your releases. More than one, switch to variable template versioning.
目前我能想到的就是这些了.希望这可以澄清事情.
This is all I can think of off the top of my head at the moment. Hope this clarifies things.
这篇关于Octopus 和持续集成 - 何时创建发布的最佳实践是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
