Get best of the week

CI / CD流程更新：teamcity

图片
这是有关更新CI / CD流程的系列文章中的第二篇。到目前为止，正在为建立新工具做准备，即：总体而言，计划，集会，解决分歧，否则，就无法有效地建立工作流程。现在，所有问题都已解决，我们相信我们可以继续开发，并且我们的代码不会在夏季开始时陷入困境。 

让我提醒您文章列表的目录以及上一部分的简要结果。

第1部分：是什么，为什么不喜欢，计划，要花点时间。我将这部分称为技术性的。
第2部分：团队合作精神。
第3部分：章鱼部署。
第四部分：幕后花絮。不愉快的时刻，对未来的计划，可能是常见问题解答。最有可能的是，它也可以称为近技术。

我们为客户提供了新的更新交付系统的概念验证，确定了现有系统的缺点，选择了新系统的基础，制定了过渡计划，并将我们的商业资料库转换为git。另外，在上一部分中，我们描述了将影响整个后续过程的项目功能。 

如前所述，现有解决方案不符合现代要求。最初，很可能是在ccnet中配置了一个内部版本。一切开始的第一个构建（是的，就像是大爆炸一样）。然后，很明显，将其全部设置好的人按下了ctrl + c，ctrl + v，更正了几行，并获得了新的配置。在随后的所有时间内，此操作进行了足够的次数，因此构建服务器上的源代码占用了60G以上的内存。这些只是来源！还有日志，构建工件，临时文件等。只有这让我思考。查看旧系统，可能会看到以下内容：每个模块都执行了构建步骤。实际上，组装了相同的核心。并将该程序集存储在服务器上的每个模块（以及源代码）中。构建结果（90％相同）被推送到本地存储库（git部署）中，当然也取代了它们。离开这是可能的，也是必要的。 

常规设置 


在此阶段，假定已经存在一个已配置的团队协作和章鱼。在安装和配置阶段，我们不会详细介绍。为方便起见，我们在env teamcity中记下章鱼的url和api令牌，顺便说一句，对于根项目，它看起来像这样：

图片

env.apiUserName和env.apiUserPassword是对teamcity用户的api访问权限（稍后需要），env.buildPath和env .sourcePath-生成文件和源文件的默认路径，分别为env.octoApiKey和env.octoUrl-章鱼的标记和URL。他们仍然env.teamcityUrl添加。好吧，env.tt.exe-文本转换实用程序的路径。该实用程序会生成所有配置。

在第三方插件中，仅安装了Octopus Deploy集成。 

为了不使已经大量的文本过载，将仅详细检查其中有一些值得注意的步骤。假定根据呈现的数据和读者的知识，其他所有内容都是可以理解的。无论如何，如果您有任何问题，我将很乐意回答。

项目细目，版本，名称


结果就是这样的项目方案（如图所示，因为显示多级列表存在问题）：
图片

我们将对软件包进行以下版本控制：major.minor.patch，到目前为止，major是1，minor是Build配置的构建计数器，patch是配置的构建计数器部署（构建配置不需要，因此始终为0）。

注意：此处描述了旧版本。我们正在重新设计它，使其基于git标签。

图片

例如，这里1为主要，95为次要，1为补丁。

在新的模块流程中，将只有一个构建，然后将其部署到每个模块。也就是说，对于每个环境，源代码都存储在一个副本中，构建结果也是如此，因为它对于所有模块都是通用的。在部署阶段，将独特的配置和库打包在单独的软件包中。这将有效利用磁盘空间并减少每个软件包的交付时间。

在准备阶段，将召开一次单独的简短会议，讨论命名配置文件的约定。它曾经是（过去），但并不总是一样。此外，配置名称并不总是包含足够的信息。结果，所有配置名称如下：
ConfigurationType.Environment.ModName.config其中ConfigurationType可以是AppSettings，Web等。环境-开发，测试，分段，生产。ModName是模块的唯一名称。

模组


所有模块项目均基于相同的原理。 

每个环境都有一个Build配置：

  1. 执行nuget恢复（NuGet安装程序，nuget恢复）
  2. 生成配置（命令行，文本转换）
  3. Buildit解决方案（Visual Studio sln）
  4. 从zip中的env.buildPath中拾取文件并将其推送到octopus（Octopus部署：推送包）
  5. 创建发行版（不部署）（Octopus部署创建发行版）
  6. 重置补丁程序版本（PowerShell）

也有基于模板工作的部署配置，并执行以下操作：

  1. 拾取在构建阶段（步骤2）生成的配置（Octopus部署推包）
  2. 部署核心版本（在构建的第6步中创建）（Octopus部署：部署版本）
  3. 部署个人版本（在当前配置的步骤1中创建）（Octopus部署：部署版本）
  4. 在日志中显示此模块的所有域的列表（方便测试人员和开发人员的步骤）。（电源外壳）。

对于每个部署配置，将构建配置添加到依赖项。这样就可以在部署不相关的构建时自动启动该构建，并可以重置补丁程序版本。

Deploy_all配置。实际上，这是一个构建链，描述了您首先需要运行不相关的构建，然后同时安装所有模式。

看起来像这样：

图片

让我们更详细地看一些步骤。

Build.General设置


图片

从不寻常的唯一内部版本号格式开始。稍后将说明。

Build.env


图片

这里有趣的是：
env.coreProjectName-为整个项目设置。需要识别章鱼中的项目。
env.Environment-为“模块”子项目设置。有必要根据环境选择正确的配置。
env.octoChannel-八达通中的数据包所属的通道。同样作为env.Environment。
env.serviceName是解决方案的名称。基本上，添加变量是为了便于可视化。
env.tenantRoleTag-章鱼中的租户标签。章鱼部分中有更多详细信息。

Build.4


图片

从目录中 添加名称为％env.serviceName％。％Build.number％.zip文件的归档文件，其中包含生成结果（不包括所有配置）以及bin / native文件夹中的dll。最后一个被手动添加到Web服务器一次，没有人会再次触摸它们。如有必要，它们也将手动更新（为此，计划编写一个单独的脚本，但是老实说）。这是由于以下事实：这些库由IIS池“保留”，并且为了成功进行部署，必须停止然后启动它，这需要一些时间。通过从部署中排除这些库，我们可以跳过停止池的步骤，这将减少部署时间，从而减少停机时间。

版本5


图片

我认为这里的一切都很清楚，除了“环境”字段为何为空。章鱼在哪个包装中得到包装，章鱼根据预发布标签（在通道中配置）做出决定。此标记包含在％build.number％中（在Build.General屏幕上相同的阶段）。因此，在这种情况下，它更加方便。还应注意“显示部署过程”复选框。如果未安装，章鱼会在开始（但尚未完成！）工作后立即将其视为成功。也就是说，如果未安装此复选框，并且在部署阶段出了点问题-如果不查看章鱼界面，我们将一无所知。

版本6


没什么不寻常的，只是powershell脚本和teamcity文档中的信息。

$pair = "%env.apiUserName%:%env.apiUserPassword%"
$encodedCreds = [System.Convert]::ToBase64String([System.Text.Encoding]::ASCII.GetBytes($pair))
$basicAuthValue = "Basic $encodedCreds"
$depUri="%env.teamcityUrl%/app/rest/buildTypes?locator=snapshotDependency:(from:(build:(id:%teamcity.build.id%)),includeInitial:false)"
# Get all dependencies of main build
$result = (Invoke-RestMethod -Headers @{'Origin'='http://localhost:8090'; "Authorization"="$basicAuthValue"} -Uri $depUri)
foreach ($i in $result.buildTypes.buildType.Count) { $buildId += $result.buildTypes.buildType.id }
$buildId = $buildId | Where-Object { $_ -ne 'Module_DeployAll' }
# Reset all child build counters to 1. This build counters are patch versions in every build. (1.build.patch)
for ($i=0; $i -lt $buildId.Count; $i++) {
  $buildCounterUri = "%env.teamcityUrl%/httpAuth/app/rest/buildTypes/"+$buildId[$i]+"/settings/buildNumberCounter"
  Invoke-RestMethod -Method Put -Headers @{'accept'='text/plain'; 'Origin'='http://localhost:8090'; "Authorization"="$basicAuthValue"} -Uri $buildCounterUri -ContentType "text/plain" -Body 1
}

在这里，我们需要teamcity中的api用户（为他创建了env）。我们登录，获取所有依赖于Build配置的配置，然后将其构建计数器重置为1。也就是说，实际上，对于每个补丁程序版本，这表明一个特定的模块部署了相同的构建多少次。如果不为1，则表示在当前版本上部署或使用模块的过程出了点问题，需要引起注意。

常规部署


图片

版本格式：1.％dep.Module_Build.build.counter％。％Build.counter％-staging，其中
％dep.Module_Build.build.counter％是teamcity系统变量，其值对应于相应Build配置的构建计数器（应添加到依赖项）。实际上，这里是主要版本1，％dep.Module_Build.build.counter％是次要版本，％build.counter％是补丁。登台是一个预发布标签。

部署环境


图片

添加新模块时，仅添加用于其部署的配置，并指示env.modName变量的值。所有其他变量均从父项目继承。章鱼的env.tenantModTag变量由env.modName形成。

部署2


图片

部署核心软件包。 

最新发行版号-使用此环境的最新可用发行版。
租户标签-客户/组织标签。章鱼部分中有更多详细信息。
其他cli参数。在这里，我们指示包将落入的通道以及其他参数。章鱼部分将对此进行单独讨论。

部署3


与Deploy.2一样，仅部署单个模块程序包。

部署4


此步骤还将在下面详细描述，因为它从章鱼接收数据。

公司网站和特殊模块的配置基于相同的原理，并且它们的主要要点是相同的，因此我看不到对其进行详细描述的要点。它们是一个，不需要多次部署，实际上有nuget restore，文本转换，msbuild，章鱼推送，章鱼创建发布+部署。

了解有关独特配置的更多信息。对于某些mod，可能没有任何环境（例如，暂存），必须将它们部署到其他服务器，或者您必须手动设置客户端标识符（采用基本配置并使用powershell更改其中的某些字段）。也就是说，它们以与主要模块相同的原理工作。它们的独特之处在于为它们添加/更改了步骤，或者更改了部署服务器并且它们不适合模板，因此创建它们需要花费更长的时间。幸运的是，他们很少。

Teamcity：摘要


团队合作精神的实现为应用程序组装过程提供了更优化的方法。现在，它花费的时间大大减少：我们不必每次都构建相同的代码，而是只需构建一次。我们还更好地利用了磁盘空间，网络流量和计算时间。以前，用于部署的软件包（带有工件的存储库）的数量等于模块的数量。每个包装以压缩形式重约100M。现在，我们的软件包数量比模块数量多一，一个软件包的重量大约为100M，其余的大约为500K。加上更友好的用户界面，方便的日志记录，最重要的是-减少了维护构建系统和添加配置的时间。现在添加新模块需要15分钟到半小时。

另外，应该说说模板，因为标准化使我们节省了创建新配置及其进一步维护的时间。与章鱼互动（部署）的所有配置都基于单个模板构建。首先，它可以统一并简化流程。其次，如前所述，它节省了添加新配置的时间：我们已经连接了模板，更改了一个变量，仅此而已。最重要的是，模板简化了维护。对模板所做的所有更改均由基于模板的配置继承。因此，如果我们需要一次将步骤添加到所有配置中，则无需全部单击它们，只需将此步骤添加到模板中即可。

自然，teamcity设置过程与章鱼设置同时进行。由于存在很大的混淆的可能性，因此根本不可能在文本中进行并行描述。因此，已经共享了描述，并且在这一部分中仅描述了提供CI的步骤。章鱼的设置过程将在下面描述。

More articles:


All Articles