无需单元测试的持续集成

您是否认为持续集成不适合您，因为您没有自动化测试？或者根本没有单元测试？并非如此。测试固然重要。但持续集成涉及的方面远不止测试。

1. 构建代码库

然而，这是持续集成应该解决的最关键问题。代码库的主分支应该始终构建/编译。甚至提一下都显得有点傻。  

假设一个 12 人的团队。假设主分支上出现了一个错误的提交。每个人都拉取代码。这时，就开始了查找错误并协调谁应该或将要修复该错误的过程。这种混乱会让整个团队大约 30 分钟无法集中注意力，而且还会带来挫败感。

假设这种情况每周发生一次（每个人最终都会犯错）。30 分钟 x 12 个人每周就会损失 8 个小时。

如果你同意的话你也可以：

• 设置 CI 流程，防止错误构建进入主分支
• 每周给一名开发人员放一天假

同样的结果，更快乐的团队:)

设置一个确保代码库能够编译的 CI 流程只需不到半天的时间。这绝对值得。

2.静态代码分析

这在几乎所有语言中都是免费的，并且是按照一组预定义的规则运行的一行程序：

• Javascript：eslint、tslint

• Java：sonarlint

• Python：pylint

• 去：golint

设置静态代码分析（或 linting）大约需要 1 小时。这有什么好处呢？

您的主分支中代码格式良好，且“按规矩办事”。这显著提升了您的代码库质量。

如果这只是你最不关心的问题，因为你的团队总是急于赶工期，那么不妨这样想：你的代码审查流程会更快。任何与代码结构、最佳实践等相关的内容都已在你的持续集成流程中检查完毕。无需再进行审查或讨论。你的开发人员可以专注于代码审查的业务内容。

一大福利：开发人员自动学习代码规范。静态分析工具会提供违反的规则以及错误原因。

约定的一大障碍是，开发者对于制表符和空格之类的东西固执己见。归根结底，好的约定是所有人都遵守的约定。选择一套标准约定，并遵循它。

3.文化变革

持续集成并非技术问题，而是一个团队协作的过程。您需要以小增量的方式工作，并经常将代码集成到主分支。请参阅如何开始使用持续集成 (CI)，详细了解文化目标的真正含义。

在团队掌握了第一批关键要素后，应该进行另一次转变。人们会意识到，以更小的增量工作效率更高。自动检查基本错误将增强更快合并代码的信心。 

因此，分支的生命周期将会缩短。代码审查将会更快。每个人都将使用几乎最新的代码。这将避免由于人们分散工作而导致的版本漂移和合并冲突。请参阅“为什么不应该使用功能分支”来了解其全部优势。

归根结底，CI 与我们的人类骄傲和自我有关。  

每个人都会很高兴有一个工具可以在错误传播到世界之前发现它。 

如何开始？

这是一个非常简单且可操作的入门流程。无论您的 Git 提供商是什么，它都可以正常工作：GitHub、Bitbucket、Gitlab、Azure DevOps 等等。

1. 启用拉取请求 (PR) 流程

锁定主分支，禁止直接推送。所有内容都应通过 PR 提交。以下是Github、Bitbucket、GitLab和Azure DevOps的相关链接。

2. 选择 CI 平台

每个 Git 提供商都允许为你的 PR 定义构建流水线。构建将在 PR 创建时以及每次推送到 PR 所属分支时运行。完成 PR（即合并分支）的先决条件是成功构建。

CI 的主要参与者有 CircleCI、Codeship、Travis CI。

我当然推荐Fire CI，因为它是我构建的平台。我并不认为它在每种用例上都比其他平台更好。

选择一个并开始。

3. 定义 2 行构建

我们想要实现的最基本的构建是构建 + 静态代码分析。只需在 shell 中执行 2 到 3 个命令即可实现。

所有 CI 平台都支持“配置即代码”。您只需在仓库根目录下的 *.yml 文件中定义构建，平台就会自动获取该文件。

以 Fire CI 为例，您需要在 repo 的根目录下添加一个 .fire.yml 文件，如下所示：

pipeline: 
  dockerfile: Dockerfile

然后，添加一个名为“Dockerfile”的文件来构建你的应用。以下是一些简单的 Dockerfile 示例。

任何基于 yarn/npm 的技术，例如 React/Angular/Vue/Node：

FROM python:3
WORKDIR /app 
COPY . .
RUN yarn
RUN yarn lint
RUN yarn build

Python：

FROM python:3
WORKDIR /app 
COPY . .
RUN pip install all_your_dependencies
RUN pylint all_your_python_files.py 

去：

FROM golang:latest
WORKDIR /app
COPY . .
RUN go build -o main .

我还可以继续举更多例子。这些例子比较简单，如果再添​​加几个命令，效果会更好。不过你懂的：很简单。

可选：启用代码审查

现在，所有代码贡献都通过 PR 进行，代码审查变得轻而易举。每个 Git 提供商都拥有出色的用户界面，可以呈现代码差异并方便用户评论。

如果您是新手，请不要强制指定一组审核人员，因为这会拖慢团队进度。请尽最大努力启动一个互相审核代码的流程，并在此基础上继续完善。

那么接下来呢？

正如所有事情一样，胸怀大志，从小事做起。建立持续集成流程，开启无限可能。

测试

一旦基本流程到位，添加第一个自动化测试就变得轻而易举。然后添加其他测试。少量但持续的努力就能在不知不觉中带来惊人的测试覆盖率。

我建议你保持精简，不要把精力花在“我们来写些测试”上。检查哪些经常出错，或者哪些需要大量手动测试。把这些自动化。 

始终牢记生产力。仅仅因为测试而进行大量测试毫无意义。

其他福利

市面上有很多工具可以集成到你的持续集成流程中。它们并非关键，但考虑到其带来的收益，付出的努力是值得的。

以下是一些示例。链接适用于 GitHub 市场，但其他 git 提供商也同样易于集成。

• 自动更新依赖项：Depfu会建议您自动更新依赖项。这样，您就可以通过小幅增量更新保持最新状态。这比一年一次的“让我们更新所有内容”策略要好得多。

• 开源安全：Snyk警告您有关开源库的安全威胁

• 图片优化：ImgBot会检测你仓库中的大图片，并提交包含尺寸优化版本的 PR。虽然这适用于前端项目，但仍然很棒。

市面上还有很多其他产品。浏览市场，寻找能帮你解决问题的产品。

不过要小心！克制住想用所有能想到的办法的冲动。选择那些真正能提高生产力的。那些没人关注的免费指标或工具是有害的，因为人们不知道该如何使用它们。

结论

您不需要花哨的测试套件来开始持续集成。 

只需 2 小时的努力就能让你开始行动，并实现团队生产力的良性循环。

你的团队和项目越大，收益就越大。2020年了，没有理由不采用持续集成 (CI) 流程。

如果您需要帮助为您的团队设置 CI 流程，请随时联系我。我很乐意为您提供帮助。

感谢您的阅读并祝您好运！

最初发表于The Fire CI Blog。
（精彩的封面照片来自Unsplash 上的 Will Porada）