八达通和持续集成 - 应该创建一个版本的最佳实践是什么？

Question

在当前项目中,我们使用Teamcity和Octopus来构建和部署我们的IIS应用程序.

我们有4个环境.CI环境(自动构建签入,运行单元测试和自动QA测试),以及QA,UAT和Prod环境(我们推动手动使用Octopus).

在本地(dev)构建中,默认构建脚本直接推送到本地Octopus实例以进行测试.

更好的做法是让CI构建(运行频繁)遵循与本地构建类似的模型(并直接推送到Tentacle实例,而不是通过主服务器),或者通过Octopus服务器(需要每次构建时都会创建一个新版本).

Answer 1

你的问题似乎有关,但我不认为它们是如此,我将这个答案分成两部分.

第一部分

我会说,根据包的大小和每次构建的时间(包括自动化单位/ qa测试),您有两种选择:

1. 为每个构建做持续部署,并使用Octo.exe自动化每个构建以进行部署.
2. 使用Octo.exe在每个当地时间再次建立一个给定时间,例如7p或8p.

我认为至少要部署到CI和QA环境.只有测试人员才能测试最新部署才有意义.

我提到包大小的原因是因为如果你每天做15-20个构建并且生成50MB +包含所有单元测试,那么如果你不小心的话,你最终可能会排队.及时性是一个因素.如果每个签入都需要20分钟来构建,nuget pack,push和deploy,这可能没问题.但是每天20分钟x N#次办理登机手续,你可能会在当天中午排队.更不用说存储可能(慢慢地)成为一个问题(或缺乏存储).我不知道您项目的所有细节,但请记住这些因素.

无论你想做什么,你都必须使用Octo.exe.如果你想做#1(持续部署),你可以编写一个简单的Powershell脚本来执行Octo.exe命令,在构建步骤和包被推送到你选择的nuget服务器之后.对于命令,您只需告诉Octopus获取最新的包.

如果你想做每晚构建选项,你会做同样的事情(脚本方式),除了不改变TeamCity运行另一个脚本,你在Windows服务器上安排一个任务在特定时间运行该脚本.这将是最谨慎的选择,但从此切换到持续部署选项并不困难.

第二部分

至于直接从服务器或直接从NuGet服务器获取软件包,它应该无关紧要.我会记住一些事情,指导你选择一个而不是另一个.

• 考虑你的包装尺寸 - 包装越大,我认为直接到nuget服务器是优选的,只是出于对Octopus IO负载的关注.可能性,这不会是一个大问题.

• 每个环境的服务器数量 - 特别是如果每​​个环境中有多个服务器.默认情况下,Octopus尝试进行并行部署,但您可以切换到"滚动"部署(一次设置要部署的特定服务器数).如果您正在为每次办理登机手续进行持续部署,则每个触手都必须下载最新的软件包.同样,根据封装尺寸和要推入的触手数量,您可能会遇到一些带宽问题.同样,我不知道你的环境中有多少台服务器,所以你真的知道什么是最好的.

• 有没有其他团队使用八达通服务器？我只是因为如果你是唯一的团队,那么你真的不必担心每个触手如何获得包裹.直接从nuget服务器到Octopus服务器真的无关紧要.

以下是Octo.exe文档的URL:http://docs.octopusdeploy.com/pages/viewpage.action？pageId = 360596 您最好的朋友是将您的构建完全自动化到您想要的任何环境.

无论您选择什么,我都强烈建议您自动部署.期.在您自动化之后,您会想知道为什么您会为手动部署而烦恼.请记住,在octo.exe并没有需要到章鱼服务器本身上运行!

该Octo.exe使用八达通API和通信与上述的API 一切.因此,您可以从任何可以访问您的Octopus服务器的计算机上测试Octo.exe命令.最好在你的桌面上试一试,一旦你得到它,然后把它放入一个脚本并测试它.

因此,为了向OPs澄清"何时"需要创建一个版本,它是非常主观的,因为Octopus中的项目可以部署一个或多个NuGet包,它将根据具体情况而有所不同.也就是说,我认为需要对发布版本进行一些认可,这不可避免地会将您的二进制文件和Nuget包的版本化也带入竞技场.

示例:如果您的测试人员严重依赖TFS变更集编号,那么最好将二进制文件中嵌入的变更集编号(通过AssemblyVersionInfo)并让您的NuGet包反映该版本(在您的NuSpec中),然后让Octopus为您的版本使用NuGet包版本控制.甜.您的发布版本可以显示您的变更集编号!真棒.好吧,除非您的项目正在部署多个 NuGet包.那么哪个包充当整个部署的版本？当每个项目和部署过程有多个NuGet包时,事情会变得非常棘手.这就是为什么Octopus(又名变量模板)中的其他版本控制机制通常最适合每个人的原因.

请记住,Octopus中推广背后的概念也是一个重要特征 - 特别是如果您正在解决最佳实践.最好是在环境之间推广发布,不仅是为了部署过程的一致性,NuGet包版本和变量值,而且版本号(无论是NuGet还是变量模板)在您的环境中保持一致.在所有环境中看到版本1.0.2并且发布1.0.2已经过全面测试,而不是为EACH部署创建新版本 - 看起来像这样:1.0.1,1.0.2,1.0 .3,1.0.4等特别是当代码完全相同时.促销允许您(有效地)将发布版本重新部署到具有所有相同NuGet包版本,变量设置和部署过程的另一个环境 - 所有这些都在同一发行版本中.作为一个无耻的自我插件,这是关于这个版本控制问题的博客文章.

是否有关于"何时"创建发布的最佳实践？我要说任何代码更改都需要新版本.您无需创建新版本即可将相同代码移动到其他环境.但是如果你关心版本,你也应该关注版本控制.

总结(TL; DR):

• Octopus Deploy发布的最佳实践受NuGet,NuGet版本控制和发布版本控制的约束.从相对代码的角度来看,您的版本号很重要.您选择哪种类型的发布版本(nuget或变量模板),只是意识到一切都可以并且可能应该链接 - 取决于您的项目的需求.
• 始终将发布升级到另一个环境 - 不要为在另一个环境中部署的相同代码创建新版本.确定哪个环境中的代码是什么令人困惑,这就是促销按钮存在的原因.
• 如果您在部署过程中有一个NuGet包 - 您可以依赖NuGet包版本控制版本.不止一个,切换到可变模板版本控制.

这就是我现在想到的最重要的事情.希望这能澄清事情.