前言

近几年，伴随着前端技术日新月异的发展，前端开发中前后端分离，工程化，自动化等现代化的开发模式越来普及，前端项目也引入了编译，构建，单元测试等现代软件工程化的标准环节。这样大提高了前端的开发效率和业务交付能力。但是，在代码集成，项目部署阶段，我们还需要引入CI/CD等现代化的软件开发实践，来减少风险和重复过程，节省我们的时间。

CI/CD 是一种通过在应用开发阶段引入自动化来频繁向客户交付应用的方法。CI/CD 的核心概念是持续集成、持续交付和持续部署。作为一个面向开发和运营团队的解决方案，CI/CD 主要针对在集成新代码时所引发的问题（亦称：“集成地狱”）。

具体而言，CI/CD 可让持续自动化和持续监控贯穿于应用的整个生命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷方式协同支持。

CI 持续集成（Continuous Integration）

现代应用开发的目标是让多位开发人员同时处理同一应用的不同功能。但是，如果企业安排在一天内将所有分支源代码合并在一起（称为“合并日”），最终可能造成工作繁琐、耗时，而且需要手动完成。这是因为当一位独立工作的开发人员对应用进行更改时，有可能会与其他开发人员同时进行的更改发生冲突。如果每个开发人员都自定义自己的本地集成开发环境（IDE），而不是让团队就一个基于云的 IDE 达成一致，那么就会让问题更加雪上加霜。

持续集成（CI）可以帮助开发人员更加频繁地（有时甚至每天）将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。

CD 持续交付（Continuous Delivery）

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。

在持续交付中，每个阶段（从代码更改的合并，到生产就绪型构建版本的交付）都涉及测试自动化和代码发布自动化。在流程结束时，运维团队可以快速、轻松地将应用部署到生产环境中。

CD 持续部署（Continuous Deployment）

对于一个成熟的 CI/CD 管道来说，最后的阶段是持续部署。作为持续交付——自动将生产就绪型构建版本发布到代码存储库——的延伸，持续部署可以自动将应用发布到生产环境。由于在生产之前的管道阶段没有手动门控，因此持续部署在很大程度上都得依赖精心设计的测试自动化。

实际上，持续部署意味着开发人员对应用的更改在编写后的几分钟内就能生效（假设它通过了自动化测试）。这更加便于持续接收和整合用户反馈。总而言之，所有这些 CI/CD 的关联步骤都有助于降低应用的部署风险，因此更便于以小件的方式（而非一次性）发布对应用的更改。不过，由于还需要编写自动化测试以适应 CI/CD 管道中的各种测试和发布阶段，因此前期投资还是会很大。

Docker 官网

Docker是一个开源的引擎，可以轻松的为任何应用创建一个轻量级的、可移植的、自给自足的容器。开发者在笔记本上编译测试通过的容器可以批量地在生产环境中部署，包括VMs（虚拟机）、 bare metal、OpenStack 集群和其他的基础应用平台。

Docker通常用于如下场景：

• web应用的自动化打包和发布；
• 自动化测试和持续集成、发布；
• 在服务型环境中部署和调整数据库或其他的后台应用；
• 从头编译或者扩展现有的OpenShift或Cloud Foundry平台来搭建自己的PaaS环境。

Docker系统有两个程序：docker服务端和docker客户端。其中docker服务端是一个服务进程，管理着所有的容器。docker客户端则扮演着docker服务端的远程控制器，可以用来控制docker的服务端进程。大部分情况下，docker服务端和客户端运行在一台机器上。

Jenkins 官网

Jenkins是开源CI&CD软件领导者， 提供超过1000个插件来支持构建、部署、自动化， 满足任何项目的需要。Jenkins 支持各种运行方式，可通过系统包、Docker 或者通过一个独立的 Java 程序。

Jenkins 有一个功能强大的扩展和插件系统，允许开发人员编写影响 Jenkins 几乎每个方面行为的插件。 即使是大部分“核心”功能都是以扩展的形式编写的 — 扩展也可以由插件提供。

一些比较明显的扩展点包括 SCM implementations：将 Git、Subversion 或 Perforce 等 SCM 集成到 Jenkins 中; build steps：提供从方便的用户界面到配置构建工具、到发送电子邮件等所有内容; 还有 authentication realms：将 Jenkins 与单点登录系统或外部用户目录（如 LDAP 或 Active Directory）集成。

Jenkins如何使用 npm去组合构建简单的 Node.js 和 React 应用 ，详细教程。

Jenkins被许多公司使用，其中包括Facebook，Sony，Netflix，Tumblr，Yahoo，eBay等。Jenkins具有易于安装，配置，丰富的插件可用性，可扩展性以及可在不同计算机上分发的版本。

CircleCI 官网

CircleCI提供轻松的设置和维护，没有任何困难。这是一个基于云的系统，这意味着不需要专用服务器，也不需要维护/管理具有免费计划的服务器，甚至对于企业帐户也是如此。

CircleCI可以与GitHub，Amazon EC2，Appfog，dotCloud等集成，并被Facebook，Spotify，Kickstarter，RedBull，Harvest和Teespring等许多公司使用。CircleCI属性（如Github集成）社区成员最强调快速构建，轻松设置，松弛集成，Docker支持和出色的客户支持。

CircleCI特性：

• CircleCI是一个基于云的系统 – 不需要专用服务器，您无需管理它。 但是，它还提供了一个本地解决方案，允许您在私有云或数据中心中运行它；
• 即使是商业帐户，它也有免费计划；
• Rest API – 您可以访问项目，构建和工件（artifacts）。构建的结果将是工件或工件组。 工件可以是已编译的应用程序或可执行文件（例如，android APK）或元数据（例如，关于测试`成功的信息）；
• CircleCI 缓存必要的安装（requirements installation）。 它会检查第三方依赖项，而不是持续安装所需的环境；
• 您可以触发SSH模式访问容器并进行自己的调查（如果出现任何问题）；
• 这是一个完整的开箱即用解决方案，需要最少的配置\调整。

Jenkins和CircleCI之间的主要区别

• Jenkins可以通过多线程支持多个作业，而CircleCI内置了对并行性的支持，可以通过项目设置来实现。
• 在Jenkins中，使用存储在Jenkins服务器中的设置的Web UI配置构建，而在CircleCI中，可以使用“ circle.yaml”文件构建作业。
• CircleCI具有调试“通过SSH调试”的最佳功能，这使调试更加容易，而Jenkins我们需要通过单击Jobs进行手动调试。
• CircleCI会在没有警告的情况下更改环境，这是一个问题，而在Jenkins中，只有在用户指示时它才会更改。
• 在Jenkins中，我们可以使用专用服务器缓存Docker映像，而在CircleCI中，我们不能缓存Docker映像。
• 在Jenkins中，将使用Jenkins凭据和插件对机密进行加密，而在CircleCI中，我们没有Jenkins这样的安全性。

GitLab 官网

GitLab是Ruby开发的自托管的Git项目仓库，可通过Web界面访问公开的或者私人的项目。

它拥有与Github类似的功能，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，它非常易于浏览提交过的版本并提供一个文件历史库。它还提供一个代码片段收集功能可以轻松实现代码复用，便于日后有需要的时候进行查找。

前端工程化

前端工程化搭建举例

工具	描述
jenkins	搭建 CI / CD 服务
verdaccio	搭建npm私有库
yapi	搭建 api mock server
mongo	暂时就提供给yapi的
nginx	做基本的代理

 CI / CD 服务大概的工作：

搭建流程图

• git：基本命令操作和分支策略
• shell: shell 脚本的基础用法
• centos：centos需要的基础知识点
• docker：基础使用docker去创建镜像，容器，持久化数据卷等
• jenkins：jenkins 多分支流水线等基础配置
• nginx：如何开启gzip和代理等基础知识
• npm：简单的发布包等
• mongodb：基础知识点和操作