一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
阶段构建）背后的思想是，实际上有多个按顺序完成的构建。对主线的提交触发了第一个构建——我称之为提交构建。提交构建是当有人需要提交到主线时所需的构建。提交构建是必须快速完成的构建，因此它将采用许多快捷方式，这将降低检测错误的能力。关键在于平衡发现bug的能力和速度的需求，这样一个好的提交构建就足够稳定，可以供其他人工作使用。
一旦有良好的提交构建，其他人就可以满怀信心地处理代码。不过，你可以开始做更多、更漫长的测试。其他机器可以在构建上运行需要更长时间的测试程序。
这是一个简单的两阶段部署流水线例子。第一阶段将进行编译并运行更本地化的单元测试，数据库通过“打桩”的方式完全被隔离掉。这样测试可以运行得非常快，保持在10分钟的范围内。但是，任何涉及大规模交互的bug，特别是涉及真实数据库的bug，都很难被发现。第二阶段构建运行一组不同的测试，这些测试确实会测试真实的数据库，并涉及更多的端到端行为。这一次运行可能需要几个小时的时间。
在这个场景中，人们使用第一个阶段作为提交构建，并使用它作为主CI周期。第二阶段构建在可能的情况下运行，从最近的良好提交构建中获取可执行文件以进行进一步的测试。如果这个二次构建失败，那么它可能没有 “停止一切”的质量目标，但是团队的目标是在保持提交构建运行的同时，尽快修复此类错误。在这个例子中，后面的构建通常是纯测试，因为现在通常是测试导致了缓慢。
如果第二级构建检测到一个bug，这表明提交构建可能使用另一套测试。尽可能地确保任何后期阶段的失败，都会触发在提交构建中引入新的测试，这样在提交构建中就能捕获bug，从而在提交构建中就能解决掉这些bug。这样，每当有错误漏过提交时，提交测试就会加强。在某些情况下，没有一种快速运行的测试来暴露bug，因此你可能决定只在第二级构建中测试该条件。幸运的是，大多数情况下，你可以向提交构建添加适当的测试。
这个例子是一个两级流水线，但是基本原理可以扩展到任何后期阶段。提交构建之后的构建也可以并行完成，因此如果有两个小时的第二阶段测试，则可以通过让两台机器分别运行一半的测试来提高响应速度。通过使用类似这样的并行第二阶段构建，你可以将进一步的自动化测试（包括性能测试）引入到常规构建过程中。
在生产环境的克隆中测试
测试的重点是在受控条件下，清除系统在生产中可能出现的任何问题。其中很重要的一部分是生产系统运行的环境。如果你在不同的环境中进行测试，每一个差异都会导致风险，即在测试中发生的事情不会在生产中发生。
因此，你希望将测试环境设置为尽可能精确地模拟生产环境。使用相同版本的数据库软件，使用相同版本的操作系统。将生产环境中的所有适用的库放入测试环境中，即使系统实际上没有使用它们。使用相同的IP地址和端口，在相同的硬件上运行它。
事实上，这是有限度的。如果你正在编写桌面软件，使用不同人员运行的、并安装了所有的第三方软件的桌面克隆中，进行测试那是不现实的。类似地，有些生产环境的复制成本可能高得令人望而却步（尽管我经常遇到不复制中等成本的环境而产生的浪费成本）。尽管存在这些限制，你的目标仍然应该是尽可能多地复制生产环境，并理解测试和生产之间的每一个差异所带来
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
