图片：
大家好！ 我们是公司的自动化工程师 我们支持公司产品的开发：我们支持从开发人员提交一行代码到在更新服务器上发布成品和许可证的整个组装管道。 非正式地，我们被称为 DevOps 工程师。 在本文中，我们想讨论软件生产过程的技术阶段、我们如何看待它们以及如何对它们进行分类。
从材料中，您将了解协调多产品开发的复杂性、技术地图是什么以及它如何帮助简化和复制解决方案、开发过程的主要阶段和步骤是什么、责任范围如何在我们公司的 DevOps 和团队之间。
关于混沌和 DevOps
简而言之，DevOps 的概念包括开发工具和服务，以及它们的使用方法和最佳实践。 我们来挑出全球的 目的 从我们公司实施 DevOps 理念来看：这是在数量上（工时或机器时数、CPU、RAM、磁盘等）产品生产和维护成本的持续降低。 在整个公司层面降低总体开发成本的最简单、最明显的方法是 最大限度地减少执行典型串行任务的成本 在生产的各个阶段。 但这些阶段是什么，如何将它们与一般过程分开，它们由哪些步骤组成？
当一家公司开发一种产品时，一切都或多或少是清楚的：通常有一个共同的路线图和开发方案。 但当产品线扩大、产品多了怎么办？ 乍一看，他们有相似的流程和流水线，日志和脚本中的“找X差异”游戏开始了。 但是，如果已经有 5 个以上的项目正在积极开发并且需要支持数年开发的多个版本怎么办？ 我们是否想要在产品管道中重复使用尽可能多的解决方案，或者我们准备好花钱为每个解决方案进行独特的开发吗？
如何在独特性和系列化解决方案之间找到平衡？
自2015年以来，这些问题开始越来越频繁地出现在我们面前。 产品数量不断增长，我们试图将支持这些产品装配线的自动化部门 (DevOps) 扩大到最低限度。 同时，我们希望在产品之间复制尽可能多的解决方案。 毕竟，为什么十种产品以不同的方式做同样的事情呢？
开发总监：“伙计们，我们能以某种方式评估 DevOps 对产品的作用吗？”
我们：“我们不知道，我们没有问这样的问题，但是应该考虑哪些指标？”
开发总监： “谁知道！ 思考…”
就像在那部著名电影中一样：“我在一家酒店！......” - “呃......你能给我带路吗？” 经过反思，我们得出的结论是，首先要确定产品的最终状态； 这成为我们的首要目标。
那么，如何在 10 到 200 人的相当大的团队中分析十几种产品，并在复制解决方案时确定可衡量的指标？
1:0 支持 Chaos，或者肩胛骨上的 DevOps
我们首先尝试应用 IDEF0 图和 BPwin 系列的各种业务流程图。 混乱是在下一个项目下一阶段的第五个方格之后开始的，每个项目的这些方格都可以在 50+ 步骤下画在一条长蟒蛇的尾巴上。 我感到悲伤，想对着月亮嚎叫——它不适合一般情况。
典型生产任务
生产流程建模是一项非常复杂且艰巨的工作：您需要收集、处理和分析来自各个部门和生产链的大量数据。 您可以在文章中阅读更多相关内容““。
当我们开始对生产流程进行建模时，我们有一个特定的目标 - 向参与公司产品开发的每位员工以及项目经理传达：
- 产品及其组件如何从提交一行代码开始以安装程序和更新的形式到达客户，
- 为产品生产的每个阶段提供了哪些资源，
- 每个阶段涉及哪些服务，
- 每个阶段的责任范围如何划分，
- 每个阶段的入口和出口存在哪些合约。
单击图像将以全尺寸打开它
我们在公司的工作分为几个职能领域。 基础设施的方向致力于部门所有“铁”资源运行的优化，以及虚拟机及其上环境部署的自动化。 监控方向提供24/7的服务性能控制； 我们还为开发人员提供监控即服务。 工作流方向为团队提供了管理开发和测试流程、分析代码状态以及获取项目分析的工具。 最后，webdev 方向提供在 GUS 和 FLUS 更新服务器上发布版本，以及使用 LicenseLab 服务的产品许可。 为了支持生产流程，我们为开发人员建立并维护了许多不同的支持服务（您可以在旧聚会上聆听其中一些故事： и）。 我们还开发内部自动化工具，包括 .
五年来，我们的工作积累了很多同类型、常规的操作，我们其他部门的开发人员主要来自于所谓的 典型任务其解决方案是完全或部分自动化的，不会给表演者带来困难，也不需要大量的工作。 我们与主要领域一起分析了这些任务，并能够确定各个工作类别，或者 生产步骤，各个阶段被分成不可分割的步骤，几个阶段相加 生产流程链.
技术链最简单的例子是公司内每种产品的组装、部署和测试阶段。 例如，构建阶段又包含许多单独的典型步骤：从 GitLab 下载源代码、准备依赖项和第 3 方库、单元测试和静态代码分析、在 GitLab CI 上执行构建脚本、在存储库中发布工件通过我们的内部 ChangelogBuilder 工具 Artifactory 和生成发行说明。
您可以在我们关于 Habré 的其他文章中阅读有关典型 DevOps 任务的信息：““和”“。
形成许多典型的生产链 制造过程。 描述流程的标准方法是使用功能性 IDEF0 模型。
制造 CI 流程建模的示例
我们特别关注持续集成系统标准项目的开发。 这使得实现项目的统一成为可能，突出了所谓的 发布构建方案并进行促销.
这是它的工作原理。 所有项目看起来都很典型：它们包括属于 Artifactory 快照存储库的程序集配置，之后在测试台上进行部署和测试，然后提升到发布存储库。 Artifactory 服务是团队和其他服务之间所有构建工件的单一分发点。
如果我们极大地简化和概括我们的发布方案，那么它包括以下步骤：
- 跨平台产品组装，
- 部署到测试台，
- 运行功能和其他测试，
- 推广经过测试的版本以在 Artifactory 上发布存储库，
- 版本的发布建立在更新服务器上，
- 交付组件和生产更新，
- 启动产品的安装和更新。
例如，考虑功能IDEF0模型形式的这种典型发布方案的技术模型（下文简称模型）。 它反映了我们 CI 流程的主要阶段。 IDEF0 模型使用所谓的 国际博物馆协会符号 （输入-控制-输出-机制）描述每个阶段使用什么资源，基于什么规则和要求执行工作，输出是什么，以及特定阶段实施什么机制、服务或人员。
单击图像将以全尺寸打开它
通常，在功能模型中分解和详细描述流程更容易。 但随着元素数量的增加，理解其中的某些内容变得越来越困难。 但在实际开发中，还有辅助阶段：监控、产品认证、工作流程自动化等。 正是由于缩放问题，我们放弃了这种描述。
希望的诞生
在一本书中，我们看到了描述技术流程的苏联旧地图（顺便说一句，这些地图至今仍在许多国有企业和大学使用）。 等等，等等，因为我们也有工作流程！...有阶段、结果、指标、需求、指标等等...为什么不尝试将流程图也应用到我们的产品管道中呢？ 有一种感觉：“就是这样了！ 我们已经找到了正确的线索，是时候把它拉好了！
在一个简单的表格中，我们决定按列记录产品，按行记录技术阶段和产品管道。 里程碑是一些大的事情，例如产品构建步骤。 步骤更小、更详细，例如将源代码下载到构建服务器的步骤或编译代码的步骤。
在地图行和列的交叉点，我们记录了特定阶段和产品的状态。 对于状态，定义了一组状态：
- 没有信息 - 或不合适。 需要分析产品中某个阶段的需求。 要么已经进行了分析，但目前不需要该阶段，或者在经济上不合理。
- 推迟 - 或目前不相关。 需要一个阶段的准备，但今年没有实施的力量。
- 预定的。 该阶段计划于今年实施。
- 实施的。 管道中的阶段按所需数量实施。
表格的填写开始逐个项目进行。 首先，对一个项目的阶段和步骤进行分类并记录其状态。 然后他们开始了下一个项目，修复了其中的状态，并添加了先前项目中缺少的阶段和步骤。 由此，我们获得了整个生产流程的阶段和步骤以及它们在特定项目中的状态。 结果与产品管道能力矩阵类似。 我们将这样的矩阵称为技术地图。
借助技术地图，我们与团队合理协调今年的工作计划以及我们要共同实现的目标：今年项目增加哪些阶段，哪些阶段留到以后。 此外，在工作过程中，我们可能会对仅针对一种产品完成的阶段进行改进。 然后我们扩展地图并将此改进作为一个阶段或新步骤引入，然后我们对每个产品进行分析并找出复制改进的可行性。
他们可能会反对我们：“这当然很好，只是随着时间的推移，步骤和阶段的数量会变得令人望而却步。 怎样成为？
我们对每个阶段、每个步骤的要求都做了规范、比较完整的描述，让公司内部的每个人都能以同样的方式理解。 随着时间的推移，随着改进的引入，一个步骤可能会被另一个阶段或步骤吸收，然后它们就会“崩溃”。 同时，所有要求和技术细微差别都符合概括阶段或步骤的要求。
如何评估复制方案的效果？ 我们使用一种极其简单的方法：将实施新阶段的初始资本成本归因于年度一般产品成本，然后在复制时除以全部。
部分开发项目已在地图上显示为里程碑和步骤。 我们可以通过在典型阶段引入自动化来降低产品成本。 之后，我们考虑定性特征、定量指标和团队获得的利润（以节省的工时或机器工时为单位）的变化。
生产工艺流程技术图
如果我们将所有阶段和步骤都用标签进行编码并将它们展开为一条链，那么它将变得非常长且难以理解（正是我们在文章开头谈到的“python 尾巴”） :
[Production] — [InfMonitoring] — [SourceCodeControl] — [Prepare] — [PrepareLinuxDocker] — [PrepareWinDocker] — [Build] — [PullSourceCode] — [PrepareDep] — [UnitTest] — [CodeCoverage] — [StaticAnalyze] — [BuildScenario] — [PushToSnapshot] — [ChangelogBuilder] — [Deploy] — [PrepareTestStand] — [PullTestCode] — [PrepareTestEnv] — [PullArtifact] — [DeployArtifact] — [Test] — [BVTTest] — [SmokeTest] — [FuncTest] — [LoadTest] — [IntegrityTest] — [DeliveryTest] — [MonitoringStands] — [TestManagement] — [Promote] — [QualityTag] — [MoveToRelease] — [License] — [Publish] — [PublishGUSFLUS] — [ControlVisibility] — [Install] — [LicenseActivation] — [RequestUpdates] — [PullUpdates] — [InitUpdates] — [PrepareEnv] — [InstallUpdates] — [Telemetry] — [Workflow] — [Communication] — [Certification] — [CISelfSufficiency]这些阶段包括构建产品 [Build]、将其部署到测试服务器 [Deploy]、测试 [Test]、根据测试结果将构建提升到发布存储库 [Promote]、生成和发布许可证 [License]、发布 [在 GUS 更新服务器上发布]并传送到 FLUS 更新服务器，使用产品配置管理 [安装] 在客户基础设施上安装和更新产品组件，以及从已安装的产品收集遥测 [遥测]。
除此之外，还可以区分不同的阶段：基础设施状态监控[InfMonitoring]、源代码版本控制[SourceCodeControl]、构建环境准备[Prepare]、项目管理[Workflow]、为团队提供沟通工具[Communication]、产品认证[认证]并确保 CI 流程的自给自足 [CISelfSufficiency]（例如，程序集独立于 Internet）。 我们的流程中的数十个步骤甚至不会被考虑，因为它们非常具体。
如果以形式呈现的话，会更容易理解和查看整个生产流程 技术地图; 这是一个表格，其中模型的各个生产阶段和分解步骤以行形式写入，并以列形式描述每个阶段或步骤所做的事情。 主要重点放在每个阶段提供的资源以及责任范围的划分。
对我们来说，地图是一种分类器。 它反映了产品生产的大量技术部分。 有了它，我们的自动化团队可以更轻松地与开发人员互动，共同规划自动化阶段的实施，并了解为此需要哪些劳动力成本和资源（人力和硬件）。
在我们公司内部，地图是从 jinja 模板自动生成为常规 HTML 文件，然后上传到 GitLab Pages 服务器。 可以查看包含完整生成的地图示例的屏幕截图 .
单击图像将以全尺寸打开它
简而言之，工艺图是生产过程的概括图，它反映了具有典型功能的清晰分类的块。
我们路线图的结构
该地图由几个部分组成：
- 标题区——这里是地图的总体描述，介绍基本概念，定义主要资源和制作过程的结果。
- 仪表板 - 在这里您可以控制单个产品的数据显示，提供所有产品的总体实施阶段和步骤的摘要。
- 技术地图 - 技术流程的表格描述。 在地图上：
- 给出了所有阶段、步骤及其代码；
- 给出了各个阶段的简短而完整的描述；
- 指出每个阶段使用的投入资源和服务；
- 指示每个阶段和单独步骤的结果；
- 标明每个阶段和步骤的责任范围；
- 已经确定了支持现阶段工作所需的技术资源，例如 HDD (SSD)、RAM、vCPU 以及所需的工时，无论是当前（事实）还是未来（计划）；
- 对于每种产品，都标明了已实施、计划实施、不相关或未实施的技术阶段或步骤。
基于技术地图的决策
检查完地图后，可以根据员工在公司中的角色（开发经理、产品经理、开发人员或测试人员）采取一些行动：
- 了解实际产品或项目中缺少哪些阶段，并评估其实施的必要性；
- 划分不同阶段工作的多个部门之间的职责范围；
- 商定舞台入口和出口的合同；
- 将您的工作阶段融入到整体开发流程中；
- 更准确地评估提供每个阶段的资源需求。
总结以上所有内容
该路由具有通用性、可扩展性和易于维护性。 与严格的学术 IDEF0 模型相比，以这种形式开发和维护流程描述要容易得多。 此外，表格描述比功能模型更简单、更熟悉且结构更好。
对于这些步骤的技术实现，我们有一个特殊的内部工具CrossBuilder——CI系统、服务和基础设施之间的层工具。 开发人员不需要砍掉他的自行车：在我们的 CI 系统中，运行 CrossBuilder 工具的脚本（所谓的任务）之一就足够了，考虑到我们基础设施的特性，它将正确执行它。
结果
这篇文章相当长，但在描述复杂过程的建模时这是不可避免的。 最后我想简单说一下我们的主要想法：
- 在我们公司实施 DevOps 理念的目标是在数量上（工时或机器时、vCPU、RAM、磁盘）持续降低公司产品的生产和维护成本。
- 降低总体开发成本的方法是最小化执行典型串行任务的成本：技术过程的阶段和步骤。
- 典型的任务是其解决方案完全或部分自动化、不会给执行者带来困难并且不需要大量劳动力成本的任务。
- 生产过程由阶段组成，阶段又分为不可分割的步骤，是不同规模和范围的典型任务。
- 从不同的典型任务中，我们得出了复杂的技术链和生产过程的多层次模型，这些模型可以通过功能性 IDEF0 模型或更简单的技术图来描述。
- 技术图是生产过程的阶段和步骤的表格表示。 最重要的是：地图可以让您完整地、大块地看到整个过程，并可以详细说明它们。
- 基于技术地图，可以评估在特定产品中引入阶段的需要，划定责任范围，就阶段的输入和输出达成合同，并更准确地评估资源需求。
在接下来的文章中，我们将更详细地描述使用哪些技术工具来实现我们地图上的某些技术阶段。
文章作者：
- — Positive Technologies 自动化 (DevOps) 主管
- - 副手Positive Technologies 自动化部门 (DevOps) 主管
来源： habr.com