DevOps软件架构师行动指南-读书笔记整理

IT大咖说

发布于 2021-04-25 11:13:28

5740

发布于 2021-04-25 11:13:28

文章被收录于专栏：IT大咖说

对于《DevOps软件架构师行动指南》这本书，整体偏大框架的介绍，但是仍然还是有一定的阅读价值，至少对DevOps架构方法论和关键技术有一个全面的了解和认知。

DevOps是什么？

书里面给出定义为，DevOps是一套实践方法，在保证高质量的前提下缩短系统变更从提交到部署至生产环境的时间。实际上看了这个定义你也很难对DevOps有一个全面的了解。因此也可以定义为，DevOps是在保证质量的前提下，提供的一整套从开发，测试到生产运维的持续交付和管控方法论。在整个过程中需要实现自动化，可视化，流水线式作用，同时将质量管控无缝嵌入其中。

网上可以找到的另外一个DevOps的定义如下：

DevOps（英文Development和Operations的组合）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它的出现是由于软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发和运营工作必须紧密合作。

所以要真正理解DevOps其一是要认识到是Dev和Ops两个部分的组合，其次是实际开发，运维和QA三者之间的协同和交互问题。而对于自动化，持续集成等仅仅是解决上面这个问题采用的工具和手段。

DevOps拓展了原有的持续集成方法论，其一是增加了组件化和微服务架构的内容，其二是在PaaS变成容器云平台后，增加了和PaaS平台对接和持续交付内容。

对于持续集成和持续交付两者区别，个人强调如下：

持续集成面向的是开发团队，交付面向的是用户
持续集成涉及到编译，构建，打包，部署一系列动作，但是交付可能仅仅涉及环境迁移

DevOps强调的持续集成和交付，不仅在新系统的全新开发过程，其更加重要价值在于老系统在后续变更中的持续交付和集成能力。也就是常说的实现了开发，运维和质量管控的一体化作业。也就是我们经常说的，打开了开发和运维之间的鸿沟，真正实现了开发，运维的一体化作业。

DevOps提倡将运维人员作为首要的干系人，并在需求阶段一开始就介入。

什么意思？

简单来说就是一个应用系统的开发，在从前期需求，设计阶段来说就应该确保应用本身是可运维，可监控的，而不是应用上线后才发现不可运维和管理。

运维人员后期运维难的一个重要原因就是前面所有开发和测试过程对他们都是黑盒，对于这种部署在软硬件环境里的黑盒系统，在出现故障时候他们也很难第一时间查找到真正的原因并快速解决。

DevOps和敏捷

对于DevOps研发过程一体化推进过程中，往往都会和敏捷方法论融合，特别是当前主流的Scrum敏捷方法论。而敏捷方法论核心仍然是需求条目化，短周期迭代，可视化这几个关键点的实践。而其中的敏捷和短周期迭代本身就是和DevOps核心思路和价值观一致。

在协同上面要注意到，DevOps有两个重点：其一是开发，QA+测试，运维三大角色之间的协同；其二是软件打包版本在开发，测试，生产多个环境间的自动化部署和迁移。

人们从不同的视角定义DevOps，例如运维人员采用敏捷实践，开发人员承担运维责任，以及其它一些视角的定义。但共同目标都是缩短一个功能或改进点从业务思路构想到最终部署给用户的时间。

云即平台

在DevOps有一个重点就是应用托管和自动部署，在自动部署的过程中才是需要动态的创建虚拟机和分配资源。因此和DevOps真正配合协同的是PaaS平台层能力，而不是IaaS平台。同时我们可以看到，DevOps实践过程中更多的是和更加轻量化的Docker容器协同，而Docker容器管理的基础单位是镜像。

在和PaaS协同时候，对于底层软硬件设施的基础架构和可见性进一步对开发人员屏蔽。

对于虚拟机故障的恢复，一个重点就是状态的保持和迁移，对于分布式架构师要做的主要决策之一就是如何在应用的不同部分划分状态。对于无状态组件最容易快速恢复和迁移，对于客户端Session状态由于数据量很小，也方便处理，而对于不同数据量状态处理方法：

1. 少量的持久状态：需要在多个会话间维护，可以保持在文件系统中，采用ZooKeeper或Memcached
2. 中等量状态：采用Memcached保存，并提供持久化存储机制
3. 大量的持久状态：保持在结构化数据库，或者Hadoop分布式文件系统中

环境是执行软件系统的一组计算资源，包括了所有支持软件，数据集，网络通信，以及执行软件系统所需要定义的外部实体。

对于环境，我们常会分为开发，测试，UAT，生产等多个环境，但是这并不是云平台特有的属性。简单的创建和快速迁移环境的能力才是云平台特有的能力。而这正是DevOps里面实现持续集成和交付的关键。

将生产轻松地从一个环境切换到另一个环境的结果就是使业务连续性的实现变得更加容易。业务连续性意味着当主数据中心发生灾难的时候业务能够继续运作。

第2章整体写得相当弱，特别是对于DevOps为何需要和云结合，维护需要PaaS平台能力没说透彻。对于这部分内容可以参考我前面的一篇文章说明：

DevOps最佳实践-处理好敏捷研发，持续集成和容器云三者集成

运维

运维整体架构可以参考ITIL标准体系。运维服务包括供给硬件，提供软件，或者支持不同的IT功能。由运维提供的服务还包括了SLA服务等级水平协议的规格说明，软硬件环境状态监控，容量规划，事件管理，故障和问题跟踪处理，日常环境检查，环境和数据备份，业务连续性和信息安全等。

容量规划实际上仍然需要业务部门或IT项目提供具体的容量需求，运维部门在整体进行容量测算和规划，以在满足业务系统性能需求的前提下保证最高的资源利用率。

比如一个业务系统在进行前期方案设计的时候就要做好业务模型测算，做好应用容量规划工作，对于业务模型测算可以参考：

IT方案硬件资源预估-从TPCC规范到业务能力测算模型

软硬件的性能和状态监控是实施了云平台后运维人员工作的一个重大改变，即底层资源已经被云平台接管，运维人员日常监控不再是传统方式登陆到物理服务器或虚拟机后台，因为这些资源本身也可能是动态在变化。在这种情况下运维更加需要借助云平台提供的性能监控分析和日志查看工具来辅助完成运维监控工作。

DevOps不仅仅是考虑软件变更在交付过程中的自动化，也需要考虑后续运维过程的自动化。所以对于运维这块的自动化和智能化专门发展了AIOps分支。

AIOps首先要解决自动化运维，其次才是解决智能化运维，对于智能化运维本身也包括了基于已有规则的智能化处理，和基于运维数据日志分析后的自动化规则生成和处理。

对于AIOps可以参考我前面输出的这篇文章。

谈AIOps基础-从自动化运维到智能化运维

IT服务治理

单独的一个内容，需要提供什么样的服务，安全要求如何，合规要求如何？SLA服务级别如何定义？日常的变更，发布，问题，事件管理流程是如何的？业务连续性如何保证？高可用性如何保证？这些都需要在IT服务和治理管控框架中进行定义。

对于服务设计需遵循标准化，松耦合，抽象，可复用，自治，无状态，可发现，可组装等标准原则。

在应用成功部署上线和交付后就涉及到服务移交，服务移交是开发角色和运维角色之间的一个重要衔接点，如何移交，具体究竟应该移交哪些内容？

一个简单的原则就是：

最终移交的内容和文档，能够确保运维人员后续的日常运维和管控要求。服务移交一定不是移交一个全黑盒的软件部署包，否则后续运维人员很难真正进行运维。

监控是运维过程中最重要的核心，因为它收集事件，检测事故和度量以判断是否符合服务等级协议。它提供服务改善的基础。服务等级协议也可以定义和监控运维活动，例如事故发生后的响应时间。监控的结果由开发或运维团队来进行分析并采取行动。

监控可以和其他控制结合在一起，例如对云资源的自动伸缩控制。

由IT服务和日常运维来反向推动持续服务改进：这个实际可以单独写一篇文章来谈，持续服务改进的主要焦点是在IT服务和业务需求之间达成一致。

ITIL提出的持续改进关键步骤包括了提出目标-》定义度量和KPI-》采集数据-》分析数据-》改进方案和计划-》执行改进-》观察和分析结果。

同传统发布不同，DevOps发布属于高频率的小规模发布，可以将DevOps发布视为更小规模的并发流。一种审视DevOps和ITIL之间关系的方法是，DevOps对各种ITIL服务提供持续交付，而不是将这些服务打包进主要发布版本。（如何理解？）

书里面这部分内容仍然没有将DevOps和传统运维过程的交叉点讲太明白。

微服务架构和DevOps

实施DevOps往往需求架构调整，其关键原因就是尽量减少每次部署动作对整体应用的影响，同时匹配前面谈到的持续高频，小规模发布的需求。而这种调整的关键就是微服务架构。对于微服务架构我前面很多文章都已经谈到过了，但这本书这部分仍然没有讲透。

微服务架构对于部署流水线作业带来的好处可以总结为：

1. 团队可以按微服务模块单独划分，减少团队之间的耦合和交叉影响
2. 多个微服务模块组件松耦合，完全可以独立自治管理，对于变更发布仅需要发布最小组件单位，降低风险
3. 微服务模块更加容易部署到轻量Docker容器，实现快速的自动化部署和集成

微服务架构本质仍然是组件化架构+接口服务化，可以看到这种松耦合架构，再加上单个可以独立管理和部署的组件更加轻量，方便我们更加容器去实施自动化部署和持续集成。也方便软件和服务部署时的最小化原则。

在传统的单体架构转变为微服务架构后，你管理的模块数，管理的接口集成点数都呈现指数级别的增加，如果你还是采用人工去处理编译，构建，集成和部署问题，那么将极大的耗费人力工作量投入。

也就是说微服务转型本身也推动了通过DevOps的自动化流水线来实现持续集成和持续交付。但是微服务化本身是技术层面的词汇，而对于最终业务用户来说仍然看到的是一个完整的应用系统。因此这里就存在应用系统-》微服务模块的两层结构。

这也是我多次提到的DevOps流水线必须支持父子多级流水线的原因。在微服务化后，整个整个DevOps和部署流水线过程的管理难度，即我所有的管理对象，配置和版本控制对象都必须到组件级别，同时还需要进一步管理好组件间的集成和依赖关系。

构建和测试

从代码提交到版本控制系统开始，整个部署流水线的工作就启动。

部署流水线工作一个重点就是持续集成，对于持续集成我在前面博客有文章专门谈到过了，书里面介绍了定义持续集成的一种方法是在一个阶段和下一个阶段之间有一个自动触发器，直到集成测试。持续集成需要完成代码构建打包，部署，单元测试，环境迁移，集成测试，部署等一系列动作。

编译和构建

对于编译和构建两个词有时候在混用，实际两者有区别，参考网上的一段描述如下：

编译：把当前源代码编译成二进制目标文件
构建：先把工程中所有源代码编译成目标文件，再link链接成可执行文件（或者lib、dll，看具体工程）。这其中，如果有源文件在此之前知被单独编译过，这个文件就不参加编译，它之前编译时产生的目标文件参加link（链接）过程。

构建和打包

传统的打包往往仅仅指将编译构建完成的文件达成一个大的EAR或WAR部署包的过程，即多个编译完成文件达成一个大包。在采用容器云进行部署的时候，打包过程还包括镜像文件制作过程，即基于镜像模板来生成一个包含了部署文件的镜像文件。

在部署流水线中移动系统要关注两个方面的内容，其一是可追溯性，可追溯意味着对于生产中的任何系统，可以准确的确定它如何进入生产环境。这意味着不仅要跟踪源代码，还需要跟踪所有工具命令。其二在移动过程中需要关注各个环境之间的差异，以确保在环境迁移过程中能够自动化地配置和设置各种环境变量信息。

Jenkins，Github，Ant，Maven，JUnit等都是我们可以采用的持续集成和管理工具。

构建的目的是创建适合于部署的东西，有多种把系统元素打包并用于部署的标准方法，其中包括了打包为WAR部署包，制作虚拟机镜像或者制作类似Docker容器镜像等。

我们看到在DevOps和Docker集成的时候，实际在第一次部署前首先是制作Docker容器镜像，然后对整个容器镜像文件进行部署，同时在后续环境迁移过程中迁移的基本单位也是该容器镜像文件。

部署

部署是将服务的某个版本投入到生产环境的过程。对于服务部署更加需要关注的是后续服务的版本升级。服务部署的总体目标是：对系统用户产生最小影响的情况下，将服务的升级版本投入到生产环境中，这些影响可能是失败或停机时间。

在容器云中的部署，则是指从镜像仓库中拿到镜像文件在进行实例化的过程，而非直接将部署包部署到虚拟机或容器中。

服务的变更有三个原因：修复错误，提升服务质量或者增加新功能。

对于微服务模块的部署，其场景往往更加复杂，一方面是微服务模块本身的部署和应用托管，一方面是需要将微服务模块提供的微服务API接口注册到微服务网关。同时可以看到对于微服务模块本身在进行服务升级或变更的时候需要全面的分析微服务模块和服务API接口相互之间的依赖和影响关系。

注：在当前一个完整的微服务应用体系内部，K8s+Docker容器云平台可以和类似SpringCLoud框架体系，Eureka等注册中心实现集成。即实现在微服务模块自动化部署完成后自动进行微服务的注册。

对于灰度发布或滚动升级是保证系统安全可靠运行的一个常见方法，为了实现滚动升级需要PaaS管理平台和微服务模块本身的配置改造来支撑。滚动升级在资源使用方面更加有效，但是容易引起逻辑一致性问题：

1. 单个服务多个版本同时服务，容易提供不一致的服务
2. 客户端可能假设依赖服务的一个版本，但是实际上是由另外一个版本服务提供

逻辑一致性的解决方法是使用某些功能开关的组合，向前或向后兼容，以及版本意识和管理。部署必须偶尔回滚，对于功能开关还需要支持回滚功能。

功能开关用来控制是否激活一个功能，而在判断一个功能是否激活的时候，需要判断是否所有涉及到该功能的服务都全部升级完成，只有全部升级完成才能够在所有虚拟机上同时激活该功能。同时在分布式架构和集群中，还需要采用ZooKeeper等事务协调机制来保证一致性。

服务版本需要支持向前兼容性，如果一个服务版本升级不能向前兼容，这就意味着所有原来消费老服务版本的系统或模块都需要进行修改。在这种情况下往往只能够发布一个新版本服务，保证新老版本服务同时运行，并在后续变更中逐渐消亡或替代老服务版本。

部分部署方法：蓝绿发布和金丝雀发布。

注意两种发布模式实际都会有新版本和旧版本两套环境，在蓝绿发布下流量全部切换到新版本环境，如果出现问题再切换回去；而对于金丝雀发布则是先切换少量流量到新版本环境，如果没有问题再逐步完成更多流量的切换。

提供自动化的回滚能力仍然是在自动化部署和持续集成中需要考虑的问题，而对于回滚真正的难点在于数据库和数据的回滚，而不是部署包和镜像文件的回滚。对于数据的回滚当前仍然是一个难题，如果是完全恢复上一次的数据库备份，仍然需要耗费相当长的时间才能够完成。

监控

随着DevOps的发展对监控提出了新的挑战，DevOps的持续交付，持续部署和强烈依赖自动化意味着更加频繁的系统变更，同时在使用微服务架构时也使得数据流的监控更具挑战。这里面实际的难点包括了多方面：

1. 持续变更增加了监控本身的复杂度，持续的变更和部署使整个环境处于一种不稳定状态。
2. 和云环境的集成增加了监控难道，特别是PaaS平台集成后底层资源往往处于不可见状态。
3. 监控已经从传统的网管类资源监控，转移到了应用和服务监控，如APM应用性能分析和服务监控。
4. 微服务架构下微服务模块和服务接口都成倍增加，即要监控部署包又要监控服务接口
5. 在大型分布式系统中，管理和分析日志成为一个大的挑战

对于DevOps的监控，我们一定要意识到一个大的变化点，即从传统的网管应用对资源层的监控，转移到了对应用和服务本身的性能监控分析。监控不再局限于传统的CPU和内存，数据库和中间件关键指标，而更多的变化为对应用本身的性能，服务性能，服务调用链的实时分析和监控。

无代理监控方案对应用和环境侵入最小，配置容易，但是可能需要开放更多端口，存在安全隐患。同时无代理方案本身监控的指标详细度往往也不足够。

监控的目的和用途，书里面主要列举了如下几个方面的内容：

1. 故障检测：包括两种方式一种是完全外置，一种是需要内置代理到应用或服务器
2. 性能下降检测：对于访问延迟，吞吐量，CPU和内存利用率等是常用的监控指标体系。
3. 容量规划：长期容量规划需要人工进去，而短期完全借助PaaS平台本身的资源动态调配扩展能力。
4. 用户交互：最好理解为对用户访问行为信息的数据采集和分析，包括访问时长等性能信息。
5. 入侵检测：主要是通过设置的安全策略和网络流量监测来判断是否遭到入侵。

数据采集（用户行为，运维日志，应用和服务器状态信息）+预设报警或预警规则=》实时警告。监控的核心是记录和分析运维时间序列数据。监控系统可以直接度量或收集存在的数据，统计，日志，然后转换为指标，这些指标的属性包括了时间和空间。然后使用预定义的协议将这些数据传输到存储库。

日志是事件的时间序列，日志在监控中起着非常重要的作用，尤其是在DevOps设置中。对于日志监控不再只是传统运维中的数据库和中间件日志，在DevOps中运维人员已经成为第一干系人，因此日志包括了应用和服务的关键日志信息，这些日志方便运维人员进行故障诊断和问题排查。

日志关键信息

日志关键信息包括了机器ID，进程ID，类型，错误等级，时间，详细内容，关键标签等。对于日志监控，现在常见的ELK(ElasticSearch, Logstash, Kibana)是一个完整的覆盖日期采集，分析和可视化展示的完整解决方案。

而对于flume更多只是日志采集方案，当然也可以基于flume，storm，kafka等主流技术来自定义适合业务需求的日志采集和监控解决方案。

监控系统向运维人员提供重要的事件信息，这些信息以警报或警告的形式提供，其满足预设的触发条件的时候就被触发。在监控系统中，将包含大量覆盖系统很多方面的大量指标，意味着可能会产生大量的警报或警告信息，因此在预警或报警规则设置的时候需要折中处理，否则会告警疲劳。

对于监控的工具，可以分为三大类工具进行分析

1. 传统的网管类监控工具：例如Nagios, Zabbix等开源监控解决方案。
2. 基于日志采集和分析类工具：例如前面谈到的ELK解决方案，Flume+Storm+Kafka解决方案等。
3. APM应用性能监控工具：基于自上而下的监控和分析路线，从应用和服务入手再到资源层。

随着DevOps的发展，个人更看好APM应用性能监控和发展，即我们传统的对资源的监控，基于CPU和内存，进程等的由下而上的监控更多都是被动式的监控模式，更逐渐会被自上而下的监控，基于应用和服务驱动的监控替代，即一种主动第一时间发现问题，面向客户并提示客户满意度的模式。

Prometheus（普罗米修斯）是一套开源的监控&报警&时间序列数据库的组合。Prometheus基本原理是通过HTTP协议周期性抓取被监控组件的状态，这样做的好处是任意组件只要提供HTTP接口就可以接入监控系统，不需要任何SDK或者其他的集成过程。这样做非常适合虚拟化环境比如VM或者Docker 。

Prometheus应该是为数不多的适合Docker、Mesos、Kubernetes环境的监控系统之一。近几年随着k8s+docker容器云的流行，Prometheus成为了一个越来越流行的监控工具。

安全与安全审计

在DevOps的实践中，需要考虑如下一些安全方面的活动和内容：

1. 安全审计：DevOps全流程是否符合企业标准的安全策略，包括Dev和Ops基于安全的协作活动。
2. 部署流水线安全：整个部署流水线作业是否会受到恶意攻击和侵入。
3. 微服务架构安全：其中重点是保留的微服务接口服务本身的安全。

安全审计：DevOps中一个流行语即是，基础设施即代码，也就是说把脚本和DevOps过程规格说明视为代码，使用和代码相同的质量控制实践。安全策略，监管规则和配置可以自然地内置在基础设施代码和自动化中以便于审计。自动化也可以帮助生成安全审计和合规性报告。

安全这章讲得不太好，实际上更多是云安全，应用安全，基础设施安全等方面内容的归纳总结，而实际我们真正关心是DevOps下的安全，即DevOps部署流水线和微服务架构下需要怎样的安全策略和技术配合支撑等。

在整个DevOps流水线设计中，实际是可以加入安全审计插件来自动化完成相关安全检查。其中包括了代码规范性检查，代码安全和漏洞扫描，同时也包括了对于容器安全方面的检查也可以前移到DevOps持续集成阶段来完成。

传统的Devs和Ops也分别形成了安全关注点的两个不同领域。开发者关注应用安全设计，而运维关注基础设施和运维环境安全。应用安全本身也依赖于运维安全。通过基础设施即代码，开发人员驱动的自动化和DevOps工具，DevOps正在把一些运维安全责任转移给开发人员和工具。

对于DevOps实践，从一开始就应该考虑安全验证和确认，并且通过DevOps流水线自动化的在不同阶段执行，包括安全检测也可以通过自动化工具在某一个阶段自动执行。但是在单元，集成和系统级别上执行合适的和半自动化的安全分析和测试不是一件简单的事情。

对于DevOps的安全，不仅仅是关于应用和运维安全的，而且也是关于流水线本身的安全，例如构建/测试服务器安全，微服务组件安全，环境安全和动态配置期间的安全等。

其他非功能性需求

首先DevOps流水线本身也是一个软件产品，这产品的最终用户是开发和运维；其次，DevOps流水线具有过程的属性，相对于产品质量和性能，这里提到的一些非功能性需求更多的与过程质量和性能相关。

对于DevOps流水线的非功能需求和质量关注点可以简单描述如下：

1. 可重复性：重复相同操作的可能性程度。
2. 性能：执行DevOps操作所需要的时间和资源。
3. 可靠性：在一定时间周期，DevOps流水线和内部各软件保持服务状态的程度。
4. 可恢复性：失败的DevOps操作恢复到希望状态的程度。
5. 互操作性：特定环境下，不同的DevOps工具通过接口有效地交换信息的程度。
6. 可测试性：通过测试，DevOps运维软件能够很容易地展示错误。
7. 可修改性：修改DevOps软件，过程或应用运维环境所需要的工作量。

对于DevOps流水线来说，这里面最重要的仍然是可靠性，可重复性和性能，同时还包括在出现故障后的快速恢复能力，包括了整个流水线的全程可视化监控和管理能力。这些都是远行科技在进行DevOps支撑平台研发和流水线功能的时候重点考虑的内容。

这要求流水线中的每个活动涉及到的组件或工具，都具备暴露南向和北向接口服务的能力，提供供管理监控台进行状态监控和日志数据实时采集的能力。这些都是必须工作，而不是简单的通过工具实现自动化就完事。

业务关注点

DevOps的目的是减少从向系统提交变更到这个变更被部署在正式生产环境所需要的时间，同时保证高质量。保证高质量意味着，在将最终的高质量系统提升到正式生产环境之前，可能进行多次问题检测和问题修复的迭代。减少问题检测和问题修复的时间也是重要的。

因此两个重要的度量是，从提交到初始生产环境的时间和问题检测到修复的时间。对于DevOps，这部分进一步从五个方面给出了实践指导：

1. 在开发系统时，让Dev把Ops作为首要干系人。
2. 让Dev更直接地参与到故障和问题处理过程中，包括对详细异常信息和日志的查看和分析。
3. 为了将软件变更部署到生产环境，强制执行一致性的过程。
4. 开发基础设施代码的时候采用与开发应用程序代码相同的实践。
5. 实施持续交付的流水线自动化作业能力。

持续部署流水线

持续部署流水线主要包括了5个阶段，即构建和测试，烧制，部署，发布，拆解。

1. 构建和测试：版本管理工具，分支管理，自动化构建脚本和自动构建，自动化单元测试等。
2. 烧制（打包）：即制作虚拟机镜像或轻量的Docker容器镜像。
3. 部署：部署一个独立的应用程序栈，需要支持负载均衡，伸缩，监控，组网和数据库等能力。
4. 发布：发布重点是DNS路由器的重新分配和迁移
5. 拆解：一旦所有流量迁移到新栈后，拆解旧栈

标准化的应用程序生命周期在持续部署系统中作为一个计划实施。标准的镜像文件的部署也不仅仅是镜像启动，还涉及到服务的注册，负载均衡的挂接，环境变量和配置文件的修改等一系列工作。

在我们自己的流水线功能设计中，重点是分为构建，打包，部署几个关键动作。构建如果是基于Maven的话，则是选择指定的Pom文件，构建源代码路径。而对于打包则是进行容器镜像制作的过程，你需要指定镜像模板并编写dockerfile来完成。对于部署重点则是设置相应的部署策略，最有动态调度策略，集群配置，存储配置等。

当持续集成和持续交付两个分离的时候，一般来说并不会实现一个完整的从开发测试到生产环境的长流水线，而是会将生产环境的发布进行单独的流水线设计，对应到发布管理功能。

下图为运行DevOps介绍可参考：