一文搞懂持续集成CI
2022-11-07
来源：DevOps社区
都应该能够引入一台空白机器，签出存储库中的源代码，发出一个命令，之后在自己的机器上就拥有了一个正在运行的系统。
构建脚本通常有不同的风格，通常是特定于平台或社区的，但他们大可不必如此。尽管我们的大多数Java项目都使用Ant，有一些在使用Ruby（Ruby Rake是一个非常好用的构建脚本的工具）。我们通过使用Ant自动化在早期的微软 COM项目中获得了某些价值。
一个大的构建通常需要花费很多精力，如果你仅仅做了一个小小的更改，那么你不会想要执行所有的步骤。所以，一个好的构建工具会分析在流程中需要更改的内容。通常的做法是检查源文件和目标文件的日期，只有在源文件的日期较晚时才进行编译。依赖关系会变得更加棘手：如果一个对象文件改变了那些依赖于它的对象文件，那么这些对象文件可能也需要重新构建。编译器能够处理这类事情，也可能不处理。
根据你的需要，你可以构建不同类型的东西。你可以通过是否使用测试代码或者使用不同的测试集来构建系统。有些组件可以独立构建。构建脚本应该允许你为不同的情况构建可选目标。
我们普遍使用IDE，而且在使用IDE时，大多数的公司内部都有一些构建管理的过程。然而，这些文件总是IDE专有的，而且它们非常脆弱。不过，他们这些公司需要通过IDE进行工作。用户通过IDE设置自己的项目文件并将其用于单独的开发是完全没有问题的。然而，有一个在服务器上可用并且可以从其他脚本运行的主干是非常重要的。所以在Java项目中，我们可以让研发人员在IDE中构建，但是主干需要使用Ant来保证它可以在开发服务器上运行。
如何构建自动化测试
从传统意义上来讲，构建意味着编译，链接以及执行程序所需的所有其他过程。一个项目可能会运行，但是，这并不意味着它在做正确的事情。现代静态类型语言可以发现许多bug，但是更多的bug会成为“漏网之鱼”。
在构建过程中包含自动化测试是更快、更有效地发现bug的比较好的方法。当然，测试并不是完美的，但它能够发现很多Bug，这就足够有用了。特别是极限编程(XP)和测试驱动开发(TDD)的兴起为自动化测试的普及做了大量工作，因此许多人已经看到了这种技术的价值。
经常阅读我作品的读者会发现我是XP和TDD的忠实粉丝。然而，我想要强调的是，这两种方式都不是构建自动化测试的最佳途径。这两种方式都强调在使测试通过之前你要先编写测试——在这种模式下，测试不仅能够用于发现错误，而且还涉及探索系统的设计。这是一件好事情，但是，对持续集成而言，这并不是必需的。因为我们通常对自动化测试代码的需求比较少。（尽管TDD是我进行自动化测试的首选）
对于自测试代码而言，你需要一套自动化测试体系它可以检查大部分代码库中的Bug。测试可以从一个简单的指令中启动并进行自动检测。运行测试套件的结果应该可以指出是否有任何测试失败。对于具备自测试的构建，测试的失败应该会导致构建失败。
在过去的几年时间里，TDD的兴起普及了XUnit开源工具家族，这些工具对于这类测试非常理想。Xunit 工具对我们 ThoughtWorks 来说非常有价值，我也总是建议人们使用这些工具。这些由Kent Beck首创的工具，能够帮你非常容易的构建一个自动化测试环境。
XUnit工具当然是让代码进行自动化测试的起点。你也应该寻找其他专注于更多端到端测试的工具。目前有很多这样
免责声明：
1、IT项目管理界发布的所有资讯与文章是出于为业界传递更多信息之目的，并不意味着赞同其观点或证实其描述。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请浏览者仅作参考，并请自行核实相关内容。
2、本站部分内容转载于其他网站和媒体，版权归原作者或原发布媒体所有。如文章涉及版权等问题，请联系本站，我们将在两个工作日内进行删除或修改处理。敬请谅解！
-
延伸阅读：
-
