本文转自微信公众号：DevOps咖啡馆 ； 下面为原文。

本文总结自Topo Pal于DOES15和DOES16的两个演讲《Bankingon Innovation & DevOps》以及《DevOps at Capital One: Focusing onPipeline and Measurement》

背景：Capital One（Capital One Financial Corp. ）是一家以投融资及基金管理为基础，集国际贸易、项目开发、投资银行业务为一体的多元化国际企业集团，总部位于美国特拉华州。

DevOps缘起：说起来这家成立只有20多年历史的银行在美国银行业里绝对算是个初创公司。公司一直都是以信息技术的采用见长，尤其是在数据分析、数据科学方面，但在软件开发方面之前都是采用外包的方式，并没有被定义成公司的核心业务。但银行业的数字化趋势，尤其是手机上的交易量已经远远超越了传统的交易渠道，促使他们开始把软件开发作为重中之重来对待。

创始人兼CEO RichFairbank能有如此深刻的认识很不容易

痛点：Capital One的DevOps之旅开始于2014年。当时，CapitalOne的软件开发实践和很多传统做法没有什么不同：大量外包，瀑布模型，季度发布，手工流程，变更请求。和上一期介绍的KeyBank从大事故而痛定思痛不同，他们是从一个小问题触发反思的。在某次代码检查会上，大家发现一个测试失败是由于某个XML文件里的tag不配备造成的。按理说，这么小的问题改了再提交就可以了。但是因为开发工作是由另外一家公司负责，他们需要发起变更请求，而且代码修改后的构建流程（编译、测试、部署等）就需要至少2天时间。这个小小的问题让CapitalOne的技术团队开始反思他们的构建流程，并决定从这里下手。

他们从一个小的团队开始优化构建流程（其实就是最小版本的Pipeline – 部署流水线），最终把时间从2天缩短到几分钟。于是，这个实践逐渐在CapitalOne蔓延开来，所谓星星之火，可以燎原。

尝到甜头之后，Capital One开始认真思索企业级的DevOps策略。可以看到，这一企业DevOps框架涵盖了从业务、到开发、到运维，最后加入了信息安全策略（对金融业安全监管尤其重要）。他们称其为DevOpsSec。

Capital One的企业DevOps框架

Capital One继续改善流水线的效率。除了开发测试这些，要想真正打通流水线，还需要搞定环境/服务器的搭建和管理。之前新建一个服务器要走完62个步骤，耗时60天，开发团队的抱怨很大。CapitalOne决定：直接上云！2015年的时候还是只有开发和测试等环境在云上，到了2016年，生产环境也放云上了。

Capital One的流水线（Pipeline）

另外，Capital One发现开源真的是宝。他们不止大量的采用开源工具（”Open Source First”,非开源系统会被严格审查），还积极加入开源社区。他们发现开源自己的工具可以让代码质量大大提高，并且大大促进了持续体验和持续学习的DevOps文化。

Capital One的开源第一（OpenSource First）策略

从2015年的DOSE大会上Topo的介绍，已经可以看到他们经过1年多的努力，已经做到了非常好的成果：

·     代码提交频率：从之前的随意到每天100多次的提交

·     集成频率：从每月1次到每15分钟一次

·     部署流程：手工变自动化

·     部署到QA和和Perf（性能）环境频率：从每月1次每天4次

·     部署到生产环境频率：从每月或每个季度1次到到每个迭代1次

·     单元测试覆盖了：从没概念到~90%

2016年继续改进流水线，已经能够做到：

·     发布到产品环境的频率：从每个Spring一次到每天1+次

·     自动发布的应用软件数量达20个

·     一个应用软件每天最大的发布次数达到34次

所以说DevOps的转型可以很快。现在，Capital One很骄傲地宣称自已有了和两年前完全不同的DNA：自己开发软件，所有环境都在云上，微服务，开源，DevOpsSec和持续交付。确实，CapitalOne在DevOps之路上是远远超越了很多同业的。尤其这一旅程也只用了2年多时间。

Capital One认为转型有三个关键中的关键：

·     外包转向自建开发团队（外包公司要努力了）

·     功能团队转成产品团队（一个产品团队就像一个多兵种的行动小组）

·     不再区分Dev，Ops，QA，还是RM（Release  Management），大家在写代码，都是Engineer

转型的的三个最关键策略/实践

总结下Capital One的转型之路:

Capital One的DevOps之旅时间表

从这两个演讲中笔者听到最多的就是流水线，开源和安全。尤其是流水线，Capital One的DevOps转型其实就是围绕着这个核心进行的，不断优化，持续改进，在整个公司推广。

Capital One总结了要做到真正的流水线，以下15个特性是必须的:

1.    版本控制

2.    最优的分支策略

3.    代码静态扫描

4.    80%以上的单元测试覆盖率

5.    漏洞（Vulnerability）扫描

6.    开源工具扫描

7.    制品（Artifact）版本控制

8.    环境自动创建

9.    不可变服务器（Immutable Server ）

10.  集成测试

11.  性能测试

12.  每次提交都触发：构建、部署和自动化测试

13.  自动化变更请求

14.  零停机发布

15.  功能开关

读者可以对照检验自己项目的Pipeline是否达标。

我们拭目以待Capital One在2017年在DevOps的转型之旅上会给大家带来什么样的惊喜。

原创：DevOps咖啡馆

本文转自微信公众号：DevOps咖啡馆 ； 下面为原文。

本文总结自Topo Pal于DOES15和DOES16的两个演讲《Bankingon Innovation & DevOps》以及《DevOps at Capital One: Focusing onPipeline and Measurement》

背景：Capital One（Capital One Financial Corp. ）是一家以投融资及基金管理为基础，集国际贸易、项目开发、投资银行业务为一体的多元化国际企业集团，总部位于美国特拉华州。

DevOps缘起：说起来这家成立只有20多年历史的银行在美国银行业里绝对算是个初创公司。公司一直都是以信息技术的采用见长，尤其是在数据分析、数据科学方面，但在软件开发方面之前都是采用外包的方式，并没有被定义成公司的核心业务。但银行业的数字化趋势，尤其是手机上的交易量已经远远超越了传统的交易渠道，促使他们开始把软件开发作为重中之重来对待。

创始人兼CEO RichFairbank能有如此深刻的认识很不容易

痛点：Capital One的DevOps之旅开始于2014年。当时，CapitalOne的软件开发实践和很多传统做法没有什么不同：大量外包，瀑布模型，季度发布，手工流程，变更请求。和上一期介绍的KeyBank从大事故而痛定思痛不同，他们是从一个小问题触发反思的。在某次代码检查会上，大家发现一个测试失败是由于某个XML文件里的tag不配备造成的。按理说，这么小的问题改了再提交就可以了。但是因为开发工作是由另外一家公司负责，他们需要发起变更请求，而且代码修改后的构建流程（编译、测试、部署等）就需要至少2天时间。这个小小的问题让CapitalOne的技术团队开始反思他们的构建流程，并决定从这里下手。

他们从一个小的团队开始优化构建流程（其实就是最小版本的Pipeline – 部署流水线），最终把时间从2天缩短到几分钟。于是，这个实践逐渐在CapitalOne蔓延开来，所谓星星之火，可以燎原。

尝到甜头之后，Capital One开始认真思索企业级的DevOps策略。可以看到，这一企业DevOps框架涵盖了从业务、到开发、到运维，最后加入了信息安全策略（对金融业安全监管尤其重要）。他们称其为DevOpsSec。

Capital One的企业DevOps框架

Capital One继续改善流水线的效率。除了开发测试这些，要想真正打通流水线，还需要搞定环境/服务器的搭建和管理。之前新建一个服务器要走完62个步骤，耗时60天，开发团队的抱怨很大。CapitalOne决定：直接上云！2015年的时候还是只有开发和测试等环境在云上，到了2016年，生产环境也放云上了。

Capital One的流水线（Pipeline）

另外，Capital One发现开源真的是宝。他们不止大量的采用开源工具（”Open Source First”,非开源系统会被严格审查），还积极加入开源社区。他们发现开源自己的工具可以让代码质量大大提高，并且大大促进了持续体验和持续学习的DevOps文化。

Capital One的开源第一（OpenSource First）策略

从2015年的DOSE大会上Topo的介绍，已经可以看到他们经过1年多的努力，已经做到了非常好的成果：

·     代码提交频率：从之前的随意到每天100多次的提交

·     集成频率：从每月1次到每15分钟一次

·     部署流程：手工变自动化

·     部署到QA和和Perf（性能）环境频率：从每月1次每天4次

·     部署到生产环境频率：从每月或每个季度1次到到每个迭代1次

·     单元测试覆盖了：从没概念到~90%

2016年继续改进流水线，已经能够做到：

·     发布到产品环境的频率：从每个Spring一次到每天1+次

·     自动发布的应用软件数量达20个

·     一个应用软件每天最大的发布次数达到34次

所以说DevOps的转型可以很快。现在，Capital One很骄傲地宣称自已有了和两年前完全不同的DNA：自己开发软件，所有环境都在云上，微服务，开源，DevOpsSec和持续交付。确实，CapitalOne在DevOps之路上是远远超越了很多同业的。尤其这一旅程也只用了2年多时间。

Capital One认为转型有三个关键中的关键：

·     外包转向自建开发团队（外包公司要努力了）

·     功能团队转成产品团队（一个产品团队就像一个多兵种的行动小组）

·     不再区分Dev，Ops，QA，还是RM（Release  Management），大家在写代码，都是Engineer

转型的的三个最关键策略/实践

总结下Capital One的转型之路:

Capital One的DevOps之旅时间表

从这两个演讲中笔者听到最多的就是流水线，开源和安全。尤其是流水线，Capital One的DevOps转型其实就是围绕着这个核心进行的，不断优化，持续改进，在整个公司推广。

Capital One总结了要做到真正的流水线，以下15个特性是必须的:

1.    版本控制

2.    最优的分支策略

3.    代码静态扫描

4.    80%以上的单元测试覆盖率

5.    漏洞（Vulnerability）扫描

6.    开源工具扫描

7.    制品（Artifact）版本控制

8.    环境自动创建

9.    不可变服务器（Immutable Server ）

10.  集成测试

11.  性能测试

12.  每次提交都触发：构建、部署和自动化测试

13.  自动化变更请求

14.  零停机发布

15.  功能开关

读者可以对照检验自己项目的Pipeline是否达标。

我们拭目以待Capital One在2017年在DevOps的转型之旅上会给大家带来什么样的惊喜。

原创：DevOps咖啡馆