GitLab CI/CD 前端 Angular 持续集成

CI/CD 是 Gitlab 提供的一整套持续集成、持续交付解决方案。

概念：「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」，概念理解详细见文章：简单理解持续集成、持续交付、持续部署 ^[1] 与 谈谈持续集成，持续交付，持续部署之间的区别^[2]

近期在抽空把团队工程化这块做好，CI/CD只是其中的九牛一毛。在运维同学协助配合下，以公司某项目前端工程做试验，实现了 CI 的过程，本质上CD也是支持了的，主要是看CD这个过程怎么做更好。自动触发了构建操作，还是直接使用构建后的 artifacts
 直接部署，走不走Jenkins后续方案等……下边简单介绍一下。

GitLab 的CI配置

前提：服务器部署有Runner了。

下边是举例 Angular前端工程 的 CI
 脚本，目前只做了代码检查和自动构建过程检测。实现自动化检查代码是否规范，前端限制了一些代码拼写规范、console.log禁用、alert禁用
 等 tslint的约束^[3]，这些都可以在工程下自定义维护规则。aot构建是为了进一步检查一些编译问题。只要两者通过，Jenkins 构建100%是无差错的。

image: node:10.4.1


cache:
    key: ${CI_COMMIT_REF_SLUG}
    paths:
        - node_modules/


stages:
    - lint
    # - test
    - build


job:lint:
    stage: lint
    before_script:
        # - apt-get update && apt-get install -y unzip fontconfig locales gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget
        - npm install --silent
    script: npm run lint


# job:test:
#     stage: test
#     before_script:
#         # - apt-get update && apt-get install -y unzip fontconfig locales gconf-service libasound2 libatk1.0-0 libc6 libcairo2 libcups2 libdbus-1-3 libexpat1 libfontconfig1 libgcc1 libgconf-2-4 libgdk-pixbuf2.0-0 libglib2.0-0 libgtk-3-0 libnspr4 libpango-1.0-0 libpangocairo-1.0-0 libstdc++6 libx11-6 libx11-xcb1 libxcb1 libxcomposite1 libxcursor1 libxdamage1 libxext6 libxfixes3 libxi6 libxrandr2 libxrender1 libxss1 libxtst6 ca-certificates fonts-liberation libappindicator1 libnss3 lsb-release xdg-utils wget
#         - npm install --silent
#     script: node_modules/.bin/ng test


job:build:
    stage: build
    script: npm run start:test
    # artifacts:
    #     name: "project-$CI_COMMIT_REF_NAME"
    #     paths:
    #         - dist/
    only:
        - master

Angular gitlab-ci.yml配置还可以参考：https://stackoverflow.com/questions/46269681/gitlab-ci-failing-with-angular-cli^[4]

开发分支

PR: pull request 或 merge request

每次提交或者 PR
 都会自动触发 job:lint
 ，PR
 在代码lint或者测试没有通过的情况下，是默认无法合并的（按钮禁用，权限大的用户才能跳过检查，但不建议，除非你想出错）。

更方便的是，PR
 可以设置为脚本执行通过后自动合并，当然如果需要 CR （code review）
 的话，可以设置为手动合并。 如果连测试都没有通过的代码，就没有必要 CR
 了。

master 分支

可以在 master 分支做持续交付操作（CD）, 主要就是自动化构建；将构建成功结果物，通过脚本来部署即可。如果还有后期的自动化接口或者组件测试，部署后执行测试，如果失败则回滚。按理是测试成功的代码，部署后就一般没有问题，除非是环境和数据引起的问题。

因为 master 分支是 dev 或者 test 分支 PR 合并过来的，所以他们的测试和代码检查一般都通过了的，当然，合并之前也会重新执行一次代码检查和测试，最后才会走构建的job。

Pipeline

Gitlab 的 Pipeline
 下可以看到每次提交触发Job的执行状态，可以对执行日记查看，对应job执行成功或失败都可以发生通知给开发者。

CD

从频繁提交代码、自动化测试(保证测试覆盖) -> 运行本地测试 -> 服务器运行测试 -> 部署到测试环境 -> 交付管理

而这些都应该是自动的，所以你需要知道的东西有: 如何编写测试(Junit、Qunit、BDD、TDD..)、自动化测试(Selenium..)、版本管理(git)、配置(feature toggle)、依赖管理、部署脚本等等。

从0起做好持续交付并不容易，涉及很多东西，从简单的做起吧。自动触发了构建操作，目前如何自动部署，走不走 Jenkins 后续方案讨论再定。可以保留 Jenkins 手动构建（出问题可以规避），也可以有自动化构建部署两种方案都有

推荐书籍：

•《持续交付:发布可靠软件的系统方法》^[5]

总结

把Runner搞成共享型的，前端的工程就不需要重复配置Runner了，后续逐步的改善即可。整合 DevOps，CI/CD 实现是必须的，目前市场和工具方案都特别成熟，个人认为，小团队或者大团队都有必要去学习掌握，以便改善团队的效能问题。一切能脚本自动化的工作，都不应该人工参与。无论如何，频繁部署、快速交付以及开发测试流程自动化都将成为未来软件工程的重要组成部分。

欢迎讨论~

References

[1]
 简单理解持续集成、持续交付、持续部署 : http://www.sohu.com/a/204476451_465922
[2]
 谈谈持续集成，持续交付，持续部署之间的区别: https://www.cnblogs.com/pegasus923/p/8674196.html
[3]
 tslint的约束: https://palantir.github.io/tslint/rules/
[4]
: https://stackoverflow.com/questions/46269681/gitlab-ci-failing-with-angular-cli
[5]
 《持续交付:发布可靠软件的系统方法》: https://book.douban.com/subject/6862062/

「前端工程化建设」其他相关文章：

Git commit message规范制定与实践

原文阅读体验更佳，可直接访问链接 ↓