持续集成与持续部署实践 pdf（如何在 linux 上配置持续集成服务）

本文目录

• 如何在 linux 上配置持续集成服务
• coding持续集成之自动发布
• 持续集成的好处
• 如何理解持续集成，持续交付，持续部署
• 如何理解持续集成、持续交付、持续部署
• 如何做到持续集成
• 什么是持续集成
• 项目打包和自动化部署

如何在 linux 上配置持续集成服务

1. 安装 Docker首先，我们要安装 docker，因为这是 Drone 的工作流的最关键的元素。Drone 合理的利用了 docker 来构建和测试应用。容器技术提高了应用部署的效率。要安装 docker ，我们需要在不同的 linux 发行版本运行下面对应的命令，我们这里会说明 Ubuntu 14.04 和 CentOS 7 两个版本。Ubuntu要在 Ubuntu 上安装 Docker ，我们只需要运行下面的命令。# apt-get update # apt-get install docker.io安装之后我们需要使用service命令重启 docker 引擎。# service docker restart然后我们让 docker 在系统启动时自动启动。# update-rc.d docker defaults Adding system startup for /etc/init.d/docker ... /etc/rc0.d/K20docker -》 ../init.d/docker /etc/rc1.d/K20docker -》 ../init.d/docker /etc/rc6.d/K20docker -》 ../init.d/docker /etc/rc2.d/S20docker -》 ../init.d/docker /etc/rc3.d/S20docker -》 ../init.d/docker /etc/rc4.d/S20docker -》 ../init.d/docker /etc/rc5.d/S20docker -》 ../init.d/dockerCentOS第一，我们要更新机器上已经安装的软件包。我们可以使用下面的命令。# sudo yum update要在 centos 上安装 docker，我们可以简单的运行下面的命令。***隐藏网址***安装好 docker 引擎之后我么只需要简单使用下面的systemd命令启动 docker，因为 centos 7 的默认初始化系统是 systemd。# systemctl start docker然后我们要让 docker 在系统启动时自动启动。# systemctl enable docker ln -s ’/usrb/systemd/system/docker.service’ ’/etc/systemd/system/multi-user.target.wants/docker.service’2. 安装 SQlite 驱动Drone 默认使用 SQlite3 数据库服务器来保存数据和信息。它会在 arb/drone/ 自动创建名为 drone.sqlite 的数据库来处理数据库模式的创建和迁移。要安装 SQlite3 我们要完成以下几步。Ubuntu 14.04因为 SQlite3 存在于 Ubuntu 14.04 的默认软件库，我们只需要简单的使用 apt 命令安装它。# apt-get install libsqlite3-devCentOS 7要在 Centos 7 上安装需要使用下面的 yum 命令。# yum install sqlite-devel3. 安装 Drone最后，我们安装好依赖的软件，我们现在更进一步的接近安装 Drone。在这一步里我们只简单的从官方链接下载对应的二进制软件包，然后使用默认软件包管理器安装 Drone。Ubuntu我们将使用 wget 从官方的 Debian 文件下载链接下载 drone 的 debian 软件包。下面就是下载命令。# wget downloads.drone.io/master/drone.deb Resolving downloads.drone.io (downloads.drone.io)... 54.231.48.98 Connecting to downloads.drone.io (downloads.drone.io)|54.231.48.98|:80... connected. HTTP request sent, awaiting response... 200 OK Length: 7722384 (7.4M) 下载好之后，我们将使用 dpkg 软件包管理器安装它。# dpkg -i drone.deb Selecting previously unselected package drone. (Reading database ... 28077 files and directories currently installed.) Preparing to unpack drone.deb ... Unpacking drone (0.3.0-alpha-1442513246) ... Setting up drone (0.3.0-alpha-1442513246) ... Your system ubuntu 14: using upstart to control Drone drone start/running, process 9512CentOS在 CentOS 机器上我们要使用 wget 命令从下载链接下载 RPM 包。***隐藏网址***然后我们使用 yum 安装 rpm 包。# yum localinstall drone.rpm4. 配置端口***隐藏网址*** port=":80"5. 集成 Github为了运行 Drone 我们必须设置最少一个和 GitHub、GitHub 企业版，Gitlab，Gogs，Bitbucket 关联的集成点。在本文里我们只集成了 github，但是如果我们要集成其他的服务，我们可以在配置文件做修改。为了集成 github 我们需要在github 的设置里创建一个新的应用

coding持续集成之自动发布

服务器环境-centos7.2 使用技术如下： CODING 的持续集成本质上就是每次实例化一台 CVM，再把 Jenkins 安装进去，和我们在普通的云服务器上部署是一样的。 CODING 持续集成会为每个构建任务分配一台 VM 作为构建资源，您可以通过内置的 agent label 来使用不同的环境进行构建。目前支持的构建环境有三种： 默认环境中提供的 SDK 以及对应的版本如下（更新日期：2019 年 11 月 30 日）： android-sdk: 26.1.1 build-essential java: 1.8.0_191 python: 2.7.12 python3: 3.5.2 python3.7: 3.7.3 nodejs: 10.15.3 php: 7.3.5 ruby: 2.6.0 go: 1.12.4 dotnet-core: 2.2 erlang: Erlang/OTP 21 elixir: 1.8.1 默认环境中提供的命令行工具以及对应的版本如下（更新日期：2019 年 11 月 30 日）： cmake: 3.5.1 maven: 3.6.1 gradle: 4.10.3 nvm: 0.34.0 yarn: 1.15.2 composer: 1.8.5 bundler: 1.17.2 rvm: 1.29.7 docker: 18.09.1 docker-compose: 1.23.1 kubectl: 1.14 rancher: 2.2.0 helm: 2.13.1 coscmd: 1.8.5.36 tccli: 3.0.67.1 svn: 1.9.3 mercurial: 3.7.3 git: 2.7.4 git-lfs: 2.7.2 jq: 1.5-1-a5b5cbe pigz: 2.3.1 sshpass: 1.05 vsftpd: 3.0.3 通过上图可以设置根据不同的触发规则来自动构建项目达到自动发布的目的。

持续集成的好处

减少风险。可以节省时间、费用和工作量。持续集成可以让您在任何时间发布可以部署的软件。增强项目的可见性。建立团队对开发产品的信心。

持续集成是一种软件开发实践，即团队开发成员经常集成他们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。

减少风险

一天中进行多次的集成，并做相应的测试，有利于检查缺陷，了解软件的健康状况，减少假定。

减少重复过程

减少重复过程可以节省时间、费用和工作量。说起来简单，做起来难。这些浪费时间的重复劳动可能在我们的项目活动的任何一个环节发生，包括代码编译、数据库集成、测试、审查、部署及馈。

通过自动化的持续集成可以将这些重复的动作都变成自动化的，无需太多人工干预，让人们的时间更多地投入到动脑筋的、更高价值的事情上。

任何时间、任何地点生成可部署的软件

持续集成可以让您在任何时间发布可以部署的软件。从外界来看，这是持续集成最明显的好处，我们可以对改进软件品质和减少风险说起来滔滔不绝。

但对于客户来说，可以部署的软件产品是最实际的资产。利用持续集成，您可以经常对源代码进行一些小改动，并将这些改动和其他的代码进行集成。如果出现问题，项目成员马上就会被通知到，问题会第一时间被修复。

增强项目的可见性

持续集成让我们能够注意到趋势并进行有效的决策。如果没有真实或最新的数据提供支持，项目就会遇到麻烦，每个人都会提出他最好的猜测。

建立团队对开发产品的信心

持续集成可以建立开发团队对开发产品的信心，因为他们清楚地知道每一次构建的结果，他们知道他们对软件的改动造成了哪些影响，结果怎么样。

以上内容参考：百度百科 ——持续集成

如何理解持续集成，持续交付，持续部署

持续交付，持续部署都算是持续集成过程中的一部分吧持续集成就是类似于一个集成环境，你需要什么样的功能，就往上集成这个功能，形成一个持续的过程，我大概就是这么理解的其实定义不用太会，知道怎么去持续集成就行

如何理解持续集成、持续交付、持续部署

我们经常听到持续集成，持续交付，持续部署，它们是什么，联系和区别是什么?让我告诉你我的想法。

是什么

集成指软件作为软件的一部分的部分交付，以尽早发现个体开发部分的问题;

部署是能够尽早交付到运行的开发/测试部分的代码，以便尽早进行测试;

交付是指研究和开发尽快交付给客户，以便尽早发现生产环境中的问题。

如果你一直等到一切都完成了再交付，所有的问题都只能再次出现，而且成本甚至无法解决。而所谓的坚持，也就是说，每一个完整的部分，下一个步骤的交付，问题都可以立即调整。这个问题不会被放大到其他的部分和后期。

三者联系

持续集成，持续交付，持续部署。个人的理解是尽早发现问题并及早发现问题，这比在开发中发现问题的成本要低得多。大多数情况下，最初的需求在开发过程中会有所不同，或者在开发过程中没有足够的需求分析。

三者区别

“持续集成(Continuous Integration)“连续交付(连续交付)”“持续部署”(持续部署)为整个团队提供了良好的企业环境，共同的利益和挑战。在任何情况下，频繁部署、快速交付和开发测试过程自动化将是未来软件工程的重要组成部分。

如何做到持续集成

        首先需要理解持续集成是什么样子的一个概念。我曾经体会过如下图的应用开发测试部署流程，基本每天都在做同样的几件事情： 1、打包，等待maven编译打包 2、发布测试环境，手动重启服务 3、通知测试组测试(邮件、用嘴巴喊等等方式...)  4、一顿grep查Exception，修复BUG，然后重复1、2、3、4 5、到达特殊的日子时，配合运维部署团队到测试环境手动copy最新版WAR包到生产环境，23点的一瞬间执行一个脚本，时刻盯住脚本运行结果，最后验证  我们可以发现很多问题： 编译打包的过程浪费开发资源，一次测试部署正常10到20分钟，那出现问题的情况...  测试长时间怠工，资源利用不充分，处于一人干活多人旁观低绩效状态  研发与测试的沟通方式高成本低效率  BUG反馈方式低效                                                                                           生产环境得不到有效的管控以及安全保障，人工浪费 如果产品或者销售想要给客户演示测试环境，得到的结果可能是测试暂时不可用或者稍微等15到20分钟，是否能计算出他们的心理阴影面积？ DevOps的中心思想在于提高产品各个阶段的产出效率减少或者避开团队间的沟通障碍，推动产品的快速迭代，“快速失败”，从而实现持续交付、持续部署。而持续集成只是DevOps中的一个环节，下图清晰描述了CI各个周期活动。 我们可以发现较多优点：                                                                                                 1、流程全自动化，减少重复性的手工操作                                                                       2、持续发布测试，时刻保持可发布的产品                                                                       3、团队、高层对项目、产品的进展清晰可见，把控风险                                            4、资源效率有效利用，流动效率更快 因此，我们要做到持续集成，我们需要：                                                                        1、一套持续集成工具，大体可分为云集成与本地化集成系统，云集成比如Travis CI、cloudbees的云集成等，本地化集成主要是开源Jenkins的搭建，如果需要大规模部署Jenkins且有预算可使用Jenkins商业版                                                                         2、自动化测试工具、良好的测试用例编写                                                                       3、版本控制系统，git、gerrit推荐                                                                                  4、构建、测试失败反馈机制，邮件、自动化运维(AI...)、日志收集分析系统                 5、一套需求、产品、开发、测试、部署、运维共同使用的敏捷研发管理系统，市场上有阿里云效、腾讯的TAPD等                                                                                             6、...

什么是持续集成

From:王海鹏持续集成不是一项软件开发实践，而是多项软件开发实践的集合。团队在尝试引入这些开发实践时，不可避免要遇到一个问题:?如果不能很好地理解为什么，持续集成可能会进入误区，不能带来期望的效果。 数据集成。数据是所有IT 系统的核心，所有的架构都建立在数据的基础之上，其目的都是为了更好地处理数据。由于数据如此重要，所以我们派专人来负责管理和维护，这就是 DBA。不幸的是，DBA 与程序员似乎来自于不同的文化，他们讲的不是同一种语言。结果常常导致程序员基于自己对数据库的假设来开发程序，到了项目的后期才与真实数据库进行集成。这种假设会带来很大的集成和部署风险，影响代码的品质，可能引起大量的返工。 对于针对已有数据集的开发，持续集成强调尽可能早地与实际数据集成，例如可以通过数据库复制，在一个几乎与生产环境一样的开发环境中进行开发。此外，DBA 可以与开发团队密切配合，双方分享观点与经验，使数据库的组织方式也能够根据新的业务需求与时俱进。关于这一主题，请参考Scott W.Ambler 的《数据库重构》。 如果项目要开发一个全新的应用，还没有数据集存在，怎么办?办法很简单:一、尽早得到真实的数据集。二、随着开发团队对问题域的理解不断加深，应用功能的不断实现，让数据的组织方式也不断优化。 静态代码检查。不同的人写的代码，其品质差异比较大。相同的人在不同时间写的代码，其品质也可以有相当的差异。为此，人们设计了代码评审活动，来提高代码品质。极限编程则通过结对编程的实践，将代码复查工作扩展到开发的每一分钟。这样做代价不菲。当然，根据克劳斯比的观点，以这样的代价换取高品质的产品，总的来说还是值得的。但是人们总是在想，如果能够降低检查的成本，又能够获得检查的好处，岂不美哉? 编码标准就是一个典型的例子。相信每一个严肃的开发机构都不会不提编码标准，但是检查代码是否符合编码标准却是一件耗时耗力的事情，这导致了在许多项目中，编码标准有名无实。自动化的代码检查工具承担了这项繁复的工作。像CheckStyle 这样的工具，能够自动检查代码是否符合编码标准。项目以能够承受的代价，满足了编码标准。程序员也在这种检查中不断提高，养成良好的编码习惯。 静态代码检查还能做更多的事。出于种种原因，我们希望代码能够做到"低耦合，高内聚"。像PMD 这样的代码依赖关系检查工具能帮助我们发现不正当的依赖关系。重复的代码是品质的大敌，PMD 还能找出重复的代码。人们在使用某种编程语言时，会有一些容易犯的错误，像FindBugs 这样的工具能够帮助我们找出这些错误。 静态代码检查不是要完全替代评审活动，但它能够让我们从繁复的低创造性活动中解放出来，专注于创造性的思维和活动。工具的归工具，人的归人。 自动化测试。利用现有的技术，我们可以用能够承担的成本，将许多的测试自动化。这些自动化测试包括单元测试、集成测试、系统测试、验收测试、压力测试等。而通过持续集成来持续进行自动化测试，将带来许多好处。 自动化测试减轻了开发团队的压力，让大家对系统有信心，使工作的气氛变得更轻松。有了自动化测试的保护，开发者也敢于不断对系统进行改进，添加新的特征和改进代码品质。当系统有机会越来越好时，我们才可能创造出了不起的软件。 自动化测试降低了测试和修改的成本。错误越早发现，更正它的成本就越低。自动化测试加速了开发/测试循环，从而使修正错误的成本降低。容易测试的系统就容易增强和维护，难测试的系统就难增强和维护，不可测试的系统基本上可以排除在我们的考虑之外。测试成本低的系统才是开发维护成本低的系统。 自动化测试报告了系统的真实进度。哪些需求已实现?现有的架构和实现是否能满足性能需求?自动化的验收测试和压力测试会告诉我们准确的答案。在许多情况下，我们都有理由让需求可测试，让测试能够自动执行。 自动化部署。系统能否部署到目标生产环境?是否需要进行一些数据迁移和应用升级?配置文件是否正确?理解这些问题的最好方式就是将部署过程自动化。通过向近似于生产环境的目标环境持续部署，确保部署过程没有问题。在自动化部署成功后，再对部署好的系统执行验收测试和压力测试。持续部署可以尽早发现部署过程中的问题，降低系统上线时的风险。 提高项目可见性。项目的进度如何?哪些需求已实现?哪些代码已测试?代码的品质如何?持续集成及时呈现各种分析报告，让开发团队和管理层了解项目的真实状况，从而制定正确的决策。"不识庐山真面目，只缘身在此山中"的感觉一去不复返。一般来说，最成功的人拥有最好的信息。 ?因为持续集成将改善软件的质量，降低风险，使软件开发变得更有效率，让大家能够"愉快工作，幸福生活"，而不是"加班工作，维持生活"。这不是唯一的标准答案，每个团队都可以思考讨论，得到属于自己的答案。关于持续集成的更多内容，请参考《持续集成》一书。

项目打包和自动化部署

在传统的开发模式中，开发的整个过程是按部就班就行。

但是这种模式存在很大的弊端：

DevOps是Development和Operations两个词的结合，将开发和运维结合起来的模式。

伴随着DevOps一起出现的两个词就是持续集成和持续交付(部署)：

持续集成CI：

持续交付和持续部署：

云服务器我们可以有很多的选择：阿里云、腾讯云、华为云。但是在我们的课程中，我选择目前使用更加广泛的阿里云来讲解。

***隐藏网址***

购买云服务器其实是购买一个实例。

Jenkins本身是依赖Java的，所以我们需要先安装Java环境。这里我安装了Java1.8的环境

因为Jenkins本身是没有在dnf的软件仓库包中的，所以我们需要连接Jenkins仓库：

一下文件/etc/yum.repos.d/jenkins.repo

安装Jenkins

启动Jenkins的服务：

Jenkins默认使用8080端口提供服务，所以需要加入到安全组中：

我们后面会访问centos中的某些文件夹，默认Jenkins使用的用户是 jenkins ，可能会没有访问权限，所以我们需要修改一下它的用户：

修改文件的路径： /etc/sysconfig/jenkins

之后需要重启一下Jenkins：

***隐藏网址***

获取输入管理员密码：

可以安装推荐的插件：

新建任务：

配置项目和保留策略：

源码管理：

构建触发器：

这里的触发器规则是这样的：

构建环境：

注意：我们需要搭建Node的环境

第一步：配置Node的环境

第二步：安装Node的插件

构建执行的任务：

后续我们部署会使用nginx，所以需要先安装一下nginx：

启动nginx：

我们这里主要配置nginx的用户和默认访问目录：

配置用户：

通过Linux命令创建文件夹和文件：

配置访问目录：