Sha (Joe) Zhu | 那些年我们追过的CI

你是否与他人合作使用GitHub？
你是担心弄坏别人的代码还是更担心别人弄坏你的的代码呢?
你是否开发供他人使用的软件？
你的代码有很多依赖性吗？你担心某些开发会破坏你的代码吗？

如果以上任一情况成立，希望此文会对你有所帮助。

简而言之，持续整合工作流程目的在于:

在独立/全新构建的虚拟环境中测试代码；
检查代码是否运行，尤其是在被重新安装的情况下,
将测试过程与开发过程分开。持续整合的过程是全自动的，从而不会对当前的工作改进造成太大干扰。

CI工具只需通过Webhook与GitHub存储库连接即可。每当检测到新的提交时，CI工具都会获取配置（yaml）文件，并按照您的说明构建虚拟机，安装，执行和测试您的代码，并确保一切都能按预期进行。

如果您仍然不确定，请查看此博客，Gitlab告诉您为什么应该使用持续整合。

以下是小编每天使用的CI工具列表，希望它们对你也有所帮助。

Travis CI

TravisCI算的上是上古级并且可能是使用最广泛的CI之一了。让小编以小编的程序 — DEploid 上的示例为例，说明配置文件的作用。

DEploid软件包是用c ++编写的。该软件设计用于对未知比例的混合基因组进行分型。你可以在小编主页找到更多信息。对于TravisCI配置，以下内容定义了您将需要在OS上安装的语言，操作系统和依赖项：用于MacOS的homebrew，以及用于Linux的apt。

language: cpp
os:
  - osx
  - linux

addons:
  homebrew:
    update: true
    brewfile: true
  apt:
    packages:
      - libcppunit-dev
      - valgrind
      - r-base-core
      - lcov
      - python-pip
      - doxygen
      - graphviz

下面这段定义了我们测试使用gcc和clang编译器来编译DEploid。对于大多数程序，一般只使用一个编译器, 小编做测试而已。 “安装前”部分定义了我在Linux系统上检查的一些额外内容，例如编码样式和测试范围。

compiler:
  - gcc
  - clang
before_install:
  - echo $LANG
  - echo $LC_ALL
  - if [ $TRAVIS_OS_NAME == linux ]; then pip install --user cpp-coveralls cpplint; fi
  - if [ $TRAVIS_OS_NAME == linux ]; then apt-cache policy zlib*; fi
  - if [ $TRAVIS_OS_NAME == linux ]; then .ci/style.sh; fi

以下部分定义了如何安装DEploid，以及许多检查，包括：检查输入/输出，结果向后兼容，直接从GitHub下载并安装。成功编译并安装后，它将覆盖报告发送到 coverall。

before_script:
  - ./bootstrap

script:
  - make
  - make check
  - if [ $TRAVIS_OS_NAME == linux ]; then ./tests/test_binary.sh; fi
  - ./tests/testPOS.sh
  - ./tests/test_binaryVcfVsTxt.sh
  - ./tests/test-against-previous-version.sh
  - ./tests/test_binaryReproducible.sh
  - if [ $TRAVIS_OS_NAME == linux ]; then cd docs/doxygen; doxygen Doxyfile; cd ../..; fi
  - rm -r *
  - wget --no-check-certificate https://github.com/DEploid-dev/DEploid/archive/master.tar.gz -o /dev/null
  - tar -xf master.tar.gz
  - cd DEploid-master
  - ./bootstrap
  - make; make check
  - cd ..; rm -r *
  - wget --no-check-certificate https://github.com/DEploid-dev/DEploid/archive/master.tar.gz -o /dev/null
  - tar -xf master.tar.gz
  - mv DEploid-master/* .
  - ./bootstrap
  - make; make check
after_success:
  - coveralls --exclude lib --exclude tests --exclude src/random --exclude src/codeCogs/ --exclude src/export/ --exclude src/gzstream/ --gcov-options '\-lp'

如果您构建R软件包，TravisCI是一个很好的选择。它允许使用三个不同的测试R版本。从基本版本到开发版本，这都很方便。有关更多信息，请参见文档.

Circleci

小编开始使用circleci的起因是寻找可以免费支持私有repo的CI（这是在Github CI破石而出之前的故事了）。过去，circleci与TravisCI非常相似，配置文件相差无几。几年前，Circleci-II的推出产生了颠覆性的改变。

Circleci-II具有许多不错的功能，它支持更复杂的编译矩阵，即不同版本的gcc编译器，不同版本的Ubuntu。 Circleci-II的优点是它与Docker很好地集成。因此，该过程可以很容易地兑现或堆叠，这使测试变得更快。

AppVeyor

AppVeyor可能是第一个支持Windows OS的CI工具。不是很好用, 每次都花很长的时间调试

Github CI

尽管GitHub是最受程序员欢迎的平台，并且其他所有东西都与Github挂钩，但Github直到2019年才宣布其CICD流程（测试版）。但是，迟来的加入并没有使Github CICD框架变得不那么受欢迎。小编觉得Github已经花了很长时间让这个浮躁的世界沉淀了沉淀。它确实了解了开发人员想要什么以及如何最好地实现目标。

首先，它支持公共和私人repo，用户无需担心host的成本。因为像小编这样的穷程序员还有几十个repo，这是再好不过的了。

其次，它真的很快！说实话，小编还没有用秒表测试。但是从经验来看，action几乎是在提交内容的第二秒触发的。与其他CI平台不同，除非您为该服务付费，否则这将取决于在线用户的数量。

使用带有秘密的CICD框架真的很容易，存储库可以彼此交互。它使自动编码变得更加容易。

Summary

对于未来，小编会继续使用所有列出的CI工具，但越来越倾向于github CI。只因为

快速且易于使用
支持私人repo
轻松支持复杂的工作流程（CICD）
显然它支持任何操作系统，我的意思是* nix可能很容易。应该也支持Windows, 反正github现在是微软家的，顺水推舟不是吗？

有关更多信息，您可以从Google撰写的blog中找到更多东西，他们在其中比较了更多工具。