CI/CD持续集成/持续部署 敏捷开发
敏捷软件开发（英语：Agile software development），又称敏捷开发，是一种从1990年代开始逐渐引起广泛关注的一些新型软件开发方法，是一种应对快速变化的需求的一种软件开发能力。它们的具体名称、理念、过程、术语都不尽相同，相对于“非敏捷”，更强调程序员团队与业务专家之间的紧密协作、面对面的沟通（认为比书面的文档更有效）、频繁交付新的软件版本、紧凑而自我组织型的团队、能够很好地适应需求变化的代码编写和团队组织方法，也更注重软件开发过程中人的作用。
1，CI/CD持续集成/持续部署
持续集成(Continuous integration,CI)是一种软件开发实践，即团队开发成员经常集成它们的工作，通过每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。持续集成是为了持续交付。 没有单元测试的持续集成基本无意义。
持续部署（continuous deployment,CD）是通过自动化的构建、测试和部署循环来快速交付高质量的产品。某种程度上代表了一个开发团队工程化的程度，毕竟快速运转的互联网公司人力成本会高于机器，投资机器优化开发流程化相对也提高了人的效率，让 engineering productivity 最大化。
在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境中。比如，我们完成单元测试后，可以把代码部署到测试环境中，交付给质量团队或者用户，以供评审。如果评审通过， 代码就进入生产阶段。
常规的测试过程：开发送测一个版本——>测试人员从配置库下载版本——>编译版本——>部署到测试环境——>进行冒烟测试——>进行功能测试。 而这些过程完全可以由CI/CD来替代。
持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
2、Devops理解
DevOps是一个完整的面向IT运维的工作流，以IT自动化以及CI、CD为基础，来优化程序开发、测试、系统运维等所有环节。
DevOps实际是一种文化上的变迁，代表了开发、运维、测试等环节之间的协作，因此DevOps工具是非常多种多样的，甚至可以由多种工具组成一个完整的DevOps工具链。此类工具可以应用于一种或多种类别，并可体现出软 件开发和交付过程的不同阶段：
①编码：代码开发和审阅，版本控制工具、代码合并工具
②构建：持续集成工具、构建状态统计工具
③测试：通过测试和结果确定绩效的工具
④打包：成品仓库、应用程序部署前暂存
⑤发布：变更管理、发布审批、发布自动化
⑥配置：基础架构配置和部署，基础架构即代码工具
⑦监视：应用程序性能监视、最终用户体验
与DevOps的关系
持续交付与DevOps的含义很相似，所以经常被混淆。但是它们是不同的两个概念。DevOps的范围更广，它以文化变迁为中心，特别是软件交付过程所涉及的多个团队之间的合作（开发、运维、QA、管理部门等），并且将软件交付的过程自动化。另壹方面，持续交付是壹种自动化交付的手段，关注点在于将不同的过程集中起来，并且更快、更频繁地执行这些过程。因此，DevOps可以是持续交付的壹个产物，持续交付直接汇入DevOps；
与持续部署的关系
有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。如果要实施持续部署，必须先实施持续交付。
3、相关工具
1、Jenkins是什么？
Jenkins是一个可扩展的持续集成引擎。
主要用用途：
持续、自动的构建/测试软件项目。
监控一些定时执行的任务。、
特点：
易于安装，只要把jenkins.war部署到servlet容器
易于配置-所有配置都通过其提供的web界面实现。
集成RSS/E-mail通过RSS发布构建结果或当构件完成是通过e-mail通知。
生成JUnit/TestNG测试报告。
分布式构建支持Jenkins能够让多台计算机一起构建/测试。
文件识别：Jenkins能够跟踪那次构建生成哪些jar，那次构建使用哪个版本的jar
插入支持：支持扩展插件，可以开发适合自己团队的使用的工具。
Jenkins的目标是监控软件的开发流程，快速显示问题。所以能保证开发人员省事又省力提高开发效率。
2、项目版本迭代控制:、
现有的版本控制工具，如 Github、GitLab、SVN、CVS 等主流工具..
构建及测试:通过 Jenkins 实现自动构建和测试,还有商业软件BAMBOO来持续集成。这个收费的。免费就用Jenkins..
交付:以Docker镜像形式进行交付，提交至镜像仓库；
2.1 SVN服务器：
Subversion是一个版本控制系统，相对于的RCS、CVS，采用了分支管理系统，它的设计目标就是取代CVS。互联网上免费的版本控制服务多基于Subversion。
Subversion的版本库可以通过网络访问，从而使用户可以在不同的电脑上进行操作。从某种程度上来说，允许用户在各自的空间里修改和管理同一组数据可以促进团队协作。因为修改不再是单线进行（单线进行也就是必须一个一个进行），开发进度会进展迅速。此外，由于所有的工作都已版本化，也就不必担心由于错误的更改而影响软件质量—如果出现不正确的更改，只要撤销那一次更改操作即可。某些版本控制系统本身也是软件配置管理系统（SCM），这种系统经过精巧的设计，专门用来管理源代码树，并且具备许多与软件开发有关的特性——比如对编程语言的支持或者提供程序构建工具。不过Subversion并不是这样的系统，它是一个通用系统，可以管理任何类型的文件集。
2.2 CVS服务器：
CVS（Concurrent Versions System）版本控制系统是一种GNU软件包，主要用于在多人开发环境下源码的维护。Concurrent有并发的、协作的、一致的等含义。实际上CVS可以维护任意文档的开发和使用，例如共享文件的编辑修改，而不仅仅局限于程序设计。CVS维护的文件类型可以是文本类型也可以是二进制类型。CVS用Copy-Modify-Merge（拷贝、修改、合并）变化表支持对文件的同时访问和修改。它明确地将源文件的存储和用户的工作空间独立开来，并使其并行操作。CVS基于客户端/服务器的行为使其可容纳多个用户。这一特性使得CVS成为位于不同地点的人同时处理数据文件（特别是程序的源代码）时的首选。
所有重要的免费软件项目都使用CVS作为其程序员之间的中心点，以便能够综合各程序员的改进和更改。这些项目包括GNOME、KDE、THE GIMP和Wine等。
2.3 GIt/github：
GIT （分布式版本控制系统）
Git是一款免费、开源的分布式版本控制系统，用于敏捷高效地处理任何或小或大的项目。Git的读音为/gɪt/。
Git是一个开源的分布式版本控制系统，可以有效、高速的处理从很小到非常大的项目版本管理。Git 是 Linus Torvalds 为了帮助管理 Linux 内核开发而开发的一个开放源码的版本控制软件。Torvalds 开始着手开发 Git 是为了作为一种过渡方案来替代 BitKeeper，后者之前一直是 Linux 内核开发人员在全球使用的主要源代码工具。开放源码社区中的有些人觉得BitKeeper 的许可证并不适合开放源码社区的工作，因此 Torvalds 决定着手研究许可证更为灵活的版本控制系统。尽管最初 Git 的开发是为了辅助 Linux 内核开发的过程，但是我们已经发现在很多其他自由软件项目中也使用了 Git。例如 很多 Freedesktop 的项目迁移到了 Git 上。
gitHub是一个面向开源及私有软件项目的托管平台，因为只支持git 作为唯一的版本库格式进行托管，故名gitHub。
gitHub于2008年4月10日正式上线，除了git代码仓库托管及基本的 Web管理界面以外，还提供了订阅、讨论组、文本渲染、在线文件编辑器、协作图谱（报表）、代码片段分享（Gist）等功能。目前，其注册用户已经超过350万，托管版本数量也是非常之多，其中不乏知名开源项目 Ruby on Rails、jQuery、python 等。
一个简易CICD持续集成、持续部署的流程
由客户端将代码push推送到git仓库，gitlab上配置了一个webHook的东西可以触发Jenkins的构建。进入到Jenkins虚线范围内，它所做的事情非常多，从mvn构建代码，对代码进行静态分析，做单元测试，测试通过之后就可以build镜像，镜像构建成功后就把镜像push推送到Harbor镜像仓库中，镜像push推送到镜像仓库后，我们就可以调用kubernetes集群的restAPI更新服务，而后kubernetes接收到了更新的指令，从Harbor镜像仓库pull拉取镜像，从而完成服务的更新与重启，最后我们从客户端来访问kubernetes集群的服务
(转)持续集成与灰度发布
一、持续集成
持续集成（Continuous integration，简称CI）是一种软件开发实践，即团队开发成员经常集成它们的工作，通常每个成员每天至少集成一次，也就意味着每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试)来验证，从而尽快地发现集成错误。许多团队发现这个过程可以大大减少集成的问题，让团队能够更快的开发内聚的软件。
持续集成的目的与价值：
持续集成的目的不是减少build失败的次数，而是尽早发现问题，在最短的时间内解决问题，减少风险和浪费。从而让产品开发流程更加敏捷，缩短产品开发周期，在产品上线后，让用户用得更加顺畅。
在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，每个开发人员分别负责一个模块，等所有的代码都开发完成之后再集成到一起提交给测试人员，随着软件技术队的发展，软件已经不能简单地通过划分模块的方式来开发，需要项目内部相互协作，划分模块这种传统的模式的弊端也越来越明显。由于很多bug在项目早期的设计、编码阶段就引入，到最后集成测试时才发现问题，开发人员需要花费大量的时间来定位bug，加上软件的复杂性，bug的定位就更难了，甚至出现不得不调整底层架构的情况。这种情况的发生不仅仅对测试进度造成影响，而且会拖长整个项目周期。
而持续集成可以有效解决软件开发过程中的许多问题，在集成测试阶段之前就帮助开发人员发现问题，从而可以有效的确保软件质量，减小项目的风险，使软件开发团队从容的面对各种变化。持续集成报告中可以体现目前项目进度，哪部分需要已经实现，哪些代码已经通过自动化测试，代码质量如何，让开发团队和项目组了解项目的真实状况。
持续集成的优点：
1、快速发现错误。每完成一点更新，就集成到主干，可以快速发现错误，定位错误也比较容易。
2、防止分支大幅偏离主干。如果不是经常集成，主干又在不断更新，会导致以后集成的难度变大，甚至难以集成。
持续集成的一些原则：
1.所有的开发人员需要在本地机器上做本地构建，然后再提交的版本控制库中，从而确保他们的变更不会导致持续集成失败。
2.开发人员每天至少向版本控制库中提交一次代码。
3.开发人员每天至少需要从版本控制库中更新一次代码到本地机器。
4.需要有专门的集成服务器来执行集成构建,每天要执行多次构建。
5.每次构建都要100%通过。
6.每次构建都可以生成可发布的产品。
7.修复失败的构建是优先级最高的事情。
二、灰度发布
互联网产品的发布大多都是做到这里就直接上线，替换了原有的版本，这种跳跃式的发布是非常危险的，如果产品影响面大，对项目成员的压力是非常大的。灰度发布是在发布新版本的时候，先切分部分流量给新版本，稳定了之后再切分所有流量到新版本。这样一旦有问题，马上修改切分的流量就可以，不需要重新发布，减少了发布风险。这种基于ABTest分流的灰度发布方式已经成为很多公司发布的一个必经流程。在灰度发布过程中，产品团队根据用户的反馈及时完善产品相关功能。目前业界一些著名的互联网公司（如google，百度）都是采用这种类似灰度发布的方式。AB Test系统就是可以实现灰度发布的系统。通过ABTest系统可以方便地以各种方式切换流量。
在敏捷开发领域，取消专职测试以后，灰度发布就更加重要。一旦新版本出现问题，能够通过我们的ABTest系统马上将所有流量切回稳定的旧版本。这样做的好处是：
1、即时生效，无需发布，快速响应。
2、可以渐进地调整比例。
3、分流的维度丰富多样。
