我们以某种方式将客户置于一个对象的电子文档管理系统上。 然后到另一个对象。 还有一个。 并在第四和第五。 他们被带走了，以至到达了十个分散的物体。 发生了强大的事情……尤其是在我们交付变更时。 作为为5种测试系统方案提供生产电路的一部分，该过程总共花费了10个小时，并且共有6-7名员工。 这样的成本迫使我们尽可能少地交付。 经过三年的运营，我们受不了了，决定用少量的DevOps对项目进行调味。
现在所有测试都在3小时内通过，有3个人参与其中：一名工程师和两名测试员。 改进明显以数字表示，导致心爱的TTM减少。 根据我们的经验，DevOps可以为更多的客户提供帮助，甚至比那些了解的客户还多。 因此，为了使DevOps更加贴近人们，我们开发了一个简单的构造函数，我们将在本文中详细讨论。
现在我们将更详细地讲。 在一家拥有10家大型设施的能源公司中，正在部署技术文档管理系统。 在没有DevOps的情况下，要进行如此大规模的项目并不容易，因为大量的体力劳动会大大延迟工作并降低质量-所有体力劳动都充满了错误。 另一方面，在某些项目中，安装是一个项目，但是有必要使所有内容自动，连续且无故障地工作-例如，大型整体组织中的相同文档管理系统。 否则，有人会手动进行设置，而忽略了部署说明-结果，设置将丢失在产品上，并且所有操作都会崩溃。
通常，我们通过合同与客户合作，在这种情况下，我们的利益会有所不同。 客户严格在预算和传统知识范围内看项目。 很难向他解释不属于传统知识的各种DevOps实践的好处。 如果他对快速增值的业务感兴趣，那么他会建立自动化管道吗？
las，在使用预先批准的价值时，并非总是可以找到这种兴趣。 在我们的实践中，有时候我们不得不选择一个不道德和不准确的承包商。 令人恐惧的是：没有实际的源代码，同一系统在不同安装上的代码库是不同的，文档部分丢失，部分质量很差。 当然，客户没有源代码控制，组装，发布等。
到目前为止，并不是每个人都对DevOps有所了解，但是值得一提的是它的优势，真正的资源节省，所有客户的目光都在闪耀。 因此，随着时间的推移，涉及DevOps的请求越来越多。 在这里，为了轻松地与客户说同一语言，我们需要快速联系业务问题和DevOps实践，这将有助于建立合适的开发渠道。
因此，我们一方面存在一系列问题，另一方面存在知识，实践和DevOps工具。 为什么不与大家分享经验？
创建一个DevOps构造函数
敏捷有其自己的宣言。 ITIL有其自己的方法。 DevOps不太幸运-它尚未获得模板和标准。 尽管
有些 公司试图根据对公司发展和运营方法的评估
来确定公司的成熟度。
幸运的是，臭名昭著的Gartner公司在2014年
收集并分析了主要的DevOps实践及其之间的关系。 基于此，我发布了信息图：
我们将其作为
构造函数的基础。 在这四个领域中的每一个领域，都有一套工具-我们将它们收集在数据库中，确定了最受欢迎的，确定的集成点以及合适的优化机制。 总共有
36种实践和115种工具 ，其中四分之一是开放或免费软件。 接下来，我们将讨论我们在每个领域中所做的事情，例如，如何在项目中实施该工作以创建技术工作流，并以此为起点。
流程
在臭名昭著的EDMS项目中，在10个工厂中的每个工厂都按照相同的方案部署了技术文档管理系统。 该安装包括4台服务器：数据库服务器，应用程序服务器，全文索引和内容管理。 在安装中，它们在单个节点内工作，这些节点位于设施的数据中心中。 所有对象的基础结构都略有不同，但这不会干扰全局交互。
首先，根据DevOps的惯例，我们在本地实现了基础架构的自动化，然后将交付的产品带到了测试电路中，然后又提高了客户的生产率。 每个过程都是逐步完成的。 环境设置在源代码系统中是固定的，要考虑到收集了分发以进行自动更新。 在配置发生更改的情况下，工程师只需对版本控制系统进行适当的更改-然后自动更新将顺利通过。
由于采用了这种方法，大大简化了测试过程。 以前，项目中只有测试人员才手动更新机架。 现在他们来了，看到一切都起作用了，并且正在从事更多有用的事情。 每次更新都会自动进行测试-从表面级别到业务场景的自动化。 结果在TestRail中布置为单独的报告。
文化文化
连续实验最好通过测试设计来解释。 测试尚不存在的系统是一项创造性的工作。 在编写测试计划时，您需要了解如何正确进行测试以及要经过的分支。 并且在时间和预算之间找到平衡，以便确定最佳的支票数量。 重要的是准确选择必要的测试，考虑用户如何与系统交互，并考虑环境和可能的外部因素。 您不能没有持续的实验。
现在介绍互动文化。 过去有两个交战方-工程师和开发人员。 开发人员说：
“我们不在乎它是如何开始的。 您是工程师，您很聪明，可以让它正常运行 。
” 工程师回答：
“您的开发人员太鲁re了。 让我们更加小心，我们将减少发布您的版本的频率。 因为每次您给我们提供一个有漏洞的代码，我们之间的交互方式都不清楚 。
” 从DevOps的角度来看，这是一个文化交互问题，其构建方式有所不同。 在这里，您既有工程师又是开发人员，他们属于一个团队，致力于不断变化，但同时又可靠的软件。
在一个团队的规模上，专家可以互相帮助。 以前怎么样 例如，正在准备某种密集的部署说明，每页50页。工程师阅读了该说明，听不懂，发誓并要求开发人员在凌晨三点发表评论。 开发人员发表评论并发誓-最终，没有人高兴。 另外，自然会有一些错误，因为您将不会记住指令中的所有内容。 现在，工程师与开发人员一起正在编写用于自动部署应用程序软件基础结构的脚本。 他们几乎用相同的语言互相交谈。
人
团队的规模取决于更新的程度。 该团队是在供应形成期间招募的，其中包括那些希望从一般项目团队中获得的人才。 然后，编写更新计划，负责团队的每个阶段，并报告每个阶段。 所有团队成员均可互换。 作为团队的一部分，我们还有一个安全开发人员，但是他几乎从来不需要联系。
技术领域
在技术方案中，突出了一些要点，但在它们的下面是一堆技术-借助它们的描述，您可以发行整本书。 因此，我们将重点介绍最有趣的部分。
基础架构即代码
现在，也许您不会对使用此概念的任何人感到惊讶，但是在对基础结构进行描述之前，尚无所求。
工程师惊恐地看着说明书 ，测试环境是独特的，它们受到照顾和珍惜，灰尘从其中吹散。
现在没有人害怕尝试。 有虚拟机的基本映像，有用于部署环境的现成方案。 所有模板和脚本都存储在版本控制系统中，并且可以快速更新。 以前，当需要将包装交付到展台时，会出现配置间隙。 现在，您只需要在源代码中添加一行即可。
除了基础结构方案和管道之外，“文档即代码”方法也用于文档编制。 因此，很容易将新人员连接到项目，通过例如测试计划中所述的功能将他们引入系统，并重用测试用例。
持续交付和监控
在上一篇有关DevOps的
文章中 ，我们讨论了如何选择工具来实现连续交付和监视。 通常，无需重写任何内容-使用以前编写的脚本，正确地在组件之间建立集成并创建通用的管理控制台就足够了。 而且所有过程都可以通过一个按钮或时间表开始。
英文，持续交付和持续部署有不同的概念。 两者都可以翻译为“连续交付”，但实际上它们之间存在细微差别。 在我们用于分布式能源公司的技术文档管理的项目中，将使用“交付”，而不是按命令执行销售安装。 在部署中，安装是自动的。 该项目中的持续交付通常已成为
DevOps的
核心部分 。
通常，通过收集某些参数，您可以清楚地了解DevOps实践为何有用。 并将其传达给非常喜欢数字的领导层。 启动总数，脚本各阶段的执行时间，成功启动的份额-所有这些直接影响每个人最喜欢的上市时间，即从提交到版本控制系统到在生产环境中发布版本的时间。 通过引入必要的工具，工程师可以通过邮件接收有价值的指标，项目经理可以在仪表板上看到它们。 因此，您可以立即欣赏新工具的好处。 您可以使用DevOps构造函数在基础架构上尝试使用它们。
我们不会作弊：对于初学者来说，他对我们很有用。 正如我们已经说过的那样，客户需要说相同的语言，在DevOps构造函数的帮助下，我们可以快速概述这种对话的基础。 业务专业人员将能够评估自己的需求，从而更快地发展。 我们试图使构造函数尽可能详细，并添加了一堆描述，以便任何用户都能理解他的选择。
设计人员的格式允许您考虑公司在构建过程和自动化方面的现有经验。 如果您只能选择通常可以集成到现有流程中的，可以填补空白的解决方案，则不必分解一切并进行重建。
也许您的开发已经移到了更高的水平，我们的工具似乎太“上尉了”。 但是我们发现它对自己有用，并希望它对某些读者有用。 我们提醒您
指向构造函数的
链接 -如果有的话，您在输入源数据后立即获得电路。 我们将感谢您的反馈和补充。