- 综合排序
- 最热优先
- 最新优先
- 来自专栏ThoughtWorks
持续交付2.0：云原生持续交付
《持续交付》提出了一系列贯穿整个软件交付生命周期的最佳实践。但它成书的年代（2010年）云计算尚未得到广泛应用，尤其在软件开发过程中的应用非常有限。 如果站在今天的技术水平和对云计算的理解水平基础上回顾《持续交付》的内容，我们有可能提出一组全新的、原生于云环境的持续交付实践。 ? 对于这些反模式，《持续交付》提出的解决办法是“将几乎所有事情自动化”。 《持续交付》中提倡整个部署流水线“只生成一次二进制包”，并且在各个验证步骤之间传递二进制包。 ---- 持续集成 尽管《持续交付》说“选择并安装好持续集成工具之后，只要再花几分钟的时间配置一下就可以工作了”，但实际上很少有哪个项目的持续集成实施会如此顺利。
2K50发布于 2018-04-13 - 来自专栏测试开发技术
3分钟了解清楚持续集成、持续交付、持续部署
近些年来，持续集成、持续交付以及持续部署这几个热词总是在大家的眼前晃来晃去！在招聘信息和面试过程中也会经常提及！在这里我就用三分钟时间来带大家了解他们！ 1. 持续交付（CD：Continuous Delivery） 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的类生产环境中。如果测试没有问题，可以继续手动部署到生产环境中。 持续交付能够以较短地周期完成需求的小粒度频繁交付。频繁的交付周期带来了更迅速的对软件的反馈，并且在这个过程中，各个角色密切协作，相比于传统的瀑布式软件团队更少浪费资源。 [007S8ZIlgy1gfielld8u6j30iy0e2myb.jpg] 3. 总结 简单地说： 持续集成主要是在开发范围，包括：构建>单元测试； 持续交付涉及开发、测试、运维合作,包括：构建>单元测试>测试环境部署>测试（不涉及生产环境的自动化部署） 持续部署是在持续交付的基础上的延伸
1.1K00发布于 2020-06-06 - 来自专栏运维之路
3.2.2 持续交付
持续交付的边界有两种观点，一种是持续交付介于持续集成与持续部署之间，强调软件一直处于可交付的能力；另一种是持续交付包括了部署。 虽然从词语来看包括Dev（开发）、Ops（运维），实际应该包括开发、质量、运维3个团队之间的沟通、协作与整合。 3.发布流水线 发布流水线是将一个软件发布环节串起来，让软件交付过程中不同的角色可以透明的看到整个过程。 持续交付的一个基本发布流水线通常包括提交、测试、生产部署（或回滚）3个步骤，围绕这3个步骤画了一张图，大致意思是： ? 3) 关联工具 在上图右边是一些关联工具应用。首先，从工具角度看发布流水线，需要有一个在线编排的功能，能够对流水线上的不同环节进行编排。
1.3K10发布于 2021-03-19 - 来自专栏新亮笔记
持续交付管理
《持续交付 发布可靠软件的系统方法》读书笔记 实现持续交付不仅仅是买些工具，做一些自动化的工作。它依赖于交付过程中所涉及的每个人的协作，来自行政管理层的支持，以及基层人员的改进意愿。 持续交付不仅仅是一种新的交付方法论。对依赖于软件的业务来说，它是一个全新的范例。要想知道为什么，需要研究公司治理核心中一种根本的张力（tension）。 提高软件交付生命周期的可预测性，让计划更有效。 具有采用和遵守任何必要的法律规章的能力。 具备有效发现和管理软件交付相关风险的能力。 通过更好的风险管理和交付更少缺陷的软件来减少成本。 在整个项目过程中，持续识别和管理风险。 风险管理过程应该有如下几个关键特征： 一个项目团队汇报项目状态的标准结构。 项目团队依赖标准，定期更新进度状态。 常见的交付问题 不频繁的或充满缺陷的部署 花很长时间部署某个构建版本，而且部署过程很脆弱。 较差的应用程序质量 交付团队无法实施有效的测试策略。 缺乏管理的持续集成工作流程 不适当的构建过程管理。
88210编辑于 2022-12-05 - 来自专栏新亮笔记
持续交付 2.0
很多人将具有以上 3 个特征的软件开发方法统称为“重型软件开发方法”。 敏捷软件开发方法 敏捷软件开发方法强调发挥人的主观能动性，提倡面对面沟通、拥抱变化、通过迭代和增量开发尽早交付有价值的软件。 持续交付 1.0 “持续交付 1.0” 是一种能力，也就是说，能够以可持续方式，安全快速地把代码变更（包括特性、配置、缺陷和试验）部署到生产环境上，让用户使用。 持续交付七巧板 讨论了 “持续交付2.0” 的指导思想、工作理念和核心原则。大家很容易意识到，它对适应快速变化的市场环境和激烈的市场竞争是非常有效的。 企业需要在组织管理机制、基础设施以及软件系统架构 3 个方面付诸行动，而每一个方面都包含多项内容，如下图。 每个企业的实施路径可能各不相同，所需要的周期也各有长短，对各方面的能力需求也不完全一致。 “持续交付 2.0” 的 4 个核心工作原则是坚持少做、持续分解问题、坚持快速反馈和持续改进并衡量。只有这样，才能不断缩短持续交付 “8” 字环的运行周期，提升用户反馈速度，从而提高业务的敏捷性。
1.1K11编辑于 2022-12-05 - 来自专栏顾宇的研习笔记
【翻译】持续交付 VS 持续部署
(中文版)在我和 Dave 出版《持续交付》一书之前一年多就发表了。 我们决定把这本书叫做《持续交付》有几个原因。首先，有一个有点学究的事实是：部署并不意味着发布。就像我们在书中说的那样，你可以持续部署到 UAT 环境——这不是什么太大的问题。 尽管持续部署意味着持续交付，但反之并不成立。持续交付是把发布计划的决策权交给业务，而不是 IT。 如果你正在使用看板并且想要进行持续交付，直到故事发布给用户之前，这个故事都没有发挥作用。 然而，向用户发布每次成功的构建并不总是有意义的。 那么你什么时候可以说你在做持续交付呢？ 我想说的是，如果你认为这是为客户提供价值的最佳方式，那么你可以切换到持续部署。特别是，如果你无法保证向用户每次发布一个成功的构建。
1.2K10编辑于 2022-09-08 - 来自专栏FunTester
持续交付：低风险快速交付
持续集成和持续交付等实践能够在进行任何更改后立即将代码交付到生产环境中。当使用更小改动的代码块时，将会让新功能发布和修复BUG并行成为可能。 在项目中实施持续集成有很多好处。它是软件更新的一个基本过程，其主要功能是将来自不同开发人员的代码更改集成到一个仓库中。 今天我们将重点介绍 CI/CD 的第二阶段，持续交付。 根据持续交付状态报告，在 19,000 多名开发人员中，有 50% 的人指出他们以每周一次到每月一次的频率进行部署。其中 2/3 的代码在提交后至少需要一周才能成功将代码运行到生产环境中。 何谓持续交付 根据持续交付的实践，团队开发软件是以最小变动代码块为单元，产品发布不是手动进行的，而是通过一个按钮来完成的。代码中的每个小改动都会自动构建、测试并发布到生产环境中。 这是对源代码的系统检查，旨在发现和纠正在开发的初级阶段没有注意到的错误； CD 实施的好处 持续交付的自动化过程为团队和项目带来了许多好处。
39320编辑于 2023-08-04 - 来自专栏muller的测试分享
持续交付-Jenkinsfile 语法
实现 Pipeline 功能的脚本语言叫做 Jenkinsfile，由 Groovy 语言实现。Jenkinsfile 一般是放在项目根目录，随项目一起受源代码管理软件控制，无需像创建"自由风格\"项目一样，每次可能需要拷贝很多设置到新项目，提供了一些直接的好处：
1.1K00编辑于 2022-06-24 - 来自专栏不止dotNET
读《持续交付2.0》
几年前看过《持续交付(发布可靠软件的系统方法)》，感触不是很深，最近看了这本书的译者乔梁编写的《持续交付2.0》，结合工作中的种种，又有一种相见恨晚的感觉。 全书围绕着双环模型展开，介绍了持续交付，快速实现客户业务价值的一系列的方法论和实践工具。本文将结合实际工作中遇到的问题来谈谈这些方法论和工具。 工具 持续交付在实践过程中离不开自动化工具，大体可以分为自动化构建和自动化测试。 自动化测试 自动化测试大体可以分为单元测试和端到端测试，单元测试对开发人员的要求比较高，要保证持续交付高质量的产品，单元测试非常重要，我们现在也在规划和完善。 总结 持续集成2.0这本书中有很多的干货，本文我只是找了几个我认为比较重要的点进行了描述，总之就一个目的，我们要快速地、正确地、高质量地把任务完成，并交付客户。
1.6K30发布于 2019-11-29 - 来自专栏后端JavaEE
docker----CD（持续交付，持续部署）
二、CD（持续交付，持续部署） 2.1 CD介绍和Jenkins安装 代码在经过测试人员的专业测试后，需要经代码打标签，将代码发布到真正的生产环境。
1.1K71发布于 2020-10-30 - 来自专栏陶士涵的菜地
持续交付Jenkins安装
1.下载并运行 Jenkins 下载 Jenkins. http://mirrors.jenkins.io/war-stable/latest/jenkins.war
48630发布于 2019-09-29 - 来自专栏muller的测试分享
持续交付-Pipeline入门
Pipeline 是一组插件，让 Jenkins 可以实现持续交付管道的落地和实施。持续交付管道（CD Pipeline）是将软件从版本控制阶段到交付给用户或客户的完整过程的自动化表现。
77950编辑于 2022-07-01 - 来自专栏CNCF
持续交付的好处
你很容易与你的团队、老板和竞争对手分享；我们都可以从更快、更安全地交付软件中受益。 小贴士：把它放在某人的办公桌上作为一个节日惊喜，也许我们一起可以让2021年更好。 ? 我谨代表持续交付基金会祝你和你的亲人有一个安全快乐的假期。
1.4K30发布于 2020-12-28 - 来自专栏DDD
常识三持续集成、持续交付、持续部署
概念 假如把开发工作流程分为以下几个阶段： 编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署 ? 正如你在上图中看到，「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」有着不同的软件自动化交付周期 「持续交付（Continuous Delivery）」 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。 「持续部署（Continuous Deployment）」 持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。 ? 三者关系 持续交付、持续部署 将持续集成扩充到部署到生产环境就是持续交付和持续部署的概念，二者的区别 ? 手动与自动的区别 CI步骤 ?
2.4K50发布于 2021-03-23 - 来自专栏翎野君
持续（集成-->交付-->部署）
软件的开发工作的大致流程 编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署 由上图可知「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery 2.持续交付： 持续交付（Continuous delivery）指的是，频繁地将软件的新版本，交付给质量团队或者用户，以供评审。如果评审通过，代码就进入生产阶段。 持续交付可以看作持续集成的下一步。 它强调的是，不管怎么更新，软件是随时随地可以交付的。 持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。 持续交付优先于整个产品生命周期的软件部署，建立在高水平自动化持续集成之上。 持续交付的好处 持续交付和持续集成的优点非常相似： 快速发布。能够应对业务需求，并更快地实现软件价值。 3.持续部署： 持续部署是指当交付的代码通过评审之后，自动部署到生产环境中。持续部署是持续交付的最高阶段。这意味着，所有通过了一系列的自动化测试的改动都将自动部署到生产环境。
1.6K10编辑于 2023-05-12 - 来自专栏博文视点Broadview
DevOps和持续交付
DevOps的另一个核心目标是自动化和持续交付。简单来说，自动化一切可重复的乏味的工作，把更多时间留给人与人之间的交流，这才能产生真实的价值。 多快才算快？ DevOps化的转变必须要快。 这也是持续交付运动的思路。 就像敏捷的很多东西一样，DevOps和持续交付虽然有许多概念名称不同，但是它们都有着相同的含义。它们只不过是一枚硬币的正反面而已，在概念上并没有什么争议。 下面是一些敏捷周期可以从DevOps获益的例子： DevOps工程师维护的部署系统，让Scrum周期最后的交付更快、更有效。而交付每2到4周就会周期性地发生。 一旦代码提交到代码库，取决于变更集的大小，一个设计良好的持续交付流水线大约只需要几分钟就可以把提交的代码部署到生产环境。 DevOps和持续交付认为我们交付到生产环境的变更集应该小而频繁，乍一看，ITIL的观点似乎与之相反。然而这并不是事实。
70510发布于 2020-06-12 - 来自专栏muller的测试分享
持续交付-Blue Ocean 应用
Blue Ocean 特性： 流水线编辑器：用于创建贯穿始终的持续交付流水线，是一种直观并可视化的流水线编辑器。 流水线的可视化：对流水线的可视化表示，提高了全企业范围内持续交付过程的清晰度。 流水线的诊断：即刻定位自动化问题，无需持续扫描日志或关注多个屏幕。 个性化仪表盘：用户可以自定义仪表盘，只显示与自身相关的流水线。 Tests 视图查看测试运行结果 单测结果展示 图片 Blue Ocean为开发人员提供了更具乐趣的 Jenkins 使用方式，从基础开始构建，实现了一种全新的、现代风格的用户界面，有助于任何规模的团队实现持续交付
73400编辑于 2022-06-26 - 来自专栏FunTester
持续测试、持续集成、持续交付、持续部署和DevOps
团队透明度和问责制增加 提高测试可靠性，减少积压，提高最终产品质量给客户 持续测试、持续交付和 DevOps 持续交付的角色从持续集成结束的地方开始。 持续交付仅仅意味着在任何时间点不断地将代码移动到生产环境中，这只能通过对代码的持续测试来实现。它涉及分小阶段将构建交付到生产环境，以便在最终发布之前随时进行彻底的验证和测试。 DevOps鼓励参与产品开发和交付的团队之间进行沟通协调。除了生产之外，大多数团队还在开发和测试环境中工作。持续交付确保代码自动推送给他们。 为什么持续交付在DevOps中很重要？ 需要更少的代码更改，使发布高效且可重用 确保可靠和更快的软件交付 提供更好的客户满意度 有效的持续交付流程提高了开发投资回报率 可靠的价值链绩效 持续测试、持续部署和 DevOps 持续部署是另一种软件发布策略
2.7K30发布于 2021-11-04 - 来自专栏yeedomliu
《持续交付：发布可靠软件的系统方法》第3章 持续集成
第3章 持续集成 3.1 引言 持续集成要求每当有人提交代码时，就对整个应用进行构建，并对其执行全面的自动化测试集合。而且至关重要的是，假如构建或测试过程失败，开发团队就要停下手中的工作，立即修复它。 持续集成的目标是让正在开发的软件一直处于可工作状态 持续集成是一种根本的颠覆。如果没有持续集成，你开发的软件将一直处于无法运行状态，直至（通常是测试或集成阶段）有人来验证它能否工作。 如果它失败了，你要与团队中的其他人一起将其修复，然后再提交自己的代码 (2) 一旦构建完成且测试全部通过，就从版本控制库中将该版本的代码更新到自己的开发环境上 (3) 在自己的开发机上执行构建脚本，运行测试 (4) 如果本地构建成功，就将你的代码提交到版本控制库中 (5) 然后等待包含你的这次提交的构建结果 (6) 如果这次构建失败了，就停下手中做的事，在自己的开发机上立即修复这个问题，然后再转到步骤(3) 3.7.1 对流程的影响 为了使交付过程更加平稳，让各团队之间的人员做定期轮换也是非常必要的，这样每个地方的成员都能与其他地方的团队成员建立起一些私人交情。
1.4K30发布于 2019-09-28 - 来自专栏kl的专栏
jenkins pipeline实现持续集成持续交付
git clone（拉源码），maven build（构建），deploy jar（上传jia包）的基础上，在新增两个步骤start app（启动服务），check health（检查应用健康），真正实现持续交付 ，持续集成。 org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onNewInstance(SandboxInterceptor.java:148) at org.kohsuke.groovy.sandbox.impl.Checker$3. 围绕持续集成ci/cd肯定还有很多很多的场景,欢迎在下方留言一起探讨。
1.4K30编辑于 2023-11-18
腾讯云开发者
Copyright © 2013 - 2026 Tencent Cloud. All Rights Reserved. 腾讯云 版权所有
深圳市腾讯计算机系统有限公司 ICP备案/许可证号：粤B2-20090059 
粤公网安备44030502008569号
腾讯云计算（北京）有限责任公司 京ICP证150476号 | 京ICP备11018762号