持续集成与持续部署

最新推荐文章于 2023-07-09 17:39:23 发布

19岁的墨先生

最新推荐文章于 2023-07-09 17:39:23 发布

阅读量1.7k

点赞数 1

分类专栏：前端工程化文章标签： ci/cd

本文链接：https://blog.csdn.net/weixin_44257930/article/details/127281445

版权

前端工程化专栏收录该内容

3 篇文章 0 订阅

订阅专栏

一、持续集成

1.1 核心概念

1.1.1 持续集成

持续集成（英文：Continuous Integration，简称CI）。

在软件工程中，持续集成是指将所有开发者工作副本每天多次合并到主干的做法

持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起

1.1.2 持续交付

持续交付（英文：Continuous Delivery，简称CD）。

完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码发布到存储库。

持续交付的目标是拥有一个可随时部署到生产环境的代码库。

1.1.3 持续部署

持续部署（英文：Continuous Deployment，简称CD）。

持续交付——的延伸，持续部署可以自动将应用发布到生产环境

1.2 组成部分及常见工作流

1.2.1 组成要素

一个最小化的持续集成系统需要包含以下几个要素：

版本管理系统：项目的源代码需要托管到适合的版本管理系统中，一般我们使用git作为版本控制库，版本管理软件可以使用github、gitlab、stash等。
构建脚本&工具：每个项目都需要有构建脚本来实现对整个项目的自动化构建。比如Java的项目就可以使用gradle作为构建工具。通过构建工具实现对编译、静态扫描、运行测试、样式检查、打包、发布等活动串起来，可以通过命令行自动执行。
CI服务器：CI服务器可以检测项目中的代码变动，并及时的通过构建机器运行构建脚本，并将集成结果通过某种方式反馈给团队成员。

1.2.2 应用场景

打包平台

常见的打包，Java应用（Gradle/Maven）、Nodejs前端应用(npm/yarn)

移动端打包：Android/iOS
测试平台

接口测试

自动化测试Robotium、Testlink

单元测试junit

性能测试Jmeter
自动部署

FTP

Shell

Tomcat/Dokcer

Kubernetes/Rancher/Cluster
持续集成

Git: gitlab github gitee等

Jenkins/TravisCi/CircleCI

Docker

1.2.3 工作流

传统的工作流

主要流程：

项目一开始是先划分好模块，分配模块给相应的开发人员；
开发人员开发好一个模块就进行单元测试；
等所有的模块都开发完成之后，由项目经理对所有代码进行集成；
集成后的项目由项目经理部署到测试服务器上，被交由测试人员进行集成测试；
测试过程中出现 Bug 就提把问题记录进行 Bug 列表中；
项目经理分配 Bug 给相应的责任人进行修改；
修改完成后，项目经理再次对项目进行集成，并部署到测试服务器上；
测试人员在下一次的集成测试中进行回归测试；
通过通过之后就部署到生产环境中；
如果测试不通过，则重复上述“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作。

带来的问题：

重复性劳动，无效的等待变多

重复的进行发布部署。

流程上：有可能开发在等集成其他人的模块；测试人员在等待开发人员修复 Bug；产品经理在等待新版本上线好给客户做演示；项目经理在等待其他人提交代码。不管怎么样，等待意味低效。

自动化部署工作可以解放了集成、测试、部署等重复性劳动，而且机器集成的频率明显可以比手工的高很多。
很晚才发现缺陷，并且难以修复
低品质的软件，软件交付时机无法保障

由于集成时每次包含的代码很多，所以大家的关注点主要都是如何保证编译通过、自动化测试通过，而往往很容易忽略代码是否遵守了编码规范、是否包含有重复代码、是否有重构的空间等问题。而这些问题又反过来会影响今后的开发和集成，久而久之集成变得越来越困难，软件的质量可想而知。
项目缺少可见性

某些项目，程序会经常需要变更，特别是敏捷开发的实践者。由于产品经理在与客户交流过程中，往往实际的软件就是最好的原型，所以软件会被当作原型作为跟客户交流的工具。当然，客户最希望的当然是客户的想法能够马上反映到原型上，这会导致程序会经常被修改的。那么也就意味着“分配 Bug -> 修改 Bug -> 集成代码 -> 部署到测试服务器上 -> 集成测试”工作无形又爆增了。

常见的工作流

在这里插入图片描述

开发者检入代码到源代码仓库。
CI系统会为每一个项目创建了一个单独的工作区。当预设或请求一次新的构建时，它将把源代码仓库的源码存放到对应的工作区。
CI系统会在对应的工作区内执行构建过程。
配置如果存在）构建完成后，CI系统会在一个新的构件中执行定义的一套测试。完成后触发通知(Email,RSS等等)给相关的当事人。
配置如果存在）如果构建成功，这个构件会被打包并转移到一个部署目标(如应用服务器)或存储为软件仓库中的一个新版本。软件仓库可以是CI系统的一部分，也可以是一个外部的仓库，诸如一个文件服务器或者像Java.net、SourceForge之类的网站。
CI系统通常会根据请求发起相应的操作，诸如即时构建、生成报告，或者检索一些构建好的构件。

常见问题：

思维转变后，新技术抵触
- 无法接受新事物：不管怎么样，求稳心态的人还是多。总是有人认为老的技术代表稳定，新的事物往往会带来问题。
- 认为手工集成也没有多少工作量：不是所有的人都参与到了整个持续集成的环节，所以没有办法认识到问题全貌。
管理层的抵触
- 培训持续集成需要投入资金啊，没钱。
- 持续集成服务器要增加软硬件成本啊，没钱。
- 开发人员领了那么高的工资，多干活多加班应该啊。
针对这一点，可以从开发人员的成本和持续集成的投入（软硬件）的成本上两者做下估算。

硬件参考：

Jenkins主服务器一般2C4G，slave服务器根据生产需要进行选购。

git服务器一般2C4G(10人团队)

Docker服务器8C32G(Rancher + harbor)
生产环境的复杂
- 比如部署的生成环境是在政务外网，无法从互联网直接访问等。
- 构建效率低下，任务多

1.3 效率工具对比

1.3.1 Jenkins

能实时监控集成中存在的错误，提供详细的日志文件和提醒功能，还能用图表的形式形象地展示项目构建的趋势和稳定性

易安装：Jenkins是一个独立的基于Java的程序，随时可以运行，包含Windows，Mac OS X和其他类Unix操作系统的软件包。仅仅一个 java -jar jenkins.war，从官网下载该文件后，直接运行，无需额外的安装，更无需安装数据库；
易配置：提供友好的GUI配置界面；
变更支持：Jenkins能从代码仓库（Subversion/CVS）中获取并产生代码更新列表并输出到编译输出信息中；
支持永久链接：用户是通过web来访问Jenkins的，而这些web页面的链接地址都是永久链接地址，因此，你可以在各种文档中直接使用该链接；
集成E-Mail/RSS/IM：当完成一次集成时，可通过这些工具实时告诉你集成结果（据我所知，构建一次集成需要花费一定时间，有了这个功能，你就可以在等待结果过程中，干别的事情）；
JUnit/TestNG测试报告：也就是用以图表等形式提供详细的测试报表功能；
支持分布式构建：Jenkins可以把集成构建等工作分发到多台计算机中完成；
文件指纹信息：Jenkins会保存哪次集成构建产生了哪些jars文件，哪一次集成构建使用了哪个版本的jars文件等构建记录；
支持第三方插件：使得 Jenkins 变得越来越强大；凭借更新中心中的数百个插件，Jenkins几乎集成了持续集成和持续交付工具链中的所有工具。
Rest API - 可以访问控制您获取的数据量，获取/更新config.xml，删除作业，检索所有构建，获取/更新作业说明，执行构建，禁用/启用作业

Jenkins优点：

价格（免费）
定制
插件系统
完全控制系统

Jenkins缺点：

需要专用服务器（或多个服务器）。这导致额外的费用。对于服务器本身，DevOps等…
配置/定制所需的时间

1.3.2 Travis CI

一个托管的持续集成服务，用于构建和测试在GitHub上托管的软件项目

基于云：TravisCI是一个基于云的系统 - 不需要专用服务器，您无需管理它。
支持Docker运行测试
使用YAML文件进行配置
可选择Linux和Mac OSX上同时运行测试
开箱即用的支持的语言

Android，C，C＃，C ++，Clojure，Crystal，D，Dart，Erlang，Elixir，F＃，Go，Groovy，Haskell，Haxe，Java，JavaScript（使用Node.js），Julia，Objective-C，Perl，Perl6， PHP，Python，R，Ruby，Rust，Scala，Smalltalk，Visual Basic
支持多环境构建矩阵：如Python 2.7 , 3.4, 3.5 + Django 1.8, 1.9, 1.10

构建矩阵是一种工具，可以使用不同版本的语言和包运行测试。您可以以不同的方式自定义它。例如，某些环境的失败可以触发通知但不会使所有构建失败（这对包的开发版本有帮助）

Travis CI优点：

开箱即用构建矩阵
快速启动
轻量级YAML配置
开源项目的免费计划
无需专用服务器

Travis CI缺点：

与CircleCI相比，价格更高，没有免费的企业计划
定制（对于某些你需要第三方的东西）

1.3.3 Circle CI

在GitHub或Bitbucket上的软件存储库被授权并作为项目添加到circleci.com之后，每个代码更改都会在干净的容器或VM中触发自动化测试

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

CircleCI优点：

快速启动
CircleCI有一个免费的企业项目计划
这很容易，也很快开始
轻量级，易读的YAML配置
您不需要任何专用服务器来运行CircleCI

CircleCI缺点：

CircleCI仅支持2个版本的Ubuntu免费（12.04和14.04）和MacOS作为付费部分
尽管CircleCI可以使用并运行所有语言，但tt仅支持“开箱即用”的以下编程语言：Go（Golang），Haskell，Java，PHP，Python，Ruby / Rails，Scala
虽然作为基于云的系统是一方的优势，它也可以停止支持任何软件，你将无法阻止

1.3.4 总结

分类	Jenkins	Travis CI	Circle CI
本地部署	支持	不支持	支持
REST API	支持	支持	支持
配置	复杂，高度可配置	YAML文件	YAML文件
按需安装	是	否	是
跨平台支持	是	Linux + MacOS	Linux + MacOS(付费)
多服务器	是	按需	否
快速构建	手动配置复杂	快(需要写配置文件)	最快
基本环境	Java	云环境	云环境
费用	免费	特定免费(69$/c)	特定免费(50$/c)