软件工程之美
宝玉
Groupon资深工程师,微软最有价值专家
立即订阅
6741 人已学习
课程目录
已完结 54 讲
0/4登录后,你可以任选4讲全文学习。
课前必读 (3讲)
开篇词 | 你为什么应该学好软件工程?
免费
特别放送 | 从软件工程的角度解读任正非的新年公开信
学习攻略 | 怎样学好软件工程?
基础理论 (9讲)
01 | 到底应该怎样理解软件工程?
02 | 工程思维:把每件事都当作一个项目来推进
03 | 瀑布模型:像工厂流水线一样把软件开发分层化
04 | 瀑布模型之外,还有哪些开发模型?
05 | 敏捷开发到底是想解决什么问题?
06 | 大厂都在用哪些敏捷方法?(上)
07 | 大厂都在用哪些敏捷方法?(下)
08 | 怎样平衡软件质量与时间成本范围的关系?
“一问一答”第1期 | 30个软件开发常见问题解决策略
项目规划篇 (8讲)
09 | 为什么软件工程项目普遍不重视可行性分析?
10 | 如果你想技术转管理,先来试试管好一个项目
11 | 项目计划:代码未动,计划先行
12 | 流程和规范:红绿灯不是约束,而是用来提高效率
13 | 白天开会,加班写代码的节奏怎么破?
14 | 项目管理工具:一切管理问题,都应思考能否通过工具解决
15 | 风险管理:不能盲目乐观,凡事都应该有B计划
16 | 怎样才能写好项目文档?
需求分析篇 (5讲)
17 | 需求分析到底要分析什么?怎么分析?
18 | 原型设计:如何用最小的代价完成产品特性?
19 | 作为程序员,你应该有产品意识
20 | 如何应对让人头疼的需求变更问题?
“一问一答”第2期 | 30个软件开发常见问题解决策略
系统设计篇 (4讲)
21 | 架构设计:普通程序员也能实现复杂系统?
22 | 如何为项目做好技术选型?
23 | 架构师:不想当架构师的程序员不是好程序员
24 | 技术债务:是继续修修补补凑合着用,还是推翻重来?
开发编码篇 (7讲)
25 | 有哪些方法可以提高开发效率?
26 | 持续交付:如何做到随时发布新版本到生产环境?
27 | 软件工程师的核心竞争力是什么?(上)
28 | 软件工程师的核心竞争力是什么?(下)
29 | 自动化测试:如何把Bug杀死在摇篮里?
30 | 用好源代码管理工具,让你的协作更高效
“一问一答”第3期 | 18个软件开发常见问题解决策略
软件测试篇 (4讲)
31 | 软件测试要为产品质量负责吗?
32 | 软件测试:什么样的公司需要专职测试?
33 | 测试工具:为什么不应该通过QQ/微信/邮件报Bug?
34 | 账号密码泄漏成灾,应该怎样预防?
运行维护篇 (6讲)
35 | 版本发布:软件上线只是新的开始
36 | DevOps工程师到底要做什么事情?
37 | 遇到线上故障,你和高手的差距在哪里?
38 | 日志管理:如何借助工具快速发现和定位产品问题 ?
39 | 项目总结:做好项目复盘,把经验变成能力
“一问一答”第4期 | 14个软件开发常见问题解决策略
经典案例解析篇 (7讲)
40 | 最佳实践:小团队如何应用软件工程?
41 | 为什么程序员的业余项目大多都死了?
42 | 反面案例:盘点那些失败的软件项目
43 | 以VS Code为例,看大型开源项目是如何应用软件工程的?
44 | 微软、谷歌、阿里巴巴等大厂是怎样应用软件工程的?
45 | 从软件工程的角度看微服务、云计算、人工智能这些新技术
“一问一答”第5期(内含彩蛋) | 22个软件开发常见问题解决策略
结束语 (1讲)
结束语 | 万事皆项目,软件工程无处不在
软件工程之美
登录|注册

26 | 持续交付:如何做到随时发布新版本到生产环境?

宝玉 2019-04-27
你好,我是宝玉。到今天为止,持续交付已经成为一种公认的好的开发实践,越来越多的开发团队都已经应用持续交付,它通过自动化的方式,让你的代码在每一次提交后,都能自动化地走完编译、测试流程,完成后即可随时准备好部署发布。
持续交付如果细分,其实可以分成持续集成、持续交付和持续部署三个概念,这三个概念很相近,但又有所不同。
今天我将带你了解什么是持续集成、持续交付和持续部署?以及我们该如何用好它们,在项目中最大程度上发挥其效用。

集成、部署和交付的发展史

要想更好地理解并应用好持续集成、持续交付和持续部署,你需要了解它们的演变史。持续集成、持续交付和持续部署的历史还不算太长,但是集成、部署和交付却是伴随着软件工程一起发展的。

集成的发展演变

在多人软件项目开发的时候,每个人都会负责一部分功能模块的开发,集成指的就是每个人把自己开发的分支代码,合并到主干上,以便测试打包。
集成的原始阶段
早在瀑布开发的年代,在开发阶段,一般是不集成的。大家各自开发,等到开发阶段差不多快结束了,再一起提交代码到源代码管理工具,让代码集成在一起,再编译、部署发布到测试环境。
由于长时间都是在各自的开发环境运行,每次集成都是很痛苦的过程,会遇到各种问题,比如说编译无法通过、hard code 了开发环境地址、类库版本不一致、API 格式不一致等,通常要持续几天甚至几周才能逐步有一个相对稳定的版本。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《软件工程之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(10)

  • W.T
    老师,现在还有一种说法:提倡基于主分支开发,效率更高;而不是您提到的每人基于自己的分支开发完再合并回主分支。您怎么看待这个问题?

    作者回复: 我认为对于软件工程来说,很多问题,并不是只有唯一解,即使是最佳实践,也得看适用的场景和团队。

    无论是基于主干还是分支开发,有两点需要注意的:
    1. 就是一定要有一个稳定的分支,可以随时发布的那种,至于是叫master还是叫release并不重要。
    2. 合并之前要有代码审查和自动化测试(配合CI)。

    上面两点才是核心。

    2019-04-27
    5
  • 纯洁的憎恶
    持续集成,分支程序自动合并到主干程序。
    持续交付,在持续集成的基础上自动部署测试环境。
    持续发布,在持续交付的基础上自动部署生产环境。

    作者回复: 💯

    2019-04-29
    3
  • alva_xu
    cicd中有一个基础能力就是自动化测试。老师能否详细介绍一下自动化测试的不同场景、采用的工具流程、测试条件的准备,输入输出等?谢谢

    作者回复: 会的,第29篇就是自动化测试。

    另外你说的场景是不是指的单元测试、集成测试、端对端测试这样的场景?

    2019-04-29
    3
  • Charles
    从老师前面的文章以及这篇文章深刻认识到单元测试和自动化测试是我们项目的薄弱点

    其它的持续集成git和git flow、根据环境自动打包、生产环境也自动化部署这个由于第三方服务的便利性已经在实践了,效果很好出错率降低很多,而且一旦有问题还能快速会滚

    作者回复: 👍赞,从工具入手,从持续集成、自动化测试、代码审查这些好的开发实践开始,就能很快起到改进的效果。然后再是优化开发流程,把好的实践工具化流程化。最后再考虑去优化开发模型,去优化开发过程中的各个环节。

    2019-04-27
    2
  • 会飞的水箭龟
    我是从事自动化设备的软件开发的的,我一直很困惑的是自动化设备的软件自动化测试应该如何做?主要有两个困惑:第一,像互联网开发的软件,很多输入通过写测试用例,直接让自动测试工具去测,但自动化设备却不一样,很多时候需要传感器的数据(当然可以模拟),而传感器检测到的数据也是变化很大的(如摄像头),无法一一列出测试用例;第二,测试结果一般是直接看设备的运行情况而不是看是否自动测试通过,无法量化结果。
    对于上述问题,宝玉老师有没有什么好的建议?

    作者回复: 既然你能模拟数据,那么就可以自动化测试了,参考《29 | 自动化测试:如何把Bug杀死在摇篮里?》中的内容。
    一个完整的自动化测试要包括三个部分的测试:验证功能是不是正确、覆盖边界条件、异常和错误处理。

    你不需要覆盖所有的测试,你只要覆盖上面三部分就可以。

    剩下的你就是要解决如何校验测试结果的问题了。我对硬件所知有限,不知道是否有方法可以做到。你也可以考虑是否有间接的方式,比如说一个测试用例完成,通过软件触发拍一张照片,然后你集中确认这些照片,那么还是可以减少很多劳动。

    2019-10-18
    1
  • 小老鼠
    最新统计,中国软件公司2019年上半年自动化测试真正搭起来仅占5%,这种情况下如何普级CICD?

    作者回复: 先不用管其他人其他公司如何,先从自己做起,从手头的项目做起🤝

    2019-09-21
    1
  • hua168
    如果一个项目有5个开发做,持续集成怎么保证不乱?
    比如开发A刚刚修复的bug1,开发B把自己修复的bug2上传,之前的代码bug1没修复
    怎么搞?
    如果采用分支怎么合并?如果是直接更新master分支,那A不是白搞了?

    难道这样一个QQ群,开发A更新的代码,然后到群里说一下他更新的代码,叫其他开发git一个新的版本,然后基于这个版本进行修改bug?

    作者回复: 要注意是“合并”而不是“覆盖”

    比如说bug1涉及file1和file3的修改,那么开发A合并的时候只合并file1和file3。
    等到开发B修复了bug2,修改了file1和file2,file2直接合并,file1需要手动去修复合并冲突才能合并。

    每个人开发之前,都会从master获取最新版本,合并的时候,如果出现冲突,要先解决冲突才能合并进去。

    这些其实你应该自己去动手试试,会体会更深刻。

    2019-04-29
    1
  • hua168
    集成指的就是每个人把自己开发的分支代码,合并到主干上,以便测试打包。
    集成包括编译,运行,测试吗?

    持续集成=不断的进行集成操作?

    作者回复: 广义的集成是包含代码合并、编译、自动测试还有部署的。

    持续集成就是频繁的集成,例如每次提交代码都会集成,或者可以手动触发集成。

    2019-04-29
    1
  • dancer
    在微服务架构中,一个服务在测试环境的交付验证,往往还依赖于其他相关服务的新版本,导致新的feature很难独立的交付。请问老师,对于这种情况,有什么好的方法嘛?

    作者回复: 我觉得对于大部分时候,微服务之间应该是独立的,而不是依赖过于紧密,如果每一个新功能都会这样,那架构设计一定是有问题的,需要重新思考服务划分的合理性。

    但你需要有更多上线或者场景我才能针对性提出一些意见。

    对于有一些确实需要跨服务合作的大Feature这样也是正常的,就是需要一起协作,实现商量好通信协议,分头开发,再联调。

    2019-04-27
    1
  • alva_xu
    是的
    2019-04-29
收起评论
10
返回
顶部