图片：未飞溅大家好！ 我们是
Positive Technologies的自动化工程师，我们支持公司产品的开发：我们支持整个组装生产线，从开发人员提交一系列代码到在更新服务器上发布最终产品和许可证。 非正式地，我们称为DevOps工程师。 在本文中，我们要讨论软件生产过程的技术阶段，如何看待它们以及如何对其进行分类。
从材料中，您将了解协调多产品开发的复杂性，工作流程是什么以及如何帮助组织和复制解决方案，开发过程的主要阶段和步骤是什么，DevOps和我们公司的团队之间的职责划分方式。
关于Chaos和DevOps
简短地注意，DevOps的概念包括开发工具和服务，以及使用它们的方法和最佳实践。 我们将通过在公司中引入DevOps构想来挑出全球
目标 ：这从数量上（工时或机时，CPU，RAM，磁盘等）定量降低了生产和维护成本。 降低公司一级开发总成本的最简单，最明显的方法是
最小化在生产的所有阶段
执行典型的串行任务的成本 。 但是这些阶段是什么，如何将它们与一般过程区分开来，它们包括哪些步骤？
当公司开发单个产品时，一切都差不多了：通常会有一个共同的路线图和开发计划。 但是，当产品线扩展并且有更多产品时该怎么办？ 乍一看，他们具有相似的流程和组装线，并且开始在日志和脚本中进行“发现X差异”游戏。 并且，如果已经有5个以上的项目正在积极开发中，并且您需要几年来开发的多个版本的支持？ 我们是否要在产品传送带中重复使用尽可能多的解决方案，还是准备为每种解决方案花钱进行独特的开发？
如何在解决方案的唯一性和串行性之间找到平衡？
自2015年以来，这些问题开始越来越频繁地出现在我们面前。 产品数量在增长，我们试图最大程度地减少我们自动化部门（DevOps）的扩张，该部门为这些产品的装配线提供了支持。 同时，我希望在产品之间复制尽可能多的解决方案。 毕竟，为什么在十种产品中以不同的方式进行相同的事情？
开发总监 ：“伙计们，我们可以以某种方式评估DevOps对产品的作用吗？”
我们 ：“我们不知道，我们没有问自己这个问题，但是应该考虑哪些指标？”
发展总监 ：“谁知道呢！ 想想...”
就像在著名的电影中一样：“到我的旅馆！..”-“呃……你会指引路吗？” 思考之后，我们得出的结论是，首先您需要确定产品的最终状态； 这是我们的首要目标。
因此，在复制解决方案时，您如何分析具有10至200人的足够大团队的十几种产品并确定可衡量的指标？
1：0有利于肩blade骨上的混沌或DevOps
我们首先尝试应用BPwin系列中的IDEF0图和各种业务流程图。 混乱从下一个项目下一个阶段的第五个框开始，每个项目的这些正方形都可以在50多个步骤之后绘制到长蟒蛇的尾部。 我很伤心，想哭到月球-总体来说不合适。
典型的生产任务
对生产过程进行建模是一项非常复杂且艰苦的工作：您需要收集，处理和分析有关各个部门和生产链的大量数据。 您可以在文章“
IT公司中的生产流程建模 ”中阅读有关此内容的更多
信息 。
当我们开始对生产过程进行建模时，我们追求一个特定的目标-向参与公司产品开发的每个员工以及项目经理传达：
- 从一行代码开始，产品及其组件如何以安装程序和更新的形式到达客户，
- 为产品的每个生产阶段提供了哪些资源，
- 每个阶段涉及哪些服务，
- 在每个阶段如何区分责任领域，
- 在每个阶段的输入和输出中存在哪些合同。
通过单击图片将以完整尺寸打开我们在公司的工作分为几个职能领域。 基础架构的方向是优化部门所有“铁”资源的运营，以及自动部署虚拟机及其上的环境。 监控方向提供24/7服务健康监控； 我们还为开发人员提供监视即服务。 工作流方向为团队提供了用于管理开发和测试过程，分析代码状态以及获得项目分析的工具。 最后，webdev在GUS和FLUS更新服务器上提供发布版本，并使用LicenseLab服务提供许可产品。 为了支持生产管道，我们为开发人员设置并维护了许多不同的支持服务（您可以在旧的mitap上收听其中的一些故事：
Op！DevOps！2016和
Op！DevOps！2017 ）。 我们还开发了内部自动化工具，包括
开源解决方案 。
在过去的五年中，我们的工作中积累了许多相同类型和常规的操作，并且来自其他部门的开发人员主要提出了所谓的
标准任务 ，其解决方案全部或部分自动化，不会给表演者带来麻烦，也不需要大量工作。 连同主要指示，我们分析了此类任务，并能够区分某些类别的工作或
生产阶段 ，将这些阶段划分为不可分割的步骤，并且
生产技术链包括多个阶段。
技术链的最简单示例是公司内部每个产品的组装，部署和测试阶段。 反过来，例如，构建阶段包括许多单独的典型步骤：从GitLab下载源代码，准备依赖项和第三方库，单元测试和静态代码分析，在GitLab CI上执行构建脚本，将工件发布到Artifactory上的存储库并通过内部工具ChangelogBuilder生成发行说明。
您可以在Habré上的其他文章中阅读有关典型DevOps任务的信息：“
个人经验：我们的持续集成系统的外观 ”和“
开发过程的自动化：我们如何在Positive Technologies中实现DevOps的想法 ”。
许多典型的生产链构成了
生产过程 。 描述过程的标准方法是使用功能性IDEF0模型。
对生产CI流程进行建模的示例
我们特别关注持续集成系统的模型项目的开发。 这使我们能够实现项目的统一，突出了
带有进步的所谓的
发布组装方案 。
运作方式如下。 所有项目看起来都是典型的：它们包括程序集的配置，这些程序集落入Artifactory上的快照存储库中，然后在测试台上进行部署和测试，然后将其升级到发布存储库。 Artifactory服务是团队和其他服务之间所有构建工件的单点分发。
如果我们大大简化和概括了发布方案，那么它包括以下步骤：
- 跨平台产品组装，
- 部署到测试台，
- 运行功能测试和其他测试，
- 推广经过测试的版本以发布Artifactory上的存储库，
- 发布发布版本以更新服务器，
- 交付装配和生产更新，
- 启动安装和产品更新。
例如，以功能性IDEF0模型的形式考虑此典型发布方案的技术模型（以下简称为模型）。 它反映了我们CI流程的主要阶段。 IDEF0模型使用所谓的
ICOM表示法 （Input-Control-Output-Mechanism），根据什么规则和要求，完成什么，输出什么以及什么机制，服务或人员来描述每个阶段使用的资源实施特定阶段。
通过单击图片将以完整尺寸打开通常，在功能模型中，更容易分解和详细描述过程。 但是随着元素数量的增加，要理解它们变得越来越困难。 但是在实际开发中，还存在辅助步骤：监视，产品认证，工作流程自动化等。 由于缩放问题，我们放弃了这样的描述。
希望的诞生
在一本书中，我遇到了描述技术过程的旧苏联地图（顺便说一下，现在许多国营企业和大学都在使用这些地图）。 等待，等待，因为我们还有一个技术流程！..有阶段，结果，度量，要求，指标等，等等……为什么不尝试将技术图应用到我们的产品输送机上呢？ 有一种感觉：“在这里！ 我们找到了正确的螺纹，是时候把它拉好！”
在一个简单的表格中，我们决定将产品固定在列中，并将行固定在产品传送带的技术阶段和步骤中。 阶段-这很重要，例如，产品组装的阶段。 而且这些步骤更小，更详细，例如，将源代码下载到构建服务器的步骤或编译代码的步骤。
在地图的行和列的交点处，我们放下特定阶段和产品的状态。 对于状态，已经定义了许多状态：
- 没有数据 -或不切实际。 有必要对产品中阶段的相关性进行分析。 要么已经进行了分析，但是当前不需要该阶段或在经济上不合理。
- 已推迟 -或暂时不相关。 传送带上需要一个平台，但是今年没有实施的力量。
- 预定的 。 该阶段计划于今年实施。
- 它已实现 。 输送机中的载物台以所需的体积实现。
填表始于项目。 首先，对一个项目的阶段和步骤进行分类，并记录其状态。 然后他们参加了下一个项目，在其中记录了状态，并添加了先前项目中缺少的步骤。 结果，我们获得了整个生产输送机的阶段和步骤以及它们在特定项目中的状态。 事实证明，这类似于产品传送带的能力矩阵。 我们称这种矩阵为技术图。
使用技术地图，我们在计量上合理地协调了我们希望共同实现的团队年度工作计划和目标：我们将今年添加到项目中的哪些阶段，以及以后再考虑的阶段。 此外，在工作过程中，我们可能仅对一种产品执行的阶段就会有所改进。 然后，我们扩展地图，并在阶段或新步骤中介绍此改进，然后分析每种产品并找出复制改进的权宜之计。
他们可能会反对我们：“这当然是一件好事，只有随着时间的流逝，步骤和阶段的数量才会变得过大。 怎么做？”
我们已经对每个阶段和步骤的要求进行了标准且足够完整的描述，以使公司内部所有人都能平等地理解它们。 随着时间的推移，在引入改进时，可以将一个步骤吸收到另一个步骤或另一个步骤中，然后它们将“崩溃”。 同时，所有要求和技术差异都适合于概括阶段或步骤的要求。
如何评估重复决策的效果？ 我们使用一种非常简单的方法：将实施新阶段的初始资本成本归因于年度常规食品成本，然后在复制时将其分为所有。
开发的某些部分已经作为步骤和步骤反映在地图上。 通过引入典型阶段的自动化，我们可以影响产品成本的降低。 之后，我们考虑定性特征，定量指标和团队获得的利润（以节省的工时或机器工时为单位）的变化。
工艺流程图
如果我们采取所有阶段和步骤，使用标签进行编码并在一个链中扩展，那么结果将是非常漫长且令人费解的（只是我们在本文开头谈到的“ 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更新服务器上发布[Publish]的阶段。并提供给FLUS更新服务器，使用产品配置管理[Install]在客户的基础架构上安装和更新产品组件，以及从已安装的产品中收集遥测技术。
除它们之外，还有单独的阶段：监视基础结构的状态[InfMonitoring]，源代码版本控制[SourceCodeControl]，准备组装环境[Prepare]，项目管理[Workflow]，为团队提供沟通工具[Communication]，产品认证[Certification]并提供CI流程的自足性[CISelfSufficiency]（例如，程序集与Internet的独立性）。 我们甚至不会考虑流程中的数十个步骤，因为它们非常具体。
如果以
技术图的形式呈现，将更容易理解和了解整个生产过程； 这是一张表格，其中模型的各个生产步骤和分解步骤以行形式编写，而各列则描述了在每个步骤或步骤中要执行的操作。 主要重点放在提供每个阶段的资源以及职责范围的划分上。
对我们来说，地图是一种分类器。 它反映了粮食生产的主要技术部分。 有了它，我们的自动化团队可以更轻松地与开发人员进行互动，共同计划自动化阶段的实施，并了解需要哪些劳动力和资源（人力和铁）。
在我们公司内部，地图是由Jinja模板自动以常规HTML文件的形式生成的，然后上传到GitLab Pages服务器。 可以在
此处查看带有完整生成的地图示例的屏幕截图。
通过单击图片将以完整尺寸打开简而言之，流程图是生产过程的概括图，反映了具有典型功能的清晰分类的模块。
路由的结构
该地图包括以下几部分：
- 标题区域-这是地图的一般说明，介绍了基本概念，确定了生产过程的基本资源和结果。
- 信息面板-您可以在此处控制单个产品的数据显示，概述所有产品通常采取的步骤。
- 技术地图-对技术过程的表格描述。 在地图上：
- 给出了所有阶段，步骤及其代码；
- 简要概述了各个阶段；
- 说明了每个阶段使用的投入资源和服务；
- 标明了每个阶段和每个步骤的结果；
- 指出了每个步骤和步骤的责任范围；
- 确定当前阶段（事实）和将来（计划）的技术资源，例如，HDD（SSD），RAM，vCPU和支持该阶段工作所需的工时；
- 对于每种产品，应指出已实施，计划实施，不相关或未实施的技术步骤。
基于技术图的决策
检查完地图后，可以采取一些措施-根据员工在公司中的角色（开发经理，产品经理，开发人员或测试人员）：
- 了解实际产品或项目中缺少哪些步骤，并评估其实施的必要性；
- 如果多个部门处于不同阶段，则要区分其职责范围；
- 在舞台的进出口处就合同达成协议；
- 将您的工作阶段整合到整个开发过程中；
- 更准确地评估提供每个阶段的资源需求。
总结以上所有内容
路由通用，可扩展且易于维护。 与严格的学术IDEF0模型相比，以这种形式开发和维护过程描述要容易得多。 此外，表格描述比功能模型更简单，更熟悉并且结构更好。
对于步骤的技术实施，我们负责特殊的内部工具CrossBuilder-CI系统，服务和基础结构之间的中间层工具。 开发人员无需看自行车：在我们的CI系统中，运行CrossBuilder工具的脚本之一（所谓的任务）就足够了，它会考虑到我们基础架构的特殊性而正确地执行它。
总结
文章篇幅相当长，但这在描述复杂过程的建模时是不可避免的。 最后，我想简要地修正我们的主要思想：
- 在我们公司中引入DevOps想法的目的是从数量上（工时或机时，vCPU，RAM，磁盘）定量降低公司产品的生产和维护成本。
- 降低开发总成本的一种方法是将执行典型的串行任务的成本降至最低：工艺过程的阶段和步骤。
- 典型的任务是其解决方案全部或部分自动化的任务，不会给执行者造成困难，也不需要大量的人工成本。
- 生产过程包括阶段，阶段分为不可分割的步骤，这是不同规模和数量的典型任务。
- 从完全不同的典型任务开始，我们进入了生产过程的复杂技术链和多层次模型，这些模型可以通过功能性IDEF0模型或更简单的流程图来描述。
- 工艺路线是制造过程中各个步骤的表格表示。 最重要的是：该地图使您可以查看整个过程，包括大块的细节图。
- 根据技术图谱，可以评估在特定产品中实施阶段的需求，以区分责任领域，就阶段的投入和产出达成协议，以更准确地评估对资源的需求。
在以下文章中，我们将更详细地讨论在地图上使用哪些技术工具来实现某些技术阶段。
本文作者：