前言
这一切都始于2年前，而我转入了托木斯克国立控制系统和无线电电子大学（TUSUR）的“商业信息学”专业的四年级。 直到大学毕业，剩下的时间不多了，写文凭的前景已经迫在眉睫。 没有考虑购买完成的作品的想法。 我真的很想自己做点什么。 文凭项目的主题有很多选择：用于使公司的生产需求自动化的配置项目和用于3个地区单位和500多个活跃用户的独立实施文档管理的项目以及引入EDI。 简而言之，很多事情都在我的脑海中，但是这些都没有启发。 这就是主要的事情。
那时，我在一家著名的公司工作，在业务问题上，我遇到了一个很酷的程序员，而且遇到了一个好人Andrei Shcheglov（嗨，Andrei！）。小黄瓜脚本语言。 我收到的答复是，没有，我没有听到。 自然，傍晚的google / Yandex和不眠之夜导致人们想到这里-未知世界。 但是这种想法可能是论文的主题还没有出现。 正如您对手动测试所了解的那样，例行工作是1C Configurator任务方面的常规工作，并且不允许您完全沉浸于1C世界中的新方法中。
陌生的概念
我遇到的第一个困难是我从来没有听说过的大量不同的术语和工具-因为那时我是一个“典型的odnosnik”（这时霍利瓦尔人开始了……）尤其是不了解任何其他编程语言，以及此外，大型IT的方法对我来说是完全陌生的，我不得不从一个主题跳到另一个主题，至少以某种方式填补了我的词汇表。
几乎同时，我（我们-和我的同事）面临一个相当具体的问题。 他们从承包商那里获得了软件模块，检查了副本。 一切似乎都正常。 但是由于工作量很大，他们签署了一项已完成工作的法案，并将其投入生产。 六个月来一切都很好，直到该子系统中的数据没有超出允许范围。 非常奇怪的事情开始发生。 从模块执行文档开始发生了5-10分钟，出现了很多错误，等等。 查看程序代码令人恐惧（接受之前，请不要问为什么没有这样做）。 嵌套循环的数量刚刚超出合理范围。 在第四个周期中，唯一的要求是上诉，并要求获得4分的上诉是琐碎的事情，它遍历所有以前的文档以填写当前文档，是同一块的10倍复制粘贴，等等。
嵌套示例：
布局中的字段重复：
此外，要填写这些字段，请进行14折复印。
周期开始：
直到FF变量达到15：
好吧，还有一堆其他同样独特的艺术品。
突然我想起来，对于OneScript，有一个简单的库可以计算模块（1）的“环性”（模块或方法的复杂性）。 找到，计算。 我得到163个单位的值，有效值不超过10。得出的结论是，程序代码的验收测试应该是强制性的，并且应该是自动且连续的。 然后我了解了连续检查-事实证明，在2006年，IBM发行了（2）本主题的出版物。
更进一步。 大概，在大型公司工作的许多人都遇到了在开发人员的本地计算机上部署工作库副本的问题。 当此基础的重量为5-10 GB时-这不是问题，而仅在备份时的重量就接近TB时，这已经很严重了。 结果，部署新副本需要5到6个小时的工作时间。 当我厌倦了它时，我开始使用一个非常好的工具1C-Deploy-and-CopyDB （感谢Anton！），然后我意识到自动化很酷。
此外，还有其他任务，例如，晚上从存储中定期更新主数据库和分布式数据库，进行表单测试，进行场景测试等。 其中一些实现了，但有些却没有。
但是所有这些仅对我而言是必要的。 在他所在的城市寻找志趣相投的人时，他实际上失败了。 他们不在那里。 尽管非常奇怪，但由于问题是典型的。 那时我已经知道我想写关于这个话题的论文。 但是我不知道该写些什么。 因此，我不仅要阅读，而且至少要写作和提出问题，因此必须加入社区。 您可以提出问题的主要地方是
Github项目：
• https://github.com/silverbulleters/add
• https://github.com/oscript-library/opm
• https://github.com/EvilBeaver/OneScript
• https://github.com/silverbulleters/vanessa-runner/
XDD论坛：
•1 脚本部分
• 测试部分
• 过程自动化部分
好吧，作为一种快速沟通的手段-Gitter中的个人资料组
资料的收集已经开始。 就像命运那样，我设法联系了Alexey Lustin alexey-lustin （嗨，Alexey！），并在XDD论坛上谈论了我的文凭想法。 令我惊讶的是，他们收到了批准的反馈，甚至收到了邀请参加Silver Bullet的毕业前练习。 这已经是一场胜利。 在几个小时内，我们提出了文凭的主题和内容。 我们为实际工作设定任务。 我从公司获得了文凭项目的负责人-Arthur Ayukhanov（Arthur，您好！），年轻的Padawan如何访问发布工程师的视频课程，以及获得Nikita Gryzlov（您好，Nikita！）的能力，他的问题无限多，对此，他深表感谢。
总结：
文凭的主题是“信息系统的自动化生命周期管理-在持续提高生产过程质量的条件下，在1C：企业平台上的解决方案的系统和软件工程”。
最终鉴定工作（WRC）的目的是识别软件工具的关系以及1C区域DevOps电路的业务流程的描述。
该项目的理论依据是从ITIL 3.0持续改善服务质量的标准，而实际目的是为我们开发的新应用程序解决方案（客户的个人帐户）构建持续集成循环。 为此，部署了GitLab源服务器和Jenkins构建循环。 测试在专用服务器（Windows Slave）上运行。 使用版本3.0的Gitsync库从1C存储库中卸载了配置
（目前位于开发分支机构）已经获得了Alexei Khorev（Lech hello！）的成就，在开发分支机构的工作频率为30分钟。 选择此特定版本的原因是能够通过tcp协议连接到存储库，但不幸的是，该协议当时不支持典型的GitSync2.x。 如果在GitLab中记录了更改，则会自动开始持续集成循环的运行。
由于整个活动的预算为零，并且无法为SonarQube购买模块而无法构建完整的程序代码质量控制的能力，因此使用标准的1C语法检查作为简化的解决方案。 尽管完成了一次卸载，但仍获得并分析了结果。 还使用了额外的周期性检查和是否存在可重用代码。
在功能测试阶段，使用了两个Vanessa-Behavior和XUnitFor1C框架，它们的组合版本称为Vanessa Automation Driven Development（Vanessa ADD）。 第一个用于开始测试预期的行为，第二个用于检查表单的打开（烟雾测试）。 通过持续集成循环会自动生成报告。
根据测试结果，发布工程师决定合并开发分支和主分支，并（已经手动）启动了第三个任务-发布对生产数据库的更改。 生产性数据库未连接到存储库，并且已完全关闭了手动更改。 更新只能通过交付并以自动模式进行。
为了描述电路的业务流程，形成了一个IDEF0图，该图由构成电路通道的4个连续的块组成。 经历任何阶段时发生的错误都会中断组装过程，并向发布工程师发出通知，并将控制权转移到组装过程的第5个块，在该块中，将以ALLURE，JUNIT格式生成报告，当然还会生成cumul.json。
IDEF0型号说明
“在GIT中卸载源代码”的过程
输入数据： -配置库
输出（Output）： -源代码
控制：使用软件的说明，汇编脚本
机制： 1C：企业， Gitsync 。
轮廓存在的先决条件是源文件的存在。 从平台版本8.3.6起，1C提供了将配置源代码上传到文件的功能。 应该注意的是，根据IT部门的开发细节，此过程可以有几种选择。 在当前版本中，为了简化员工向新方法过渡的过程，已执行了通过配置存储库并使用1C配置器与当前开发过程的集成。
在“在GIT中卸载源”过程的阶段，将创建文件，服务信息库1C。 它已连接到服务帐户下的配置存储； 在当前时间（或到存储库中的最后一次提交）接收所有更改； 源代码已卸载到程序集目录中； 致力于GIT版本存储系统； 更改将发送到GitLab源服务器
“测试源代码质量”的过程
输入数据： -源代码
输出（Output）： -源代码
控制：使用软件的说明，汇编脚本
机制： 1C：Enterprise， Deployka ， SonarQube ，Cyclo.os-（不幸的是没有链接）
在此过程开始时，源代码存储在GitLab存储库中。 使用控制（程序集）脚本，它会在程序集目录中接收。 通过1C：企业平台，基于这些源代码，可以部署服务信息库。 使用平台工具执行错误分析。 如果在分析过程中检测到不允许汇编配置的程序代码错误，则过程将被中断。 此步骤的目标是消除浪费时间的分析无效配置的程序代码。
检查错误之后，开始计算程序代码的圈复杂度。 该系数的增加会严重影响程序代码的调试和分析。 允许的最大值为10。如果超过该值，将引发异常，并返回代码以进行修订。
分析程序代码质量的最后一步是检查是否符合开发标准。 为此，建议的方案使用SonarQube服务和他从Silver Bullet开发的1C语法支持模块。 根据分析结果，系统为发布程序代码的每个员工计算技术债务的价值。
功能测试流程
输入数据： -源代码
输出（Output）： -源代码
控制：使用软件的说明，汇编脚本
机制： 1C：企业， Vanessa-Behavior，XunitFor1C 。
在开发过程中，可能会出现新功能可能会破坏现有子系统的操作的情况。 这可以在异常的形成以及未预期结果的结论中得到体现。 为此，测试了系统的预期行为。
几种开发和测试方法适用于此电路：TDD（测试驱动开发）和BDD（行为驱动开发）
在编写WRC时，使用了Vanessa-bahavior框架来使用BDD 方法论和XunitFor1C for TDD来执行测试。 目前，它们已合并为一种Vanessa-ADD产品。 开发人员对较旧产品的支持已停止。 测试结果将输出到Yandex Allure和Xunit报告文件中。
流程“交货组装”
输入数据： -源代码
输出数据： -交付配置
控制：使用软件的说明，汇编脚本
机制： 1C：企业， packman 。
在此过程中，将进行最终交付的配置交付以部署到目标系统。 经过验证的源代码位于GitLab源代码存储库的development分支中。 要形成交货，必须将来自develop分支的更改出现在master分支中。 此操作可以手动也可以自动执行，并由IT部门使用CI / CD循环进行规定。 合并分支后，开始组装完成的交货过程。 为此，再次在程序集目录中，基于现有资源，创建服务信息库，然后使用1C：Enterprise平台的工具生成并归档配置交付。 配置交付是组装过程的最终产品，并通过已建立的通信渠道交付给客户，或者直接安装到生产信息系统中。
发布结果流程
输入数据： -卸载结果，报告文件
输出数据： -报告
控制：使用软件的说明，汇编脚本
作用机理： Yandex Allure ， Xunit 。
在执行流程步骤时，测试工具会以某些格式将报告文件作为副产品创建。 此过程的任务是对数据进行分组，转换和发布，以方便数据分析。 如果在装配的某个阶段生成了异常并进行了必要的设置，则系统应自动将问题通知循环管理员。 此阶段在组装过程的后处理中执行，并且无论先前过程的结果如何，都应执行此阶段。
为了获得反馈，除邮件列表外，还使用了与Slack公司经理的集成，其中发送了所有有关构建状态，新提交的外观，备份的形成以及与DevOps电路以及从1C到1C的服务的功能监视的信息消息。整体。
我项目的结果是在今年5月底保护WRC，并取得了“优异”的成绩。 此外，更新了有关轮廓形成的方法学信息。
一般结论：
- 经济影响只有长期才能实现。 从经验中可以注意到，当实施工程实践的项目启动时，开发效率比当前水平降低了20-30％。 该时间段是暂时的，通常情况下，运行三到四个月后，性能会恢复为其初始值。 性能下降的主要原因是开发人员必须适应新的开发要求：编写脚本，测试和创建技术文档。
- 由于测试了程序代码，生产信息系统的稳定性已大大提高。 场景测试覆盖范围可确保关键子系统的运行。 因此，公司在关键领域的风险-与客户的运营互动减少了。
- 排除了对生产性信息库的动态修复之后，就可以更有建设性地计划开发并防止软件代码绕过测试循环。
- 由于装配电路的自动化，减少了维修信息库的人工成本。
- 通过Slack使用反馈可以在线监视和修复系统生命周期问题。 根据团队评论，使用Messenger比邮寄更为方便（尽管它也存在）。
- 使用自动连续代码检查（Continuous Inspection）符合开发标准（SonarQube）会强制开发人员独立地提高他们的能力，并且在软件模块的开发过程中直接解决已确定的技术债务要快得多，因为您不必花费时间来恢复任务的上下文。
- 启用自动文档功能和视频指令的生成可以减少用户请求的数量。
- 在项目过程中，形成了一个业务流程，该业务流程描述了开发和测试1C应用程序解决方案的生命周期，进而影响了实施工程实践的项目的形成。 , 1.
, . 90% .
, :
- , " 1. - , , ( 5 ).
- “ 1”. . ( , " ". ).
- CICD 1 , 5.5.0 .
, , 1 , DevOps. , — DevOps 1 .
, DevOps 1. ?