教程【免费下载链接】growth-ebookGrowth Engineering: The Definitive Guide。全栈增长工程师指南项目地址https://gitcode.com/phodal/growth-ebook点击查看免费下载本文是《Growth全栈增长工程师指南》中持续交付一节的深度展开。持续交付Continuous Delivery是一系列工具与实践的组合它让软件在任何时刻都处于可部署的状态是连接编码、测试与上线的关键一环。读完本文你将理解持续交付的完整工作流、落地所需的本地开发环境/持续集成环境/测试环境三类基础设施并掌握持续部署与持续交付的本质差异以及它们与自动化部署、可配置性、持续集成之间的协作关系。持续交付让软件随时处于可交付状态持续交付依赖于一系列的工具和实践下图展示了一个典型的持续交付工作流这张图以**提交Commit**为起点形成一个环形闭环代码提交后依次经过自动化验收测试、探索性测试、用户验收测试UAT、预发布/准生产环境最终到达生产环境而生产环境的反馈监控Feedback Monitoring又回到提交环节驱动下一次迭代。环上每一环都标注了典型的工具链例如Commit代码提交构建、单元测试、代码指标、版本控制关联 Git、JUnit、Maven、Nexus 等工具自动化验收测试集成测试、冒烟测试、特性级测试、组件测试、服务虚拟化关联 JUnit、Cucumber、SpecFlow 等探索性测试UI 测试、可用性测试、手动测试关联 Selenium 等用户验收测试UAT演示、客户端主导的特性级测试、手动测试Staging 与预生产性能测试、网络测试、容量测试关联 JMeter 等生产环境部署后测试、持续在线事务测试、应用监控关联 Jenkins、Docker、Chef 等。也就是说持续交付不只是部署这一个动作而是一条覆盖构建、测试、发布、监控的完整流水线。如果用一张更直观的三阶段图来概括这条流水线可以理解为持续集成 → 持续测试 → 持续部署在这一工作流中左侧开发者在各自机器上完成代码与单元测试通过后进入集成单元测试与构建核心特征是 Fast快速中间阶段执行部署与冒烟测试BVT并展开回归、功能、系统、手动等端到端自动化测试右侧所有测试通过后进入预发布部署与测试再进入生产部署与验收全程保持持续反馈Constant Feedback。与开发无关却决定交付成败的四项技能原文特别强调持续交付还依赖一系列与开发无关的技能自动化——把重复的构建、测试、部署动作交给工具执行DevOps——打破开发与运维的边界让团队对交付结果共同负责云基础设施——弹性、可复现的运行环境是自动化部署的前提以软件为中心的哲学——把环境、配置、流程本身当作软件来管理。这四项能力决定了持续交付能否真正落地也呼应了本仓库《Growth全栈增长工程师指南》对全栈工程师的定义不只精通某个领域而是对系统有整体性的认识参见 README.md。基础设施让项目可以持续交付软件包在让项目可以持续交付软件包之前我们需要逐层搭建三类环境本地开发环境、持续集成环境与测试环境。本地开发环境开发机器上的最小工具集假设我们要开始一个 Java Web 项目在开发机器上需要安装版本管理工具如 Git用于管理源代码IDE如 IntelliJ IDEA用于搭建开发环境构建工具如 Gradle用于安装依赖、运行测试、构建工程语法检测工具如 Checkstyle用于检查代码风格与潜在语法问题单元测试框架如 JUnit用于进行单元测试集成测试框架如 Cucumber、Selenium用于做行为测试。除了开发机器上的工具项目代码里还必须有四类配套脚本与代码CI 运行脚本用于在 CI 上运行指定的测试上传包脚本用于上传 build 完的软件包部署脚本用于在本地把包部署到测试环境监控代码用于监测网站性能和用户行为。此外还需要性能测试、网络测试等辅助测试工具来测试网站。这四类脚本正是交付管道的最小可运行单元——没有它们CI 服务器即使拿到了源码也不知道该执行什么、产物该送去哪里。持续集成环境Master 与 Agent 的分工要运行持续集成我们需要一台运行持续集成服务器的机器。持续集成服务器由两部分组成Master一个用于控制其他运行持续集成服务的机器Agent执行指令的机器。因此在 Agent 上需要安装对应的运行服务软件指定版本的语言环境如 Java、Python构建工具版本管理工具及对应的密钥用于拉取私有仓库源码打包工具如 RPM虚拟桌面即可以模拟桌面浏览器的软件用于执行 Selenium 等 UI 测试。同时我们还需要一个地方放置构建产物如 RPM 包即软件包仓库Binary Repository。这套 Master/Agent 架构在仓库的持续集成章节中有更详细的论述以 Jenkins 为例它基于 Java 开发提供了用于监控持续重复工作的软件平台让整个开发流程到部署都实现自动化。测试环境多环境隔离与差异化配置相比前两个环境测试环境要简单得多我们只需要创建几个不同的环境——开发者的测试环境QA 环境模拟线上环境Staging。这几个环境使用不同的配置。结合仓库中可配置章节的论述典型的环境划分至少包括环境用途数据特征开发环境开发者日常开发由开发者自己注入数据集成测试/测试环境自动化测试注入的测试数据Bug 时补充模拟环境Staging发布前预览产品环境旧数据数月或数年前产品环境线上运行真实用户数据不同的环境最好独立写在不同的配置文件里并以文件名区分如开发环境用dev.config.js、测试环境用test.config.js同时还需要一套变更控制机制否则只有配置而没有运行机制配置就形同虚设。更进一步当应用运行在多个机器上时修改配置要么选择热加载不停机生效但会持续消耗系统资源去读取、判断配置状态要么选择冷启动配合自动化部署批量更新——而功能开关Feature Toggle则允许我们在上线新功能出现 Bug 时通过切换开关而不是下线整个版本的方式来控制线上行为。自动化部署持续交付管道中的五步流水持续交付的落地离不开自动化部署。仓库的自动化部署章节给出了一个五步流程正好是持续交付管道中构建 → 发布环节的具体展开获取源码在 CI 服务器上使用git clone一类的方式获取源码版本管理在前面章节已就绪获取依赖无论是 Python、Ruby、Java 还是 JavaScript都需要下载软件包依赖。由于我们依赖公有的包服务系统会严重依赖于外部条件——原章节以 NPM 圈left-pad 模块被作者撤下导致大量软件包挂掉为例说明自建包服务如 Java 技术栈用 Nexus 搭建 Maven 私有服务是一种简单有效的方案代价是包可能不是最新的但对追求稳定的项目而言这反而是优势构建软件包编译型语言会产出 Jar 这类压缩文档但 Jar 无法直接安装使用需要拷贝到服务器并修改配置。因此RPM/DEB 包是更好的选择——RPM 全称 Red Hat Package ManagerRed Hat 包管理器工作于 Red Hat Linux 及其它 Linux 和 UNIX 系统。构建标准 RPM 包需要创建.spec文件包含包的 Summary、Name、Version、Copyright、Vendor 等信息然后执行rpmbuild命令生成目标 RPM 包生成/上传安装包生成软件包后上传到 KojiFedora 社区的编译系统目标平台安装/配置如果已经对所有目标操作系统配置好软件源就可以直接在服务器上用包管理工具安装如yum install。可见持续交付的最后一公里——软件包的构建、归档、上传与安装——完全由这套自动化部署机制支撑。持续交付工作流之所以强调随时可部署正是因为这些环节都已自动化、产物随时可被拉取。与持续集成的关系可部署的前提是可集成持续交付并不孤立存在它与仓库持续集成章节论述的实践互为表里。持续集成更关注代码质量在每一次构建后运行单元测试保证代码级的质量单元测试的粒度则用来平衡持续集成的质量与速度。其核心价值在于持续集成中的任何一个环节都是自动完成的减少人工干预节省时间、费用和工作量保障每个时间点上团队成员提交的代码能成功集成第一时间发现集成问题使任意时间发布可部署的软件成为可能利于软件本身的发展趋势在需求不明确或频繁变更的情景中尤其重要帮助团队有效决策并建立信心。持续集成的流程中值得注意两点小步前进集成越早问题越小。代码越早提交到源码服务器别人就能越早与之集成。每天结束时本地修改要尽可能小并且不破坏持续集成要频繁在本地提交代码、编写独立的测试——如果最后才写测试就会拖慢整个流程尽早反馈反馈越早问题越小。从 Code Review、静态代码分析、自动集成测试、自动验收测试到高频率发布都是在做尽可能小的反馈这是持续集成的基础也是持续交付管道中每个环节自动化的意义所在。持续部署持续交付的进阶形态在持续交付之外还有持续部署Continuous Deployment——这更依赖于团队的组织结构。两者的对比如下图所示从上图可以清晰地看到两者的前几个环节完全相同——单元测试自动、平台测试自动、交付至预发布自动、应用验收测试自动唯一的分歧点在生产环节持续交付部署到生产环境是手动触发的Deploy To ProductionManual部署后测试为自动持续部署包括部署到生产在内的所有环节全部自动Auto代码通过所有测试后自动上线。换言之持续部署会直接将构建生成的包部署到产品环境。这意味着团队不仅要有强大的技术实力也要有足够的组织支持——例如完善的自动化测试覆盖率、生产环境的监控与回滚能力以及团队对快速发布的文化认同。这部分已经超出了软件开发本身的内容但从持续集成到持续交付、再到持续部署正是交付能力逐步升级的三级台阶先保证可集成再保证可交付最终追求全自动上线。小结在《Growth全栈增长工程师指南》的知识体系中持续交付位于上线与数据分析之间的关键位置它向上承接编码、构建、测试向下支撑线上运行与反馈。回顾本章要点持续交付是一条覆盖提交、构建、测试、预发布、生产、监控的环形闭环工作流由自动化、DevOps、云基础设施与以软件为中心的哲学共同支撑落地持续交付需要三类基础设施本地开发环境工具 CI 脚本 部署脚本 监控代码、持续集成环境Master/Agent 分工Agent 预装语言环境、构建工具、密钥、打包工具与虚拟桌面、测试环境开发、QA、Staging 多环境差异化配置持续交付管道中的构建与发布环节由自动化部署的五步流程获取源码、获取依赖、构建软件包、上传安装包、安装配置承载并通过可配置机制保证不同环境各取所需持续部署是持续交付的进阶当部署到生产也变为自动交付能力才真正达到全自动化而这需要技术与组织的双重支撑。持续交付的本质正如仓库 6.0.0 章节 所概括的那样交付管道的建立和自动化是持续交付的基础。赞分享教程【免费下载链接】growth-ebookGrowth Engineering: The Definitive Guide。全栈增长工程师指南项目地址https://gitcode.com/phodal/growth-ebook点击查看免费下载相关推荐Growth 指南持续交付完全手册持续集成 CI 与持续部署 CD 落地实践Growth 指南持续交付完全手册持续集成 CI 与持续部署 CD 落地实践 Growth 指南 growth ebook https://link.git教程Wire与持续交付价值持续交付的依赖管理Wire与持续交付价值持续交付的依赖管理 在现代软件开发中持续交付Continuous Delivery要求团队能够快速、可靠地构建和部署应用。然而随开发工具代码生成从学术到生产bert-finetuned-ner-openmind在企业级NLP系统中的终极落地指南 从学术到生产bert finetuned ner openmind在企业级NLP系统中的终极落地指南 命名实体识别NER作为自然语言处理的核心任务上一篇如何快速用LeRobot跑通第一个机器人策略从采数据到真机回放下一篇React Native Sound 高级技巧实现背景音乐、循环播放和音量控制创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
