亨利·福特曾经说过：“最好的汽车是一辆新车。” 因此，我们在Tinkoff公司集团中考虑软件发行版。 迟早交付功能和紧急修复过程中的惰性会给客户带来巨大的技术负担，并且通常最终会导致整个项目停滞不前。
确保高质量的上市时间并保持质量并非易事。 从我的角度来看，您无法立即构建导轨，就可以在启动后的几个月内快速方便地进行更改。 一个项目的增长通常伴随着工作人数的增加，这意味着它会在您的发行版中造成潜在的混乱。
我们的经验几乎不值得作为成功的指导，但是许多想法似乎很有趣，我可以与您分享。 让我们开始吧。
从技术上讲，我们历史的起点如下。 该系统由多个服务组成，其代码库大约由30个人组成-几个团队按业务领域划分，例如，为个人和法人提供服务。 我将尝试忽略该项目的技术和体系结构细节，以便专注于发布过程本身。
我们正在研究Gitflow ，因此对于那些选择这种特定交付方式的人来说，本文将是非常有趣的。
问题所在
我们遇到的第一个问题与流程自动化不足有关。 我们团队中所有发布活动的实施都与发布经理（RM）的角色相关。
以下是其中一些：
- 离开发行分支并创建标签。
- 与主人合并并发展分支机构。
- 构建和部署发行版中包含的工件。
- 与过程中涉及的专家进行沟通-例如，与质量检查人员或管理员进行沟通。
随着项目的扩展（在我们的情况下，服务数量的增加），这些例行任务需要越来越多的资源，因此第一步是使所有可以自动化的东西实现自动化。 我们与CI / CD工具集成在一起，以便分配和合并发行分支，启动测试构建并部署工件。 使用任务跟踪工具和公司Messenger来及时通知负责下一步的参与者-例如，更改任务的状态并配置挂钩以发送通知。
发布管理器仍将必须手动解决合并分支所引起的潜在冲突，但是快速而频繁的发布应将其数量减少为零。
下一个问题是测试 。
对我们来说，构建标准之一是测试的成功执行。 通常将测试至少分为两种类型：单元测试和集成测试。
单元测试使您可以检查程序源代码中各个模块的正确性，实际上，在大多数情况下，这归结为检查一种或多种具有明显逻辑连接的方法。
集成测试通常检查此类模块的整个级联的可操作性，即客户端整个功能的功能。 例如，如果在任务中实现了休息接口，那么我们将检查授权的可操作性，请求本身的反序列化，所传输字段的有效性，与其他服务和数据库的集成以及业务逻辑本身。 乍一看，这样的测试似乎非常自给自足，能够覆盖所有潜在的问题区域。 无需了解每个砖的工作方式，并且被调用的接口封装了所有逻辑，以便在输出上获得简单的答案：它是否起作用。
实际上，它们会产生许多延迟的问题，以下是其中的一些问题：
- 大量测试零件的参与会成比例地影响组装时间和此类测试的执行。
- 封装测试逻辑通常会导致难以保证测试结果正确性的事实。 通常，我们会根据结果自定义测试，并且由于随机的副作用，结果经常更符合预期。
- 测试数据的相关性丢失。
- 与第三方系统（尤其是在测试环境上）的集成通常会失败。 这消除了花费的运行时间，因为这并不总是显而易见的：这是由于我们的更改导致的暂时下降或崩溃。
对于大多数问题，已经提出了解决方案。 但是，像往常一样，解决方案并非没有其他限制或新问题。
为您选择正确的测试并正确实施它们是一项非常艰巨的任务。 此外，重要的是要在覆盖质量和构建速度之间取得平衡，以优化发行版。
就我们而言，我们选择了混合动力车。 我们会继续提高所有必要组件的功能，以进行完整的功能测试，同时清洗所有可能的集成。 为了保存API合同，我们使用Pact ，并检查与数据库Testcontainers的集成。
结果，这种编写测试的方法导致解决了第三个问题- 长时间手动测试任务 。 混合测试的稳定性导致了在指定用于编译测试用例的任务阶段吸引QA工程师的想法-这将使他们在手动测试阶段被跳过。 与有用的产品（例如TestRail和Allure）的集成已经成为开发人员和测试人员之间的桥梁。 创建了一个合同，该合同的执行逐步反映在测试程序集生成的报告中。
仍然可以将报告连接到您的任务跟踪工具，以进行透明的任务跟踪。 一个清晰的故事也将减少为将来的相关任务编译和实施测试所需的时间。
这样，质量检查工程师可以节省足够的时间来专注于测试特殊情况并与其他系统集成。
最后一个问题与此有关。 对于手动测试，所有任务都从开发中的功能分支合并，然后启动部署到测试台。
首先，使用这种方法时，您不能谈论功能的纯测试，因为与此同时，其他开发人员的相关更改可能会落入开发过程。
其次，当释放release分支时，可能会发现QA没有时间测试某些任务。 可以选择：回滚受这些任务影响的更改，或者放慢发布速度，直到测试结束。
除非您隔离测试环境 ，否则您将始终必须做出这样的选择。 重要的是，除了该任务所做的更改外，被测组件中没有其他更改。 在我们的案例中，我们需要能够选择分支已更改的一个或多个服务，并通过仅将我们需要的请求从QA发送到这些实例来管理集群内部的路由。 如果群集上已经使用了平衡机制，则该任务将变得很复杂，这也必须予以考虑。
意识到了这个机会，我们开始直接在单独的功能分支上进行手动测试：在测试过程中部署所需的服务，孤立地集成到整个环境中。 通过仅将现成的任务合并到dev分支中并摆脱了锁，我们自己开始确定哪些更改应包含在发行版中，哪些不应该包含在发行版中。
值得注意的是，对于那些几乎对相同文件进行更改的团队来说，这种解决方案不太可能成为灵丹妙药。 在这种情况下，特征的存储与合并期间发生的冲突数量成反比。 在实践中，由于发行版相当频繁，在拥有五十名开发人员的团队中很少发生这种情况。
代替输出
总而言之，我们可以确定有助于加速发布的主要方法：
- 日常操作的自动化。
- 所有参与者流程的透明度。
- 编写自动化测试时，必须在速度和质量之间取得平衡。
- 减少了手动测试的时间。
- 隔离测试环境。
重要的是要理解，在选择各种方法，原则和策略时，始终值得从问题的背景出发。 有许多同样可靠和更复杂的方法可以加快将软件交付给客户端的速度。 试图应对新出现的困难已得出上述结论。 对于我们来说，这是迈向大胆发布发行版的第一步。