持续集成持续交付（CICD）
概念
CI/CD 是⼀种通过在应⽤开发阶段引⼊⾃动化来频繁向客户交付应⽤的⽅法。CI/CD 的核⼼概念是持续集成、持续交付和持续部署。作为⼀个⾯向开发和运营团队的解决⽅案，CI/CD 主要针对在集成新代码时所引发的问题。
具体⽽⾔，CI/CD 可让持续⾃动化和持续监控贯穿于应⽤的整个⽣命周期（从集成和测试阶段，到交付和部署）。这些关联的事务通常被统称为“CI/CD 管道”，由开发和运维团队以敏捷⽅式协同⽀持。
持续集成（CI：Continuous Integration）
CI/CD 中的“CI”始终指持续集成，它属于开发⼈员的⾃动化流程。成功的 CI 意味着应⽤代码的新更改会定期构建、测试并合并到共享存储库中。该解决⽅案可以解决在⼀次开发中有太多应⽤分⽀，从⽽导致相互冲突的问题。
持续集成（CI）可以帮助开发⼈员更加频繁地（有时甚⾄每天）将代码更改合并到共享分⽀或“主⼲”中。⼀旦开发⼈员对应⽤所做的更改被合并，系统就会通过⾃动构建应⽤并运⾏不同级别的⾃动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应⽤造成破坏。这意味着测试
内容涵盖了从类和函数到构成整个应⽤的不同模块。如果⾃动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
持续交付（CD：Continuous Delivery）
CI/CD 中的“CD”指的是持续交付和/或持续部署，这些相关概念有时会交叉使⽤。两者都事关管道后续阶段的⾃动化，但它们有时也会单独使⽤，⽤于说明⾃动化程度。
持续交付通常是指开发⼈员对应⽤的更改会⾃动进⾏错误测试并上传到存储库，然后由运维团队将其部署到实时⽣产环境中。旨在解决开发和运维团队之间可见性及沟通较差的问题。因此，持续交付的⽬的就是确保尽可能减少部署新代码时所需的⼯作量。
持续部署（另⼀种“CD”）指的是⾃动将开发⼈员的更改从存储库发布到⽣产环境，以供客户使⽤。它主要为了解决因⼿动流程降低应⽤交付速度，从⽽使运维团队超负荷的问题。持续部署以持续交付的优势为根基，实现了管道后续阶段的⾃动化。
产⽣与发展
软件⼯程⽅法编年史
软件⼯程发展概述
瀑布软件开发⽅式
特点：简单，分阶段，阶段间存在因果关系，各个阶段完成后都有评审，允许反馈，不⽀持⽤户参与，要求预先确定需求。
适⽤于需求易于完善定义且不易变更的软件系统
敏捷软件开发⽅式
特点：作为整体⼯作；短迭代周期；每次迭代交付⼀些成果；关注业务优先级；检查与调整。
理念：个⼈与交互重于开发过程与⼯具；可⽤的软件重于复杂的⽂档；寻求客户的合作重于对合同的谈判；对变化响应重于始终遵循固定的计划。
Devops运动
特点：倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进⾏全⾯的⾃动化和监控的IT组织管理的发展趋势。优势与劣势：解放开发、运维⽣产⼒（技术要求⾼）；促进组织结构松散化（边界模糊，⽆法专注）；使运维更贴近业务（⽴场不同，⽆法达成决策）；应对变更能⼒强，快速迭代（管理死⾓，规模扩展性不好）
理念：⼀切皆代码，⾃动化⼀切，部署流⽔线尽早反馈。
云原⽣
软件的影响⼒正在⽇益凸显，它不但会影响⽤户与企业间的互动⽅式，还会影响企业为保持市场竞争⼒⽽做出的创新之举。因此，应⽤的快速开发和交付已成为数字化企业必须要满⾜的⼀项新需求。
为了满⾜这⼀需求，企业必须采⽤云原⽣⽅法来开发应⽤，以提⾼速度、增加灵活性、改善质量并降低风险。
** 云原⽣内容依赖关系
⾸先，为了抓住商业机会，业务需要快速迭代，不断试错，因此，企业需要依赖拥有持续交付的能⼒，这些不仅包括技术需求还包括产品的需求，如何能拥有持续交付的能⼒，⼤⽽全的架构因为效率低下，显然是不合适的。于是演变出微服务架构来满⾜需求，通过把系统划分出⼀个个独⽴的个体，每个个体服务的设计依赖需要通过12要素的原则来规范完成。同样，如果系统被分成了⼏⼗个甚⾄⼏百个服务组件，则需要借助DevOps才能很好地满⾜业务协作和发布等流程。最后，DevOps的有效实施需要依赖⼀定的⼟壤，即敏捷的基础设施服务，现实只有云计算的模式才能满⾜整体要求。通过上述梳理，我们总结出⾯向云原⽣应⽤的3个不同层次的特点。
⾼可⽤设计（Design for Availability），依据应⽤业务需求，⾼可⽤分为不同级别，⽐如不同区域、不同机房（跨城或同城）、不同机柜、不同服务器和不同进程的⾼可⽤，云原⽣应⽤应该根据业务的可⽤性要求设计不同级别的架构⽀持。
可扩展设计（Design for Scale），所有应⽤的设计是⽆状态的，使得业务天⽣具有扩展性，在业务流量⾼峰和低峰时期，依赖云的特性⾃动弹性扩容，满⾜业务需求。
快速失败设计（Design for Failure），即包括系统间依赖的调⽤随时可能会失败，也包括硬件基础设施服务随时可能宕机，还有后端有状态服务的系统能⼒可能有瓶颈，总之在发⽣异常时能够快速失败，然后快速恢复，以保证业务永远在线，不能让业务半死不活地僵持着。** 微服务结构之12要素
特点：通过强化详细配置和规范，基于“约定优于配置”（convention over configuration）的原则，特别在⼤规模的软件⽣产实践中，这些约定⾮常重要，从⽆状态共享到⽔平扩展的过程，从松耦合架构关系到部署环境。基于12要素的上下⽂关联，软件⽣产就变成了⼀个个单⼀的部署单元；多个联合部署的单元组成⼀个应⽤，多个应⽤之间的关系就可以组成⼀个复杂的分布式系统应⽤。
参考：
** 实现云原⽣成功的实践步骤
1.采⽤充分利⽤ DevOps 所需的技术和协作流程
2.借助经过优化的单体式应⽤，提⾼现有应⽤的运⾏速度
3.构建可按需提供的⾃助式基础架构
4.实现 IT ⾃动化，加速交付应⽤
5.实施持续交付和⾼级部署技术
6.推动变⾰，采⽤模块化程度更⾼的架构
流程与⽅法论
开发流程
持续集成和部署主要参与者
源代码库：负责存储源代码，常⽤的有Git和SVN
持续集成与部署⼯具：负责⾃动编译和打包以及把可运⾏程序存储到可运⾏库。⽐较流⾏的有Jenkins，GitLab，Travis CI，CircleCI 等.
库管理器(Repository Manager)：也就是图中的Repository，我们⼜叫运⾏库，负责管理程序组件。最常⽤的是Nexus。它是⼀个私有库，它的作⽤是管理程序组件。
持续集成系统的组成:
1.⼀个代码存储库，即需要版本控制软件来保障代码的可维护性，同时作为构建过程的素材库.
2.⼀个⾃动构建过程，包括⾃动编译、分发、部署和测试等
3.⼀个持续集成服务器，负责⾃动编译和打包以及把可运⾏程序存储到可运⾏库.
持续部署步骤：
1.下载源码：从源代码库中下载源代码(Gitlab)
2.编译代码：编译语⾔都需要有这⼀步
3.测试：对程序进⾏测试
4.⽣成镜像：这⾥包含两个步骤，⼀个是创建镜像，另⼀个是存储镜像到镜像库(Docker hub)
5.部署镜像：把⽣成的镜像部署到k8s
⼯具链
Gitlab
开源的版本管理系统，实现⼀个⾃托管的Git项⽬仓库，可通过Web界⾯进⾏访问公开的或者私⼈项⽬。
与Github类似，能够浏览源代码，管理缺陷和注释。可以管理团队对仓库的访问，易于浏览提交过的版本并提供⼀个⽂件历史库。成员可以利⽤内置的简单聊天程序(Wall)进⾏交流。它还提供⼀个代码⽚
段收集功能可以轻松实现代码复⽤，便于⽇后有需要的时候进⾏查。
Nexus
管理第三⽅库：第三⽅公共库管理不⽅便，建⽴⼀个私有管理库，来集中统⼀管理各种第三⽅软件。例如它既可以做为Maven库
（Java），也可以做为镜像库（Docker），还可以做为NPM库（JavaScript），来保证公司软件的规范性。
管理内部程序的交付：所有公司在各种环境（例如DEV，QA，UAT， PROD）发布的程序都由它来管理，并赋予统⼀的版本号，这样任何交付都有据可查，便利于程序回滚
Jenkins
Jenkins是⼀款开源 CI&CD 软件，⽤于⾃动化各种任务，包括构建、测试和部署软件。使开发者从繁杂的集成中解脱出来，专注于更为重要的业务逻辑实现上
java语⾔开发，⽤于监控持续重复的⼯作，包括：持续的软件版本发布/测试项⽬，监控外部调⽤执⾏的⼯作。
Jenkins ⽀持各种运⾏⽅式，可通过系统包、Docker 或者通过⼀个独⽴的 Java 程序。
流⽔线：流⽔线是⽤户定义的⼀个CD流⽔线模型。流⽔线的代码定义了整个的构建过程, 他通常包括构建, 测试和交付应⽤程序的阶段。
另外， pipeline 块是声明式流⽔线语法的关键部分.Jenkins 流⽔线是⼀套插件，它⽀持实现和集成 continuous delivery pipelines 到Jenkins。对Jenkins 流⽔线的定义被写在⼀个⽂本⽂件中 (称为 Jenkinsfile)，该⽂件可以被提交到项⽬的源代码的控制仓库，这是"流⽔线即代码"的基础; 将CD 流⽔线作为应⽤程序的⼀部分，像其他代码⼀样进⾏版本化和审查。
Blue Ocean:Blue Ocean 重新思考Jenkins的⽤户体验，从头开始设计Jenkins Pipeline, 但仍然与⾃由式作业兼容，Blue Ocean减少了混乱⽽且进⼀步明确了团队中每个成员 Blue Ocean 的主要特性包括：持续交付(CD)Pipeline的复杂可视化;Pipeline 编辑器；个性化；在需要⼲预和/或出现问题时精确定位；本地集成分⽀和合并请求.
Docker
软件开发最⼤的⿇烦事之⼀就是环境配置，操作系统的设置、各种库和组件的安装带来的兼容性，复杂性，重复性给项⽬实施带来了巨⼤的消耗。虚拟机就是⼀种带环境安装的解决⽅案，但资源占⽤多，冗余步骤多，启动慢。这样就诞⽣了Linux容器技术（由 Linux
Namespace、Linux Cgroups 和 rootfs 三种技术构建出来的进程的隔离环境），由于容器是进程级别的，具有启动快，资源占⽤少，体积⼩的优势，类似于轻量级的虚拟机，能够提供虚拟化的环境，成本开销⼩很多。Docker属于Linux容器的⼀种封装，提供简单易⽤的容器使⽤接⼝，是⽬前最流⾏的Linux容器解决⽅案。
持续集成的概念Docker 项⽬通过“容器镜像”，解决了应⽤打包这个根本性难题。这种机制直接打包了应⽤运⾏所需要的整个操作系统，从⽽保证了本地环境和云端环境的⾼度⼀致，避免了⽤户通过“试错”来匹配两种不同运⾏环境之间差异的痛苦过程.
发展现状
容器技术圈⼦在短短⼏年⾥发⽣了很多变数，但很多事情其实也都在情理之中。就像 Docker 这样⼀家创业公司，在通过开源社区的运作取得了巨⼤的成功之后，就不得不⾯对来⾃整个云计算产业的竞争和围剿。⽽这个产业的垄断特性，对于 Docker 这样的技术型创业公司其实天⽣就不友好。
在这种局势下，接受微软的天价收购，在⼤多数⼈看来都是⼀个⾮常明智和实际的选择。可是 Solomon Hykes 却多少带有⼀些理想主义的影⼦，既然不⽢于“寄⼈篱下”，那他就必须带领 Docker 公司去对抗来⾃整个云计算产业的压⼒。只不过，Docker 公司最后选择的对抗⽅式，是将开源项⽬与商业产品紧密绑定，打造了⼀个极端封闭的技术⽣态。⽽这，其实违背了 Docker 项⽬与开发者保持亲
密关系的初衷。
相⽐之下，Kubernetes 社区，正是以⼀种更加温和的⽅式，承接了 Docker 项⽬的未尽事业，即：以开发者为核⼼，构建⼀个相对民主和开放的容器⽣态。
参考：
Kubernetes
过去很多的集管理项⽬（⽐如 Yarn、Mesos，以及 Swarm）所擅长的，都是把⼀个容器，按照某种规则，放置在某个最佳节点上运⾏起来。这种功能，我们称为“调度”。⽽ Kubernetes 项⽬所擅长的，是按照⽤户的意愿和整个系统的规则，完全⾃动化地处理好容器之间的各种关系。这种功能，就是我们经常听到的⼀个概念：编排。所以说，Kubernetes 项⽬的本质，是为⽤户提供⼀个具有普遍意义的容器编排⼯具。不过，更重要的是，Kubernetes 项⽬为⽤户提供的不仅限于⼀个⼯具。它真正的价值，乃在于提供了⼀套基于容器构建分布式系统的基础依赖。
Kubernetes 项⽬就没有像同时期的各种“容器云”项⽬那样，把 Docker 作为整个架构的核⼼，⽽仅仅把它作为最底层的⼀个容器运⾏时实现。
Kubernetes 项⽬最主要的设计思想是，从更宏观的⾓度，以统⼀的⽅式来定义任务之间的各种关系，
并且为将来⽀持更多种类的关系留有余地
Kubernetes 项⽬从⼀开始就⽐较幸运地站上了⼀个他⼈难以企及的⾼度：在它的成长阶段，这个项⽬每⼀个核⼼特性的提出，⼏乎都脱胎于 Google Borg/Omega 系统的设计与经验。更重要的是，这些特性在开源社区落地的过程中，⼜在整个社区的合⼒之下得到了极⼤的改进，修复了很多当年遗留在 Borg 体系中的缺陷和问题。
所以，尽管在发布之初被批评是“曲⾼和寡”，但是在逐渐觉察到 Docker 技术栈的“稚嫩”和 Mesos 社区的“⽼迈”之后，这个社区很快就明⽩了：Kubernetes 项⽬在 Borg 体系的指导下，体现出了⼀种独有的“先进性”与“完备性”，⽽这些特质才是⼀个基础设施领域开源项⽬赖以⽣存的核⼼价值。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。