持续交付的核心原则包括以下7点：1、自动化；2、不断地进行测试；3、更小的和更多的发布更新版本；4、使用自动化的基准套件；5、使用源代码控制；6、使用代码审查系统；7、使用Pull Request。
这里有7个能够使开发和交付周期变得高效的持续交付的原则：
1、自动化
虽然越来越多的组织认识到他们的端到端发布流程和交付对自动化的需要，但是如果我们没有正确的使用它，它将会成为负担。比如，有些人仍然在拒绝使用自动化单元测试，但是从长远看，这实际上会让他们的发布和交付慢下来，尤其是人为错误会不可避免的出现。
2、不断地进行测试
很显然，如果你想使发布周期更快更好，你就需要不断的进行测试。如前所述，自动化测试是持续交付的关键，并且你也不想在QA和开发之间会出现瓶颈，堵塞你的流程。
3、更小的和更多的发布更新版本
持续交付的核心原则之一是更小的和更多的发布版本通常要好于一个大的发布版本。它更有效率——甚至更安全——在交付之前，持续发布一些更新版本，然后等待添加大批量的特性和bug修复。然后，如果需要进行任何的修改，都能够在不影响其他特性的情况下，很容易的进行。
4、使用自动化的基准套件
如果你想要一个成功的持续交付，在你的创建中添加一个自动化的基准套件将非常重要，它会帮助你在不进行任何回归的情况下，优化你的性能。
5、使用源代码控制
对持续交付进行完善，能确保你能够在不影响已有组件和特性的情况下，不断增加版本。这不仅支持你的SQL代码，也允许你能够进行持续集成，进而实现持续交付。
6、试用代码审查系统
很多组织使用了多级审查系统，这意味着越来越多的高级开发人员必须在代码被批准之前，对其进行审查。而一个对等的审查系统，由开发人员互相进行代码审查，将会产生更快和更有效的过程。
7、使用Pull Request
使用Pull Request能够极大的加速流程。当其他人能够同时对作者的代码进行审查以及在它集成到主程序之前提出修改建议，将会带来更好的交流和更少的瓶颈。
持续交付不仅仅是一个很好的想法，就像每一个使用敏捷方法的人会告诉你的，它已经迅速的成为了必须品。它很重要，然而，不论是你正在将他引入到你的组织当中，还是想要优化你的持续交付方法，你都需要使用正确的持续集成原则，来保持你的素质更快和更有效率。
延伸阅读：
什么是持续交付？持续交付有什么用？
持续交付 (CD) 是从生成到生产环境自动执行生成、测试、配置和部署的过程。 发布管道可以创建多个测试或过渡环境，以自动创建和部署新的生成。 后续环境支持逐步延长运行的集成、负载和用户验收测试活动。持续交付价值已成为组织必需的要求。 若要向最终用户提供价值，必须不断发布且不会出现错误。
在 CD 之前，软件发布周期是应用程序和运营团队的瓶颈。 这些团队通常依赖于手动交接，导致发布周期出现问题。 手动过程导致生成延迟和错误的不可靠版本。
CD 是一种 精简 做法，目的是使生产保持最新，并采用从新代码或组件可用性到部署的最快路径。 自动化可最大程度地缩短部署时间和 时间，以缓解 (TTM) 或 修正 (TTR) 生产事件的时间。 在精简方面，CD 优化进程时间并消除空闲时间。
持续集成 (CI) 启动 CD 过程。 测试成功完成后，发布管道会将每个连续环境暂存到下一个环境。 自动化 CD 发布管道允许 快速 验证方法失败，其中测试很可能先快速运行，并且运行时间较长的测试仅在更快成功完成后才会发生。基础结构作为代码 (IaC 的补充做法) 和监视有助于 CD。
本文来自投稿，不代表Worktile社区立场，如若转载，请注明出处：https://worktile.com/kb/p/30513
微信扫一扫 
支付宝扫一扫 
