展开

关键词

持续交付2.0:云原生持续交付

持续交付》提出了一系列贯穿整个软件交付生命周期的最佳实践。但它成书的年代(2010年)云计算尚未得到广泛应用,尤其在软件开发过程中的应用非常有限。 如果站在今天的技术水平和对云计算的理解水平基础上回顾《持续交付》的内容,我们有可能提出一组全新的、原生于云环境的持续交付实践。 ? 对于这些反模式,《持续交付》提出的解决办法是“将几乎所有事情自动化”。 《持续交付》中提倡整个部署流水线“只生成一次二进制包”,并且在各个验证步骤之间传递二进制包。 ---- 持续集成 尽管《持续交付》说“选择并安装好持续集成工具之后,只要再花几分钟的时间配置一下就可以工作了”,但实际上很少有哪个项目的持续集成实施会如此顺利。

1K50

3.2.2 持续交付

1.聊聊“持续集成、持续交付持续部署” 在做持续交付项目中,我们经常会遇到持续集成、持续交付持续部署三个词,不同的人对这些词的理解有所不同。 比方说,运维可能容易将持续交付理解为程序自动化分发,重点解决程序向多台主机的下发的自动化,或将持续交付做成运维内部的独立工具,这与“持续”关注的完整流畅的流水线、“交付”关注的用户价值交付有所不符。 “持续集成、持续交付持续部署”这三个概念都有“持续”两个字,单从“持续”两个字,我觉得强调软件交付流水线前后环节之间的连续性、自动化、质量内建、精益管理。 持续交付的边界有两种观点,一种是持续交付介于持续集成与持续部署之间,强调软件一直处于可交付的能力;另一种是持续交付包括了部署。 2.从IT价值看持续交付 1)DevOps与SRE、持续交付 关于价值我在前面提到过数字化转型下的运维价值与运维角色的变化,所以思考持续交付价值,先看看持续交付与DevOps、SRE的关系。

30410
  • 广告
    关闭

    90+款云产品免费体验

    提供包括云服务器,云数据库在内的90+款云计算产品。打造一站式的云产品试用服务,助力开发者和企业零门槛上云。

  • 您找到你想要的搜索结果了吗?
    是的
    没有找到

    【翻译】持续交付 VS 持续部署

    (中文版)在我和 Dave 出版《持续交付》一书之前一年多就发表了。 我们决定把这本书叫做《持续交付》有几个原因。首先,有一个有点学究的事实是:部署并不意味着发布。就像我们在书中说的那样,你可以持续部署到 UAT 环境——这不是什么太大的问题。 尽管持续部署意味着持续交付,但反之并不成立。持续交付是把发布计划的决策权交给业务,而不是 IT。 如果你正在使用看板并且想要进行持续交付,直到故事发布给用户之前,这个故事都没有发挥作用。 然而,向用户发布每次成功的构建并不总是有意义的。 那么你什么时候可以说你在做持续交付呢? 我想说的是,如果你认为这是为客户提供价值的最佳方式,那么你可以切换到持续部署。特别是,如果你无法保证向用户每次发布一个成功的构建。

    7010

    持续交付-Jenkinsfile 语法

    实现 Pipeline 功能的脚本语言叫做 Jenkinsfile,由 Groovy 语言实现。Jenkinsfile 一般是放在项目根目录,随项目一起受源代码...

    7000

    持续交付的好处

    你很容易与你的团队、老板和竞争对手分享;我们都可以从更快、更安全地交付软件中受益。 小贴士:把它放在某人的办公桌上作为一个节日惊喜,也许我们一起可以让2021年更好。 ? 我谨代表持续交付基金会祝你和你的亲人有一个安全快乐的假期。

    24630

    读《持续交付2.0》

    几年前看过《持续交付(发布可靠软件的系统方法)》,感触不是很深,最近看了这本书的译者乔梁编写的《持续交付2.0》,结合工作中的种种,又有一种相见恨晚的感觉。 全书围绕着双环模型展开,介绍了持续交付,快速实现客户业务价值的一系列的方法论和实践工具。本文将结合实际工作中遇到的问题来谈谈这些方法论和工具。 双环模型 ? 工具 持续交付在实践过程中离不开自动化工具,大体可以分为自动化构建和自动化测试。 自动化测试 自动化测试大体可以分为单元测试和端到端测试,单元测试对开发人员的要求比较高,要保证持续交付高质量的产品,单元测试非常重要,我们现在也在规划和完善。 总结 持续集成2.0这本书中有很多的干货,本文我只是找了几个我认为比较重要的点进行了描述,总之就一个目的,我们要快速地、正确地、高质量地把任务完成,并交付客户。

    82030

    持续交付Jenkins安装

    1.下载并运行 Jenkins 下载 Jenkins. http://mirrors.jenkins.io/war-stable/latest/jenkins....

    15230

    持续交付-Pipeline入门

    Pipeline 是一组插件,让 Jenkins 可以实现持续交付管道的落地和实施。持续交付管道(CD Pipeline)是将软件从版本控制阶段到交付给用户或客户的完整过程的自动化表现。

    8450

    docker----CD(持续交付持续部署)

    二、CD(持续交付持续部署) 2.1 CD介绍和Jenkins安装 代码在经过测试人员的专业测试后,需要经代码打标签,将代码发布到真正的生产环境。

    25471

    DevOps和持续交付

    DevOps的另一个核心目标是自动化和持续交付。简单来说,自动化一切可重复的乏味的工作,把更多时间留给人与人之间的交流,这才能产生真实的价值。 多快才算快? DevOps化的转变必须要快。 这也是持续交付运动的思路。 就像敏捷的很多东西一样,DevOps和持续交付虽然有许多概念名称不同,但是它们都有着相同的含义。它们只不过是一枚硬币的正反面而已,在概念上并没有什么争议。 下面是一些敏捷周期可以从DevOps获益的例子: DevOps工程师维护的部署系统,让Scrum周期最后的交付更快、更有效。而交付每2到4周就会周期性地发生。 一旦代码提交到代码库,取决于变更集的大小,一个设计良好的持续交付流水线大约只需要几分钟就可以把提交的代码部署到生产环境。 DevOps和持续交付认为我们交付到生产环境的变更集应该小而频繁,乍一看,ITIL的观点似乎与之相反。然而这并不是事实。

    31410

    常识三持续集成、持续交付持续部署

    概念 假如把开发工作流程分为以下几个阶段: 编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署 ? 正如你在上图中看到,「持续集成(Continuous Integration)」、「持续交付(Continuous Delivery)」和「持续部署(Continuous Deployment)」有着不同的软件自动化交付周期 「持续交付(Continuous Delivery)」 持续交付持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。 「持续部署(Continuous Deployment)」 持续部署则是在持续交付的基础上,把部署到生产环境的过程自动化。 ? 三者关系 持续交付持续部署 将持续集成扩充到部署到生产环境就是持续交付持续部署的概念,二者的区别 ? 手动与自动的区别 CI步骤 ?

    30550

    持续测试、持续集成、持续交付持续部署和DevOps

    团队透明度和问责制增加 提高测试可靠性,减少积压,提高最终产品质量给客户 持续测试、持续交付和 DevOps 持续交付的角色从持续集成结束的地方开始。 持续交付仅仅意味着在任何时间点不断地将代码移动到生产环境中,这只能通过对代码的持续测试来实现。它涉及分小阶段将构建交付到生产环境,以便在最终发布之前随时进行彻底的验证和测试。 DevOps鼓励参与产品开发和交付的团队之间进行沟通协调。除了生产之外,大多数团队还在开发和测试环境中工作。持续交付确保代码自动推送给他们。 为什么持续交付在DevOps中很重要? 需要更少的代码更改,使发布高效且可重用 确保可靠和更快的软件交付 提供更好的客户满意度 有效的持续交付流程提高了开发投资回报率 可靠的价值链绩效 持续测试、持续部署和 DevOps 持续部署是另一种软件发布策略

    31530

    持续交付-Blue Ocean 应用

    Blue Ocean 特性: 流水线编辑器:用于创建贯穿始终的持续交付流水线,是一种直观并可视化的流水线编辑器。 流水线的可视化:对流水线的可视化表示,提高了全企业范围内持续交付过程的清晰度。 流水线的诊断:即刻定位自动化问题,无需持续扫描日志或关注多个屏幕。 个性化仪表盘:用户可以自定义仪表盘,只显示与自身相关的流水线。 Tests 视图查看测试运行结果 单测结果展示 图片 Blue Ocean为开发人员提供了更具乐趣的 Jenkins 使用方式,从基础开始构建,实现了一种全新的、现代风格的用户界面,有助于任何规模的团队实现持续交付

    5700

    四要素落地持续交付

    一、什么是持续交付 持续交付(Continuous delivery,缩写为 CD),是一种软件工程方法,让软件产品的产出过程在一个短周期内完成,以保证软件可以稳定、持续的保持在随时可以发布的状况。 二、持续交付的价值 其最大的显性价值是,在实施持续交付后,能够做到在保证交付质量的前提下,加快交付速度,从而更快地得到市场反馈,推动产品的商业价值的实现。 在互联网应用盛行、速度为王的几天,持续交付的价值更被突显出来。持续交付的能力,已成为评定一家互联网公司研发能力的重要指标。 三、持续交付的落地 了解了持续交付的价值以后,我们再看持续交付在我们团队的具体推进实践。坦诚地说,在任何一个团队推行持续交付都不是易事。 四、持续交付四要素 从代码提交开始,我们可以把整个持续交付归纳出四个关键要素:持续集成、自动化测试、自动化部署、流水线。下面分别从四个关键要素解读我们的持续交付平台。

    58030

    聊聊持续交付这点事儿

    持续交付指的是在短周期内完成软件产品,以保证软件保持在随时可以发布的状态。让每一个变更都经过一条自动化的检验流水线,来检查每一个变更的质量,通过就进入下一个阶段。其不是一种工具,而是一种实践! 持续交付的共识和管理机制如下: 不要阻塞开发人员,这是实现持续交付的本质理念 为每个团队指定构建负责人或者发布工程师:优化交付流水线,提升交付效率 项目状态应该对参与整个过程(包括构建、部署、测试和发布 文档自动化、自文档 接下来先说明实现持续交付的一些基础设施和准备工作,然后从本地开发和自动化构建/部署流水线两方面说明持续交付的具体实现。 除非有特殊情况 部署流水线中的数据管理 提交测试:快速运行,避免复杂的数据准备 验收测试:后续阶段可以复用 容量测试:为测试提供足够的输入数据,可以看做验收测试的重复利用 主干开发 主干开发的分支模式实现持续交付最好的模式 :持续交付流水线大屏显示 存储构建结果报告 只要有环节失败,就停止整个流水线!

    10320

    Docker下的持续交付

    在研发体系的交付下,更加期望的是编写代码完成后,能够进行自动化的环境部署和自动化测试的冒烟测试,这样就可以节省很多的人力成本的验证时间。 那么在这样的一个过程中,可以完全结合Docker的技术以及结合Jenkins的持续集成的思路,打造一个可持续交付的自动化测试验证的一个过程。 那么可以做一个初始化的处理,也就是前置的动作,在构建镜像前先停止之前的服务,然后删除原来的镜像,这样在后期每次更新代码后进行构建,就不会因为初始化这部分导致流水线失败,这样也就可以打造可持续交付的流水线的作业交付 python3 -m pytest -v test_springboot.py''' } } } } 结合如上的具体实现细节,就可以打造Docker下的持续交付的过程 ,也就实现了自动化部署和自动化测试的过程,这样的好处就是拥有很多的微服务也是无所谓的,也是可以使用该思想和具体的技术来打造可持续交付流水线。

    11320

    详解持续集成是什么 持续交付持续部署、流程

    Martin Fowler 说过,"持续集成并不能消除 Bug,而是让它们非常容易发现和改正。" 与持续集成相关的,还有两个概念,分别是持续交付持续部署。 ---- 二、持续交付 持续交付(Continuous delivery)指的是,频繁地将软件的新版本,交付给质量团队或者用户,以供评审。如果评审通过,代码就进入生产阶段。 持续交付可以看作持续集成的下一步。它强调的是,不管怎么更新,软件是随时随地可以交付的。 ---- 三、持续部署 持续部署(continuous deployment)是持续交付的下一步,指的是代码通过评审以后,自动部署到生产环境。 持续部署的目标是,代码在任何时刻都是可部署的,可以进入生产阶段。 持续部署的前提是能自动化完成测试、构建、部署等步骤。它与持续交付的区别,可以参考下图。 ?

    64520

    DevOps -测试内持续集成与持续交付

    持续交付CD 持续交付持续集成的基础上,将集成后的代码部署到更贴近真实运行环境的「类生产环境」(production-like environments)中。 持续交付优先于整个产品生命周期的软件部署,建立在高水平自动化持续集成之上。 持续交付框架分析 ? 持续交付的目的 持续交付的目标是让软件在短周期内产出,确保软件随时可以被可靠地发布,目标是持续产出可以可靠发布的软件。 我理解持续交付需要依赖于持续集成,在持续集成的过程中,通过了所有测试case并且可以正确发布的集成系统,就可以作为持续交付的结果。持续交付与DevOps的含义很相似。持续交付可以看作持续集成的下一步。 它强调的是,不管怎么更新,软件是随时随地可以交付的。 持续交付的优点 持续交付持续集成的优点非常相似: 快速发布。能够应对业务需求,并更快地实现软件价值。

    1K10

    持续集成、持续交付持续部署 的区别与关系

    持续集成 尽可能快的把不同开发人员修改的代码集成到一起,通常一天进行多次 需要结合自动化单元测试,每次集成都运行一整套单元测试 目标是尽快发现代码问题 持续交付 持续的把改动的代码交给预演环境 ,接受QA检查,确保此套代码是可以随时部署的 持续交付持续集成更进一步,持续集成是代码层面的测试,持续交付不仅把代码集成起来,还会把真实环境中需要的配置信息设置好,在预演环境中运行起来,进行整体业务逻辑检查 目标是保证代码处于可部署状态 持续部署 把所有通过测试的代码尽快部署到线上产品环境 持续部署是持续交付的更高阶段,它把处于可部署的代码自动发布到了产品环境,所以持续部署需要持续集成、持续交付的支撑 持续交付完成前4部分自动化 ? 持续集成实现全部自动化 ? 但也是很有难度的,例如产品规模很大,服务器数量多,拓扑关系复杂,而且可能需要蓝绿部署,部署工作本身就很繁重,这种情况下想实现从头到尾的全自动持续部署的确困难 如果不便实现持续部署,最好能实现持续交付

    57250

    扫码关注腾讯云开发者

    领取腾讯云代金券