．在金融行业落地都有哪些姿势
我们先看看我们对于的定义：
• 持续集成，我们通常定义为从代码提交到编译打包，再到的过程
• 中的持续交付，我们通常定义为从代码提交到的过程
• 但项目里，没有用做的项目，也可变相为从编译打包到的过程
• 中的持续部署，我们通常定义为从代码提交到最后生产部署的全过程
• 但项目中，有可能变通为从编译打包到生产部署的过程总结来看，项目结果不同，或者接入应用系统也有可能处于不同的阶段，这造成了，/的过程随项目实际情况会有些差异。
项目在售前、招标或前期阶段，我们通常看到是小圈里面的内容：
/、自动化部署及回滚、与现有云平台的接口、流程的图形化编排调度等，但这些只是的内核，真正去落地一个项目的时候，其实你会看到外面大圈的这些内容，换句话讲，需要梳理组织整个软件生产的全过程！
姿势一：小范围+，再全公司推广
先看看 的案例，美国第一资本金融公司，美国排名前十的银行。
痛点：
年当时， 的软件开发实践和很多传统做法没有什么不同：大量外包，瀑布模型，季度发布，手工流程，变更请求。在某次代码检查会上，大家发现一个测试失败是由于某个文件里的不配对造成的。按理说，这么小的问题改了再提交就可以了。但是：开发工作是由另外一家公司负责，他们需要发起漫长的变更请求；代码修改后的构建流程（编译、测试、部署等）就需要至少天时间。这个小小的问题让 的技术团队开始反思他们的构建流程，并决定从这里下手。他们从一个小的团队开始实践，最终把时间从天缩短到几分钟。于是，这个实践逐渐在 蔓延开来，所谓星星之火，可以燎原。
年的成绩：
. 代码提交频率：从之前的不固定到每天多次的提交
. 代码集成频率：从每月次到每分钟一次
. 部署流程：手工变成自动化
. 部署到和（性能）环境频率：从每月次到每天次
. 部署到生产环境频率：从每月或每个季度次到每个迭代次
. 单元测试覆盖：从没概念到>%
年的成绩：
. 发布到产品环境的频率：从每个迭代一次到每天至少次
. 自动发布的应用软件数量达个
. 一个应用软件每天最多可以发布次
总结在 的落地姿势：先小范围做全套，再全公司大范围推广。
某寿险也是用的姿势一：他们是与基于 的微服务体系架构一起引入的，原来的想法只是对于这些新的微服务的应用适用，经过半年的时间之后，感觉还不错，就将逐步向传统单体架构的应用中去推广了。表中的系统是目前已经接入到中的系统。对接的代码库有//，介质库是，和的流程目前还是做手工触发，集成了和 单元测试，已包含测试和生产环境。组件包含：、脚本和 类，主要是全量的部署方式。
再总结一下：先小范围适用+，它是现在微服务架构适用的，取得经验积累之后，再大范围的推广。
姿势二：先，后
我们看看某银行的案例
在项目之初，某银行首先对软件生产的全流程进行了重新梳理和规划，其中包含流程、规范、度量体系和反馈机制。
在实践阶段分了三步走，研发层面的持续集成、运维层面的持续交付，最终打通研发和运维实现全流程。
从试点效果来看，单就自动化部署层面就比之前提高了-倍的效率。并且在软件质量和规范落实层面有了长足的进步。
再来一个以姿势二落地的，某国家政策性银行。
它的科技局下属研发中心和运行中心是分开的两个大部门，两个部门之间的纽带就是介质，但之前代码基线与生产环境的介质版本一直对不上，这对生产的修复、灾备部署都形成了很大困扰，所以它的研发中心引入是希望能形成统一的软件出口，能够将需求、代码、配置、介质控制在同一个基线上。所以他们做法是先做，并且并行配合的框架推广及的落地实施。但项目到了二期，它要引进建行建银科技的新核心，一是新核心短时间内的多版本在多个测试环境的部署，二是配合改造的个业务系统短时间内也会有很多版本要快速部署，进行集成测试，这就要求必须有自动化部署的工具才行。所以二期的重点就定在了，主要是配合核心及配套改造系统提测后的快速自动化部署。
所以总结一下，落地的第二个姿势：通常都是先由研发部门主导做，之后再推广，最后将两个流程串起来形成和的全流程。
姿势三：先，后
这是一家地方商业银行，也是因为今年要上新核心，并且伴随新核心，有个系统要重新建设，套系统要配套改造，行领导提出的目标：在月日上线时，利用做一键式的统一部署！所以项目一期的重点就放在了上，短期目标是满足多套系统的短期大量版本的提测后的自动化部署，最终目标，是要将++这些系统能够可视化的一键式部署。项目的二期重点，是在，配合诸多研发管理的落地实施，全流程的应用和推广以及自动化测试的接入。