章鱼和持续集成 - 应该创建版本的最佳实践是什么？ [英] 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 +包含所有单元测试，你可能最终排队的builds如果你不小心。及时性是一个因素。如果每次签入需要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脚本来执行Octo.exe命令后，构建步骤和包推送到您选择的nuget服务器。对于命令，你只是告诉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.
如果你想做nightly build选项，你会做同样的事情（脚本），除了改变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.
有没有其他团队使用Octopus服务器？我不知道你的环境中有多少台服务器，所以你真的知道什么是最好的。我只问，因为如果你是唯一的团队，那么你真的不必担心每个触手如何获得包。直接从nuget服务器到八达通服务器真的没关系。
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的URL。 exe文档： 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进行通讯。所以你可以从任何可以访问你的Octopus服务器的机器上测试出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.
因此，为了澄清OPs点何时需要创建发布，在八达通可以部署一个或多个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），然后八达通使用NuGet包版本控制您的版本。甜。您的发布版本可以显示您的变更集编号！真棒。好，除非你的项目正在部署多一个NuGet包。那么哪个包作为整个部署的 版本？当每个项目和部署过程有多个NuGet包时，事情变得很粘。这就是为什么章鱼中的其他版本控制机制（也称为变量模板）通常对每个人都是最好的。
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）：
To summarize (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.
这篇关于章鱼和持续集成 - 应该创建版本的最佳实践是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
