关键词：
软件交付通识
摘要
本篇博客参考董越老师的《软件交付通识》，对其第一部分内容进行简要总结，以便加深理解和记忆。
写在前面
1）书本导读
这本书介绍了软件交付的概念、目标、历史演进、策略、过程、细分领域、关注点和各个具体过程，并不针对具体的工具、技术、管理方法，更多介绍了概念性的、全面的“软知识”。这些知识由作者的经验汇聚而成，需要较多的亲身实践才能读进去，产生共鸣。
2）其他
正如上面所说，阅读此书需要一定的实践经验，且需要站在项目管理者的层面考虑，因而我读此书时，仅对软件交付相关概念和思想进行了了解，后面具体的过程没有读完。这实际并不能算是一种失败，正如今天阮一峰发布的科技爱好者周刊245期中引入的文摘中有：
“生命太短暂，不能花在那些不值得阅读的内容上面。就算你是一个很爱读书的人，活到70岁最多大概能阅读15000本书，这只占世界最大图书馆美国国会图书馆3800万册藏书的0.04%。我们一生中能够阅读的书籍其实很少。因此，关键技能不是多读，而是跳过那些不值得读的内容。”
若以后有缘再读此书或是多年以后…
1.软件交付概述
1）软件交付过程（Software Delivery Process）：编码之后到软件发布给用户为止的一系列活动，包括如：提交、集成、测试、代码评审、构建、发布上线等
2）软件交付过程的主要内容：①测试（动态的接口测试、UI测试；静态的代码评审、代码扫描；人工测试、自动测试）②提交、集成、联合测试、发布 ③软件形态转换：将源代码编译构建，转换为归档包、容器镜像等形态经过部署得到可实际运行的软件系统
3）软件交付不是按时间阶段或角色划分出来的，只要是做生产环境上的部署、完成软件的发布就属于软件交付过程
4）最终目标：一切为了业务（业务驱动）的成功（访问量、活跃用户数、市场占有率、盈利能力、社会效率、人类福祉）
5）小步快跑：将软件的生命周期划分为定义侧和实现侧，定义侧应定义一个小步伐的目标，实现侧应该快速完成。这是由于需求的不确定性，因而先做一个最小可行性产品MVP（Minimum Viable Product）确定市场、用户需求
6）软件实现侧/交付过程的目标：①较高的产能；②更快的响应速度；③适当的质量；④合理的成本
2.历史演进
1）从软件危机到工程化
2）敏捷
2001年“敏捷软件开发宣言”，去过度工程化
①管理实践：Scrum；②工程实践：单元测试；持续集成
3）精益
①起源于制造业的精益思想：面对VUCA（易变性Volatility、不确定性Uncertainty、复杂Complexity、模糊Ambiguity）的市场，去批量化、减少等待时间，从追求资源效率（单位成本的最大产出）到流动效率（审视创造用户价值的过程是否通畅）
②将精益思想应用于软件开发：精益创业（如何在高度不确定的情况下开创新的产品或服务）“开发-测量-认知”循环，用开发验证需求
③精益软件开发的重要实践：精益看板，将未发布上线的各个特性展现在看板墙上，使其可视化，让团队能够看到每个特性的进展
4）持续集成、持续交付、持续部署
- 持续集成
2007《持续集成：软件质量改进和风险降低之道》
①定义：持续集成是一种软件开发实践，即团队的成员经常集成（特性分支到主干分支、解决冲突）他们的工作，并通过自动化构建（测试）来发现并修复质量问题（本地测试、开发环境测试）
②如何做：版本控制、质量内建（系统交给测试人员之前先由开发人员自测）、自动化（提交自动触发测试流程）、过程可视化、加速
- 持续交付
①定义：持续交付是一种软件开发实践，能够让各类变更（新特性、配置变更、缺陷修复、尝试性内容等）安全、快速、可持续的交付到生产环境中或用户手上
②相比于持续集成的提交集成与开发环境测试相比，持续交付将质量验证工作扩展到整个系统与发布上线，其中融入更多的自动化，使比较频繁的发布上线成为一键式，是持续集成的更进一步。
- 持续部署
持续部署意味着每个通过部署流水线的变更都能动态地部署到生产环境中，相比于持续交付要求测试做到完全的自动化，可理解为持续交付的极致。
- 优点
①早合并、早暴露冲突和错误，早解决；②有利于跟踪进度和提供对进度的感知；③早接近可发布给用户使用的目标
5）DevOps
- 概念
2009 “10+Deploys Per Day:Dev and Ops Cooperation at Flickr” 《DevOps实践指南》
DevOpts标准（中国信息通信研究院的研发运行一体化能力成熟模型）
DevOps运动，强调从组织、流程规范特别是技术上将运维甚至安全（DevSevOps）等纳入进来，打通开发（Dev）、运维/技术运营（Ops）之间的隔阂（开发出新特性并上线 vs 线程运行的稳定性），实现真正的端到端，从用户需求到最终用户端。
DevOps是一组最佳实践，融合了“务虚”和“务实”，既包括组织、流程、文档、乃至文化，也包括自动化构建、自动化测试、自动化部署等技术。基于DevOps的最佳实践，充分运用自动化技术形成了虚拟的、可大量复制的软件生产及发布流水线，无需专门的运维人员，开发人员可以一键触发自动化部署、自动化测试
- DevOps三步工作法
①实现从开发到运维的快速从左向右流动：工作可视化、减少批次大小和等待间隔、内建质量避免向右传递缺陷，持续优化全局目标
②从右到左的每个阶段，应用持续、快速的反馈机制，通过放大反馈环防止问题复发，缩短问题检测周期，实现快速修复
③建立具有创意和高可信度的企业文化，支持动态的、严格的、科学的实验，主动承担风险，从失败中学习
- 落地实践
①自动化基础设施、共享的版本控制、一键完成构建和部署、特性开关、共享度量统计、即时通信机器人
②尊重、信任、对失败的正确态度、避免指责
6）技术方面的演进
①软件架构：结构化→面向对象→组件、插件、动静态链接库→微服务→软件复用与中台
②部署运行：虚拟机→容器化
3.典型软件交付过程
代码改动积累 → 代码改动提交（到特性分支） → （特性feature）分支改动积累 → （特性）分支改动提交（集成分支dev） → 集成分支改动积累 → 集成分支改动提交（主分支master）→ 发布（release）
4.具体活动
源代码版本控制、构建、构建环境管理、制品管理、部署、运行环境管理、配置参数管理、数据存储结构管理、代码评审、代码扫描、制品分析、单元测试、自动化接口测试、人工UI测试、自动化UI测试、非功能测试（性能与容量、安全性、兼容性、易用性）、生产环境测试
5.10个策略
1）细粒度、低耦合、可复用的架构
①软件架构
②测试脚本和测试数据的架构：数据驱动（测试脚本和测试数据分离）、页面对象模型、业务流程抽象、关键字驱动
③组织架构：小团队（5-9，<15）、低耦合（独立自主）、可复用；特性团队（长期的、具备交付价值所需的各种角色、可以协同完成完整用户价值交付的团队，针对独立产品而非仅是特性分支）；康威定律（组织结构做成什么样子，那么产品系统的架构就长什么样子）
2）小批量持续流动的流程：①大批量带来等待等问题；②短周期、小粒度、减少在制品
3）运用综合手段保证质量和安全
①综合各种测试：人工测试；自动化测试（接口、UI）；开发、生产环境（全链路压力测试、混沌工程、灰度发布、A/B测试）测试；灰度发布、绿蓝部署；分层测试策略（金字塔模型；橄榄球模型）
②左移（开发人员测试）+右移（发布到生产环境再测试）
③测试人员（专业能力测试：探索性测试、安全方面测试）+开发人员（单元测试、单个接口测试、代码评审、结对编程）
④人工测试+自动化测试（需要反复执行、有明确标准和规则的测试，不能完全取代人工测试）
4）自动化（单项活动自动化、流程自动化）与自助化（用户可以方便地自行配置使用，无需专门的运维人员即可一键式地构建、测试、发布）
5）加速各项活动：提高硬件能力；考虑并行；避免重复；只关注增量；使用缓存
6）及时修复：通知及时和精准；优先处理；修不如退；便捷排查
7）完备记录，充分展示：任务及其执行情况（工作项/变更请求管理工具）；日志（构建日志、部署日志、自动化测试报告）；版本和配置信息；制品管理；关联关系；维持单一可信源（Single Source of Truth,SSOT）
8）标准化：规范可重复（构建、发布过程标准可重复，同一源代无论在哪构建结果一致）；方案收敛（同一团队、公司的工具流程方案应一致）；环境一致性（本地开发环境、测试环境Mock挡板、生产环境）
9）协调完成完整功能
10）基于度量的持续改进
ci/cd(代码片段)
...念是持续集成、持续交付和持续部署。持续集成：是一种软件开发实践，团队开发人员频繁提交代码到源代码仓库，每次提交都进行构建、自动化测试，从而尽早发现集成问题。持续交付：频繁地将软件的新版本，交付给质量团... 查看详情
docker(代码片段)
...Docker能够将应用程序与基础架构分开，从而可以快速交付软件。借助Docker可以与管理应用程序相同的方式来管理基础架构。通过利用Docker的方法来快速交付，测试和部署代码，可以大大减少编写代码和在生产环境中运行代码之间... 查看详情
开发成长之路（13）--linux网络服务端编程（通识篇）(代码片段)
文章目录文件I/O进程线程SOCKET网络编程epoll线程池数据库专区文件I/O引用一句经典的话：“UNIX下一切皆文件”。文件是一种抽象机制，它提供了一种方式用来存储信息以及在后面进行读取。在创建一个文件后，它会给... 查看详情
基于jenkins+docker+git持续化自动部署项目(详细版一))；(代码片段)
软件的安装jenkins的安装jenkins的安装持续集成(CI)持续集成指的是，频繁地（一天多次）将代码集成到主干。将软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。持续交付持续交付（Continuousdeliv... 查看详情
helmchart多环境多集群交付实践，透视资源拓扑和差异(代码片段)
HelmCharts[1] 如今已是一种非常流行的软件打包方式，在其应用市场中你可以找到接近一万款适用于云原生环境的软件。然后在如今的混合云多集群环境中，业务越来越依赖部署到不同的集群、不同的环境、同时指定不同... 查看详情
使用drone+gitea配置自己的cicd流程(代码片段)
...ContinuousDelivery），持续部署（ContinuousDeploy）。他是一种软件开发实践，核心是通过引入自动化的手段来提高软件交付效率。其最终目的是为了让工程师更快，更高质量，更简单的交付软件。持续集成在传统软件开发过程中，集... 查看详情
开源软件通识基础：第二周课程回顾与总结
接第一篇《开源软件通识基础：第一周课程回顾与总结》，本文为第二周课程内容的回顾与总结。本导学班在调研全球开源教育与课程的基础上，通过收集、整理、理解、拓展国际最新的前沿开源课程，采取众创... 查看详情
msivsnuget包：哪个更适合持续交付？(代码片段)
...opy方法。这种方法很难管理依赖项，文件更新等。有一些软件包的帮助下启动应用程序部署的想法，你知道你在Linux的帮助下RPM，但适用于Windows。所以我有疑问：在Windows经典Windows安装程序（msi）或nuget或其他东西上使用什么包... 查看详情
kubevela上手｜让云端应用交付更加丝滑(代码片段)
...省力，轻松简单作者｜KubeVela社区 本文适合所有软件工程师进行阅读使用，尤其是希望开拓后端技术视野的前端、移动端和全栈工程 查看详情
kubevela上手｜让云端应用交付更加丝滑(代码片段)
...时省力，轻松简单作者｜KubeVela社区本文适合所有软件工程师进行阅读使用，尤其是希望开拓后端技术视野的前端、移动端和全栈工程师们 查看详情
jenkins(代码片段)
...成到主干。持续交付（Continuousdelivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。持续部署（continuousdeployment）是持续交付的下一步，指的是代码通过评审以后，自动部署到生产环境。Jenkins是一款开... 查看详情
exe打包成安装文件（界面美观）(代码片段)
前言在开发windows桌面应用过程中，软件交付时，一般都是交付安装包。安装文件的优点显得更正规，安装界面也可展示软件特点介绍，可自动生成桌面图标等；安装包体积要比软件小，方便下载。探索之路最开始用的打包软件... 查看详情
正交设计(代码片段)
...ftwareeasilyinthelongterm.--KentBeck.设计是什么正如KentBeck所说，软件设计是为了「长期」更加容易地适应未来的变化。正确的软件设计方法是为了长期地、更好更快、更容易地实现软件价值的交付。软件设计的目标软件设计就是为了完... 查看详情
texthg交付要点(代码片段)
xmlmiva-运输交付估算(代码片段)
基于jenkins的持续交付全流程设计与实践(代码片段)
...境的发布流程总会存在不顺利。而DevOps则致力于统一整合软件开发和软件运维，其特点是强烈倡导对构建软件的所有环节（从集成、测试、发布到部署和基础架构管理）进行全面的自动化监控。目标是缩短软件开发周期，提高部... 查看详情
华为云容器交付流水线引领企业容器化之路(代码片段)
...D等一系列工具的支撑，CI/CD工具的出现大大提升了企业的软件行业的效率，可以称得上是软件工程领域的工业革命，但容器化的大浪潮到来时，企业现有的CI/CD工具，以及围绕着这些工具所构建的集成和交付体系，因为与企业IT... 查看详情