The history and future of continuous integration tools
As an important part of the DevOps process, the goal of continuous integration (CI) is to integrate the code of the development team, including the construction of the code, the execution of unit tests and integration tests, and the generation of reports on the execution results. CI frees development teams from wasting time dealing with code conflicts, so many see it as the cornerstone of agile software development .
CI and continuous deployment (CD) processes are often closely linked. The CD process deploys the results generated by the CI process into integration, staging, and even production environments through the steps defined in the pipeline. Since the entire CD process is "continuous", once code is checked into source control, the subsequent process automatically tests, builds the code, and deploys the build to the target environment. Its advantages are obvious: on the one hand, developers can be quickly notified of bugs and failures, forming a fast feedback loop. On the other hand, customers will also use your new features faster.
In a recent blog post, Vassili van der Mersch conducted a detailed comparison of CI tools in various environments and analyzed the future development of CI tools. In subsequent articles, the author will continue to analyze another important content in DevOps, that is, configuration management.
Traditional CI tools
The first formal continuous integration tool was CruiseControl launched in 2001, which is an open source software developed based on Java. In addition to the continuous build process, it also provides email notifications, Ant, and support for various source control systems, as well as ported versions that support .NET and Ruby. Although Jenkins came to the fore and became the first widely used CI tool, CruiseControl already has the basic functions of a CI tool and has made a great contribution to the promotion of the CI process.
The emergence and development of Jenkins is quite legendary. Its predecessor was Hudson, a Java-based CI tool developed by Kohsuke Kawaguchi, a developer from Sun Corporation, in 2004. After three/four years of development, it gradually surpassed CruiseControl as the most popular CI tool. But since Oracle bought Sun, it hopes to develop Hudson as a commercial tool for a fee. The developer community headed by Kawaguchi decided to continue the development of the free version in the name of Jenkins. Interestingly, the developers of Hudson and Jenkins each see each other as their fork version and themselves as orthodox. After 2013, Jenkins' momentum has surpassed that of Hudson in the number of daily commits, and it is now the most popular CI tool on the market.
Early Jenkins, like other traditional CI, only supported local hosting. And now some cloud computing platforms have launched Jenkins-based SaaS solutions. The most prominent in this regard is CloudBees, which provides a hybrid solution that integrates CI and CD, and provides support for Docker containers through the Docker Pipeline plugin.
In addition to Jenkins, some other popular CI tools include TeamCity by JetBrains, and Bamboo by Atlassian, among others. These CI tools basically provide the following functions:
-
Support for source control systems such as Git, Subversion, TFS, and more. A series of subsequent steps, such as build, test, and deploy, can be automatically triggered when code commits occur in the mainline of code control.
-
Support for dependency management tools such as Maven for Java, NPM for NodeJS, Gem for Ruby, Nuget for .NET, and more.
-
Support for various types of tests. Early CI only supported unit testing, i.e. functional verification of a single object or component. Later, support for integration testing was added, that is, to make communication and interaction between components difficult. Still, this is not enough to verify that the system is indeed working the way the user expects it to. Therefore, modern CI tools began to support functional testing, replacing the original manual testing with automated testing based on tools such as Selenium.
CI Tools in a Cloud Computing Environment
曾在大规模企业中尝试过CI实践的开发者非常了解：代码的构建与测试的执行是一种非常消耗资源的操作，如果有多个团队使用同一个CI平台，那么这种情况将进一步加剧。近几年来，软件团队逐渐厌倦了本地托管的CI系统对时间与精力的要求。而基于云计算平台的SaaS解决方案的出现快速地弥补了这方面市场的缺失。
Travis CI是一个基于GitHub API所打造的托管CI服务，使用Travis CI有一个先决条件，即源代码需要在GitHub进行托管。Travis CI通过webhook对GitHub代码仓库中的各种变化进行响应，例如代码提交或pull request等等。Travis CI也依赖GitHub提供的服务对用户和组织进行认证。
使用基于云环境的CI系统让开发者得以从对本地CI系统的安装、配置过程中解脱，不必再关注于基础设施和用户认证与授权方面的问题。此外，由于大多数SaaS方案都提供了对应的API，因此整个工作流都可以实现API驱动。
基于云环境的CI系统还有另一大优势，他们通常会提供更多的测试功能，例如对不同浏览器与操作系统组合条件的测试。例如Travis就支持在Linux、Mac和Windows系统上的测试，并支持PHP、NodeJS、Go和C等各种语言。
用于移动应用的CI工具
随着智能手机的日益普及，移动应用的数量也在不断增长。但由于移动应用与Web应用相比有一些特别之处，例如它的测试与发布方式，以及完全不同的依赖管理机制，因此移动应用对于构建、测试及部署流程提出了完全不同的要求，这是传统的CI工具力所不及的。好在如今已经有几家主流的CI提供商实现了支持移动应用的CI工具，例如CircleCI已经提供了对iOS应用的支持。
移动应用的测试与Web应用具有很大的差别，Web应用的客户端多数集中在一些主流的浏览器与操作系统上，而移动应用的客户端往往是千差万别的，特别是在Android平台上。某些测试框架，例如Espresso以及Appium能够自动替你解决许多困难。而像Crashlytics与HockeyApp这样的工具除了内置的CI功能之外，还能够自动生成应用崩溃的报告，为开发者进行问题诊断提供充分的上下文。
而由于移动客户端的多样性，以集中化的方式进行所有测试的方式是不太实际的。因此，移动开发社区更推崇beta测试的方式，通过TestFairy或TestFlight等工具将潜在的新版本发布给beta测试人员。
移动应用的另一个独特之处在于它的发布方式，通常需要经过漫长而繁琐的审核流程才可发布至对应的应用商店。这不仅降低了持续交付的速度，还不得不在流程中引入各种人工步骤，使全自动化的流程无法实现。
为此，像Fastlane这样的工具可实现将应用审核流程中的大部分元素实现自动化，例如为新应用进行屏幕截图及处理认证等信息。可结合Jenkins等CI工具以完善整个工作流。
CI工具的未来
CI与CD过程如今已成为现代化应用开发中一个并不可少的元素，绝大多数开发团队在软件项目中都需要设计一个完善的CI与CD工作流。
而CI的发展并不会停下脚步，它仍处于高速的发展中。在对Web及移动项目支持的基础上，未来几年之内，我们将看到CI在其他类型的开发中的应用，例如智能手表、智能汽车以及物联网中，甚至是在虚拟现实与生物科技项目中的应用。
CI过程目前所面临的一个挑战在于在开发环境中执行的自动化测试与生产环境之间总是存在着或多或少的差别。随着近来年以Docker为代表的容器化技术在（微）服务系统中的广泛应用，CI过程也从容器的使用中受益匪浅。Docker的高可移植性使多个CI提供商开始拥抱Docker。举例来说，CircleCI就支持基于容器的应用，而CodeShip近期也推出了Jet，这是一个对Docker应用进行测试与部署的解决方案。