在项目上成功设置持续交付的关键是什么？ 开发，测试和基础架构工程师的协调工作。 谢谢，上限，正如他们所说的:)但是如何将其付诸实践？ 在本文中，我们将分享有关如何组织和实现所有这些的最佳实践。
我们已将基本知识汇总为一份备忘单，并与您分享：
经验丰富的工程师不太可能从本文中学到任何东西，但我们希望这些信息对初学者有用。
有哪些要求及其特征
每个项目都有许多要求。 重要的是要理解所有这些并且不要混淆它们。
业务需求从业务角度确定系统应该做什么。
例如：该应用程序应允许用户出售票证和其他服务，以增加代理商的销售额。用户需求描述了将在系统中实现业务需求的用户的目标。 用户需求通常以用户案例的形式呈现。
例如：作为用户，我需要销售里程服务。功能要求 -系统应该做什么。 确定系统的功能（行为），该功能必须由开发人员创建，以便用户可以满足用户要求。
非功能性需求 -系统应如何工作。 这包括对性能，质量，限制，可用性等的要求。
任务类型及其在问题跟踪器中的描述顺序
因此，我们已经描述了需求的类型。 现在，我们将它们分为任务类型，解密每种类型并说明如何正确描述。
让我们从史诗般的史诗开始。
Epic是一项常见任务，其中收集所有用户故事，同时考虑服务的开发时间。 它描述了产品或服务的主要目的。 Epic的主要目标是收集任务并将其存储在一个地方，无论对该产品提出什么新要求。 Epic始终不只是一个用户故事，甚至可能不适合一次迭代。
Epic问题的解决方案使您可以创建
MVP （最小可行产品）-最小可行产品。 换句话说，为了根据最终用户的反馈来学习和调整产品，需要发布哪些内容。
史诗与用户故事有何不同？
- 史诗只是一个重要的用户故事，其标志是对用户而言存在明确的价值。
- 开始形成用户故事，即收集项目需求后，我们通常从一般性转向特殊性-首先确定项目的概念，选择主要人员（系统用户），创建主要功能列表，然后按照不同的意愿详细说明这些功能-用户故事。
对Epic的描述如下：
- 标题/摘要标题 -新功能的名称。
- 说明/说明 -根据模式编写：
用户的角色（这样的用户，我...）/用户的操作（我想做某事...）/操作的结果（得到...的结果）/兴趣或利益（将使我获得这样的利益...）。 - 作为Mpic的Epic的一部分，将实施示例实施计划或主要用户故事的简短描述。
- 附件/附件 -附加信件，技术和其他必要信息。
如何制作用户故事和技术故事
用户故事和技术故事之间的区别在于，技术故事是指在开发产品时必须考虑并在任务中描述的功能要求。 在这里，作为消费者的角色是系统的一部分。
描述它们很容易。 要记住的主要事情是为什么要完成所有这一切。
用户故事描述的顺序很标准：
- 标题/摘要/标题-对新功能或客户可以理解的语言的改进的简短描述。
- 说明/说明包括主要目标和预期结果。 就像<用户角色>，我<想要获取>，目标是<操作结果>。
- 验收标准是优先产品标准的列表。 也就是说，对产品应采取的措施进行了可衡量的定义，以使产品利益相关者可以接受该产品。
- 技术说明，模型，布局，页面布局。
- 附件/附件-所有必要的技术，文件，与客户的通信。
如何描述错误
报告错误时应指出哪些信息：
1.
标题/摘要/标题简要描述了错误的本质，并指出了问题的位置。
2.说明包含以下步骤：
•如何重现错误/播放步骤，
•当前结果，
•预期结果。
3.
附件/附件 -所有必需的日志，屏幕截图，指向Kibana和其他文件的链接。
4.
环境 -在错误的环境中重现错误的标记，以及问题所属的类别。 例如，UI错误，CORE错误，SWS错误等。
5.
优先级将使团队中的每个成员都可以评估问题的严重性，经理可以在第一次冲刺的候选人列表中看到问题。
并且不要忘记设置正确的优先级：）
现在，我们已经了解了工作的一般原理，接下来将告诉您如何组织部署管道。
部署管道配置
为了加快将服务交付生产的速度，我们引入了新的部署管道，并使用GitFlow处理代码。
为了快速，动态地执行此操作，我们部署了多个GitLab运行程序，这些运行程序运行所有开发人员的推送任务。 借助GitLab Flow的方法，我们有了几台服务器：开发，质量检查，候选发布和生产。
持续集成开始为每个提交收集和运行测试，运行单元测试和集成测试，为应用程序交付添加工件。
开发过程如下：
- 开发人员在单独的分支（功能分支）中添加了新功能。 之后，他创建一个将其分支与开发主分支合并的请求（将请求合并到Develop分支）。
- 其他开发人员查看合并请求，接受（或不接受）并更正注释。 合并后，一个特殊的环境在主干分支中展开，在该环境上执行了提高环境的测试。
- 完成所有这些步骤后，质量检查工程师将更改带到其“质量检查”分支并进行测试。
- 如果质量检查工程师同意所做的工作，则更改将进入“候选发布”分支，并部署到外部用户可以访问的环境中。 在这种环境下，客户接受并验证技术。 然后，我们将一切提炼到生产中。
如果在某个阶段存在错误，那么我们将在此分支中解决它们，然后将结果发布到Develop中。
我们还制作了一个小插件，以便Redmine可以告诉我们该功能所处的阶段。 这有助于测试人员评估您需要在什么阶段连接到任务，并帮助开发人员纠正错误。 因此，他们可以查看故障发生在哪个阶段，可以转到特定分支并在那里进行播放。
希望对您有所帮助。