持续交付36讲
王潇俊
携程系统研发部总监
立即订阅
7125 人已学习
课程目录
已完结 41 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 量身定制你的持续交付体系
免费
基本概念 (3讲)
01 | 持续交付到底有什么价值?
02 | 影响持续交付的因素有哪些?
03 | 持续交付和DevOps是一对好基友
配置管理 (4讲)
04 | 一切的源头,代码分支策略的选择
05 | 手把手教你依赖管理
06 | 代码回滚,你真的理解吗?
07 |  “两个披萨”团队的代码管理实际案例
环境管理 (6讲)
08 | 测试环境要多少?从现实需求说起
09 | 测试环境要多少?从成本与效率说起
10 | 让环境自己说话,论环境自描述的重要性
11 | “配置”是把双刃剑,带你了解各种配置方法
12 | 极限挑战,如何做到分钟级搭建环境?
13 | 容器技术真的是环境管理的救星吗?
构建集成 (5讲)
14 | 如何做到构建的提速,再提速!
15 | 构建检测,无规矩不成方圆
16 | 构建资源的弹性伸缩
17 | 容器镜像构建的那些事儿
18 | 如何做好容器镜像的个性化及合规检查?
发布及监控 (6讲)
19 | 发布是持续交付的最后一公里
20 | Immutable!任何变更都需要发布
21 | 发布系统一定要注意用户体验
22 | 发布系统的核心架构和功能设计
23 | 业务及系统架构对发布的影响
24 | 如何利用监控保障发布质量?
测试管理 (3讲)
25 | 代码静态检查实践
26 | 越来越重要的破坏性测试
27 | 利用Mock与回放技术助力自动化回归
持续交付平台化 (3讲)
28 | 持续交付为什么要平台化设计?
29 | 计算资源也是交付的内容
30 | 持续交付中有哪些宝贵数据?
持续交付移动App (3讲)
31 | 了解移动App的持续交付生命周期
32 | 细谈移动APP的交付流水线(pipeline)
33 | 进阶,如何进一步提升移动APP的交付效率?
实践案例 (4讲)
34 | 快速构建持续交付系统(一):需求分析
35 | 快速构建持续交付系统(二):GitLab 解决代码管理问题
36 | 快速构建持续交付系统(三):Jenkins 解决集成打包问题
37 | 快速构建持续交付系统(四):Ansible 解决自动部署问题
特别放送 (2讲)
持续交付专栏特别放送 | 答疑解惑
持续交付专栏特别放送 | 高效学习指南
结束语 (1讲)
结束语 | 越痛苦的事,越要经常做
持续交付36讲
登录|注册

16 | 构建资源的弹性伸缩

王潇俊 2018-08-09
在前面的文章中,我已经介绍了构建在整个持续交付过程中扮演的重要角色,并且详细讨论了依赖管理和构建检测等方面的内容。在这篇文章中,我将带你搭建一套高可用、高性能的构建系统。

持续集成工具

目前市面上已经有很多持续集成工具了,它们已经替我们解决了很多实际问题,所以我们也就没有必要去再重复造轮子了。这些持续集成工具,最流行的应属 Travis CI、Circle CI、Jenkins CI 这三种。
第一,Travis CI
Travis CI 是基于 GitHub 的 CI 托管解决方案之一,由于和 GitHub 的紧密集成,在开源项目中被广泛使用。
Travis CI 的构建,主要通过 .travis.yml 文件进行配置。这个 .travis.yml 文件描述了构建时所要执行的所有步骤。
另外,Travis CI 可以支持市面上绝大多数的编程语言。但是,因为 Travis 只支持 GitHub,而不支持其他代码托管服务,所以官方建议在使用前需要先具备以下几个条件:
能登录到 GitHub;
对托管在 GitHub 上的项目有管理员权限;
项目中有可运行的代码;
有可以工作的编译和测试脚本。
Travis CI 的收费策略是,对公共仓库免费,对私有仓库收费。
第二,CircleCI
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《持续交付36讲》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • 日拱一卒
    请教几个和组织结构相关的问题,可能和技术关系不大。
    1. DevOps需要作为一个横跨多个部门的独立部门存在吗?如何统一不同部门之间不同的开发规范?
    2. DevOps需要在公司层面针对所有项目进行统一管理吗?
    3. DevOps有价值,持续交付也有价值,但是涉及到不同的部门时,不同的部门可能有不同的诉求,如何平衡所有的利益?
    2019-09-15
  • 日拱一卒
    不是很理解构建环境容器化的含义。
    从持续交付的角度来说,我们有Jenkins来从GitHub获取代码,有Maven或者其他工具来打包,有Dockerfile来构建镜像,有私有docker registry来管理镜像,有Kubernetes来管理容器实例。我理解这就是一个闭环了。
    2019-09-15
    1
  • 董永刚
    请问如何能够实时获取到jenkins的构建数量呢,
    2019-01-23
  • 小雨
    使用了GitLab runner ,编译部分已经完成,正在进行线上docker,目前无法大批量转入k8s,只能使用docker swarm,资源调度还有些距离,毕竟现在只有两台机器,推动难度很大,只能将新的推荐和ai业务进行容器化。原先的php业务耦合太严重。

    作者回复: 一步步走稳,解耦是架构永远追求的目标

    2018-08-11
  • 九脉一谷
    我们现在个别的项目在使用jenkins的流水线,为了实现持续部署,开发了一套内部管理平台依靠jenkins提供的接口,实现了流水线的执行过程的监控,自行开发了环境资源管理模块,自动化测试模块,最终通过docker发布。将整个过程都在管理平台统一跟踪监控。我想问一下作者,我们现在的产品线项目非常多,只有个别的项目加入了jenkins,那现在除了让各个项目组都加入pipeline,还有没有其他比较好的方式能实现对整个从开发人员提交代码后,接下来的走查,单元测试,环境部署,自动化测试等等这些全周期部署过程都能依靠平台统一监控各个过程。谢谢!!

    作者回复: 监控肯定不是最终的目的,提高研发效率才是,所以,不管是标准化,还是自动化,以提高效率为目标,解决实际问题,就比较容易被项目组所接受

    2018-08-10
  • 吃饱了晒太阳
    jenkins ci和现在最新版本的gitlab自带的ci功能有何区别呢,哪一个更适合使用呢,最近在公司用的是用的自带的,想了解下是否需要切换,还望给点意见

    作者回复: 本质上都是任务驱动管理,如果已经很熟悉gitlab那就用它的ci,Jenkins更多了不同插件的支持,如果你有更丰富的需求,不如自动化测试,部署等等,Jenkins就更适合

    2018-08-09
  • 禾子先生
    jenkins的slave扩展问题,我也是通过容器的方式,master使用swarm插件,每个开发者可以在自己的机器上启动slave镜像,避免资源不足和自己构建的需求。看到作者提供思路和方案,很受启发,谢谢。
    2018-08-09
  • 刘京城
    老师,请问你有研究过teamcity吗?我大致在网上查了下,说它开箱即用更容易些,但高可用和弹性伸缩不知道是否支持

    作者回复: 没有特别去研究这个,但是我写的那个ha方案是通用的,无论构建引擎用的是什么,甚至混用都可以的

    2018-08-09
收起评论
8
返回
顶部