在大型和复杂项目上积累的开发经验体现在有用的工具和工程实践中，这些工具和工程实践需要丰富开发过程，并重新进行重新思考。 正是对获得的经验作为一种工件的价值的认识，对发展的渴望，使我们理解了在当前流程中实施工具和实践的必要性。 我们对设计解决方案的方法以及整个开发过程进行了彻底的审查。 描述1C世界中团队开发的“经典”方法的典型局限性和不足之处是没有道理的。 关于这个话题已经说了很多。 我将仅描述使我们将这些缺点缩小并几乎不令人恐惧的模式。
结识了
集成开发人员！建筑的一般原则
在设计展台的架构时，我们力求涵盖在项目上实施的解决方案的整个生命周期，实施所获得的经验，标准化流程以及使例行程序自动化。 同时，有必要在服务，开发和用户体验方面奠定发展潜力，以保持扩展能力和最大程度的简化。 在实践中已被证明有效的工具和技术应添加到该过程中。 并且所有无用的，干扰工作的都必须清除。
过程
根据项目的规模和复杂性，任何解决方案的生命周期实际上都保持不变。 它包括：分析，设计，开发，测试，实施，维护，退役。 为了获得最大的效率，应该对每个过程进行验证，并与之前和之后的过程进行协调，组合成一种自动传送带，可以将其复制用于无限数量的项目。 通过以隔离的容器中通过导出的API连接的微服务形式实现系统，解决了该任务，该微服务可以部署在企业的云服务和本地网络中。
这是实现该过程的堆栈的样子：
我们试图通过封闭的源代码尽量减少对付费服务的使用，这对拥有成本产生了积极影响。 几乎所有服务都是开源的，并且可以在Linux上运行。
设计该流程时，我们可以充分利用开发团队的每个成员，并且标准化和自动化消除了不必要的复杂性和例程。
设计（应用程序设计服务）
在项目开始时最重要的阶段之一是基于需求分析来设计未来的解决方案。 主要任务是以开发人员/工程师和顾问都可以理解的术语，尽可能清晰，明确，快速地描述未来解决方案的体系结构。 描述元数据，已实现的业务流程的算法。 同时，我想针对特定条件最大化使用可快速定制的现成模板，这些模板可以适应输入数据并在输出中获得项目文档。
我们已经将“ 1C：DSS”配置实现为用于设计应用解决方案的单个界面，大大改进了描述业务流程和功能以及设计TP（FDR）的概念。 他们还通过与1C：DO功能和微服务集成来使文档生成过程自动化，以便以docx格式生成文档。
“ 1C：DPR”。 编辑项目信息：
“ 1C：DPR”。 流程报告：
“ 1C：DPR”。 编辑对象元数据：
“ 1C：DPR”。 编辑业务流程图：
顺便说一下，我们可以可视化系统中业务流程和对象之间的关系，根据注册的需求创建改进列表并自动获取项目文档，从而简化了变更管理流程。 因此，要详细计划开发过程，了解任务的复杂性，连通性，以便更准确地确定执行任务的时间和步骤。
当然，不能说设计过程已经发生了巨大变化，但是组织方法的统一和许多功能的自动化已经对项目的质量做出了贡献。
开发（持续集成，检查和测试服务）
我们尝试着重于对开发代码进行全面，连续，自动化的质量控制的可能性，以确保符合CROC中建立的标准。 此外，即使我们聘请第三方开发团队，其方法，工具和开发标准也可能与我们采用的方法，工具和开发标准大不相同。
在展位上，每个开发人员提交都会自动启动通过Gitsync服务将配置解析为目录和文件结构的过程。 所产生的更改被索引并放入Git存储库。 在我们的例子中，这就是Gitlab服务。 提交消息是根据将更改发布到配置库时输入的注释文本自动生成的，版本控制系统中提交的作者被映射到配置库的用户。 在注释文本中进行解析的过程中，我们可以获得有关开发任务和人工成本的信息，并将其传递给任务跟踪系统，例如Jira。 这提供了发展历史的全面情况。 例如，我们可以通过一行代码找到作者，并且对提交的智能注释使您可以自动控制任务的状态，并直接在任务本身中评估与任务相关的代码。
Gitlab 现在可以对由提交放置的代码的任何行进行注释：
Gitlab 进行语法突出显示的“代码审查”：
Gitlab 清晰了解新提交中的代码更改：
每次提交后，SonarQube服务进行的静态代码检查过程将自动在存储库中启动。 检查BSL提交代码是否符合描述代码开发标准的一组规则（质量配置文件）。 该过程既针对正在开发的配置的代码，也针对外部机制：扩展，外部报告和过程，以及原则上任何其他项目代码（甚至使用其他语言）也是如此。
SonarQube：
每次检查都会更新跟踪的代码库质量指标的信息，例如：
- 技术债务-纠正发现的错误所需的总劳动；
- 质量阈值-代码的错误，漏洞和其他缺陷的最大允许指标，达到该指标时，认为无法发布版本；
- 代码重复-在已开发配置的框架内多次重复的代码行数；
- 循环复杂性和认知复杂性-具有大量分支的算法会使代码的支持和改进变得复杂。
验证所收集的度量可以直观地表示项目代码库的当前状态，可以评估质量，识别风险并快速纠正错误。
通过XPath可以使用其自己的规则集来扩展质量配置文件，也归因于作为其自己的1C插件实现的一部分发布的新规则。 这使您可以根据特定解决方案的实际情况灵活地管理质量要求。
自动启动配置解析过程，代码检查，自动测试等。 启动持续集成服务（Jenkins服务）。 此类装配线的数量和性质可以根据项目的具体情况进行更改。
尽管描述的过程相对复杂，但是执行例程的所有传送器机制都隐藏在云服务中。 开发人员可以处理配置器熟悉的界面，还可以使用更高级的工具来开发自己的技能。 例如，git，它是与第三方代码编辑器和SonarLint，SourceTree等结合使用的外部机制的存储库。
在一般情况下，开发人员将信息库连接到1C配置存储服务，编写代码并将其放置在该服务中，从而在展台处启动对其隐藏的过程。 如果作为检查提交的结果，在代码中发现了缺陷，则开发人员会收到一封电子邮件通知（或聊天机器人消息），其中包含错误描述的链接以及在SonarQube服务界面中用于更正和临时评估人工成本的建议。 修复错误后，将进行新的提交并重复该过程，已编辑的任务将自动关闭，从而减少了技术债务。 按照相同的逻辑，构建了一个自动测试过程，其中每个提交都会启动测试环境部署的启动，并连接测试库中的必要测试。 在运行之后，将汇总有关测试过程中的错误以及有关测试的代码覆盖率的信息。
很难高估连续，全面的代码验证，然后对开发的功能进行自动测试的效果。 这使您摆脱了深远的影响，使开发阶段变得透明，并结合适当构建的流程，客观地评估了开发人员的资格，从而消除了依赖承包商的风险。 估计当前代码库的参数，我们可以快速识别和缓解新出现的风险，纠正设计缺陷并及时响应不断变化的需求。
展位架构的模块化组织使您可以在过程中嵌入新模块，为所需数量的项目复制解决方案。 从示意图上看，它看起来像这样：
测试（连续测试服务）
我已经讨论了持续测试服务，该服务已集成到开发流程的管道中。 目前，已经在展台上进行了烟雾测试和单元测试的测试。 自动测试的功能是使用xUnitFor1C框架实现的。
测试过程的启动以及代码检查与项目存储库中的commit事件相关。 对于单元测试，这意味着在开发功能的同时开发测试。 在即将实施之前，最新配置会自动部署到准备好的测试信息库中。 然后启动客户端，该客户端运行针对已实现功能的测试脚本。 自动化测试服务与BSL SonarQube插件的紧密集成使您能够计算出诸如测试代码覆盖率之类的参数。 测试运行结果是一个报告，该报告已上载到ReportPortal测试分析和可视化系统。 此服务是一个报告门户，其中汇总了测试运行的数据（统计信息和结果），对系统进行了跌倒分类的基础培训，并进一步自动确定了原因。 测试运行的所有参数都可以在方便的Web界面中使用，该界面具有用于图形，图表（窗口小部件）的各种板。 要扩展门户网站的功能，可以使用自己的扩展。
自动化测试服务是另一步，可降低进入发布代码的风险，该发布代码破坏了先前实现的功能或出现错误。
ReportPortal。 资讯主页：
ReportPortal。 试运行失败：
ReportPortal。 缺陷类型：
ReportPortal。 编辑缺陷类型：
发展历程
评估完成工作的结果，我们可以从已经实施的计划中看到哪些想法已经成功运行，哪些想法尚未实现。
在不久的将来的计划中，展位的发展是建立展位服务管理门户。 门户网站的Web界面允许您使用将项目连接到展台的应用程序，服务成本计算器以及根据项目要求自动部署的应用程序。 结果，经理可以立即获得所选服务成本的计算并估算成本，确定项目的开发商。
我们计划将门户网站与用于1C操作系统的云解决方案集成。 这将有助于快速部署复制的标准解决方案，以及在展位上实施的开发服务，以将客户系统更有效地迁移到CROC云。
我们还计划将管理门户与自动配置管理服务（部署，配置，删除）集成在一起。 这将减少部署时间，简化系统设置和维护。 为了提高安全性，我们将为展位的所有服务引入通过身份验证服务，以便在所有服务中使用相同的帐户。
如果我们从解决方案开发的整个周期的历史角度考虑整个过程，那么创建的管道将使我们能够收集和汇总由项目工件和参与其中的专家组成的大量各种度量。 这样详尽的回顾将有助于积累和重用解决复杂问题的经验，从而组建成功的开发人员团队，以进行更高效，更协调的工作。UPD 根据评论的要求，添加带有链接的我们使用的开源产品列表。