华为开发汇(Huawei Developers Gathering)简称“HDG”，旨在为广大开发者分享华为内部、合作伙伴以及社区成员的干货，营造一个自由、开放、分享的技术交流平台。是华为今年一个重要的技术交流活动，计划将在全国各个地区举办。
9月，HDG成都站如期举行，林帆是HDG成都站***一位发言的讲师，他作为ThoughtWorks高级DevOps技术顾问，带来的是《构建企业级私有云持续交付平台》的主题演讲，讲解了如何通过整合开源社区中的优秀软件，使其匹配企业级应用的场景。其中涉及的一些方案细节等都是***次在外部活动中进行展示。
现场实录如下：
我今天的话题主要有下面几个部分，首先我想简单过一下关于持续交付概念基本的价值，和它的主要内容。然后再说一说在企业级的应用当中能够使用开源的工具，做这种交付的话，哪些事情是可以做的，哪些事情是具有缺陷的。***一点是想用一些开源的工具做一个全流程的持续交付平台的话，我们应该怎么去做。
持续交付的概念到现在也有五六年的历史了，在座的多少都听过持续交付这个概念吧，大家半数以上都听过。持续交付，这本书是在2010年时候英文版就已经出来了，国内的中文版稍微晚一些。持续交付的想法是，我们始终将我们已经开发好的工具保持在一个可交付、可上线的状态上，当我们支持的人说这部分完成了，是没问题的，可以立马上线，这样就以最快的速度来实现这部分的功能价值，并且在***时间把我们的软件功能走到一个反馈，它是不是我们想要的。
到现在来说很多时候我们对软件交付周期比较有要求的企业，特别是互联网创业企业，对持续交付理念的追求度是比较高的。因为它一个主要的特点是，它从实践层面上去提出一些工具和方法，能够将这种快速迭代的方式实践落地。这些方法包括我们更加频繁的做交付，更加频繁的做周期反馈，相关情况的具化，主要是关于自动化的工具。通过这些持续交付的工具能够很好的帮助开发者，包括帮助团队去实现更好的交付流程的自动化，交付流程的打通。当流通出问题的时候，能够***时间把出问题的地方反馈出来，比如说代码出问题了，提交了一个有问题的功能之后，***时间进行自动化设置，这样可以最快的得到问题反馈，最快的把问题解决。
通过这种开源的工具，是不是能够真正的帮企业解决所有这个过程中所需要解决的问题呢，答案是不一定，这个要看我们实际团队的规模和我们团队对持续交付概念的诉求。如果是对一个比较小的团队来说的话，很多小团队是一个互联网团队，基本的交付***的诉求就是我能够多快的把这个软件，通过一个稳定可控的方式把它上线。因为对于这样企业来说的话，软件交付的速度不单单是软件的价值回馈的速度，更重要的它直接决定了一个产品，甚至是一个公司生与死的问题。像这样子的产品它主要帮助解决的是，我怎样去构建这样一条可视化的通路，我把代码编译之后，***时间对代码进行检查，***时间进行反馈，没有问题之后我会***时间把这个功能上线，给用户使用，得到用户的反馈。对于这种需求点的话，大部分的开源工具已经能够比较好的满足小团队、个人开发这样的一些需求。
当我们把产品放到一个更大的团队，对于一个企业级的用户来说，企业级的用户是比较大的，所以它的交付周期会比较长，它的交付团队是跨团队进行合作的。从任何一个点上都很难一眼看出所有团队的交付状况，在这种情况下我们需要很多的指标，来告诉我们这个项目当中的哪一个部门，哪一个部分的地方有问题。不像是我们很轻松的一眼望尽所有的上面有几百个路线，几百个项目，很大型的一个产品。这样的话我们会需要对这个产品提出很多指标性的诉求，从上层往下看的时候能清楚的看到整个产品交付的状态。这个指标就包括我们在代码提交之后，可以看某个子项目上面代码提交的频率，代码成功的比例，以及进行代码扫描，进行测试的时候，测试的够不够。进行代码扫描的时候，扫描出来的问题多不多。这些问题都可以反映出这个产品的质量是否会延迟交付，是否会有一些问题。同样的当我们把这个项目进行布置的时候，同样也可以获得很多，包括每个子产品部署的周期，这个子模块或者这个子项目是否匹配，是否会存在一些潜在的问题。这些东西都需要通过一些指标性的东西才能提供出来。除此以外，除了指标还有一方面就是我们需要很多的实践，就是更多的实践的东西，去配合这些沟通合作。比如我们需要一些统一的分制策略，怎么去管理我们代码的分解。怎么去通过一些文件的机制，去保证非常差的提交，不能够进入正常的运行，在做测试的时候，一旦有其中一个模块出现问题，会影响整个测试的结果。这个保证如果代码扫描出现非常严重的问题的时候，这个提交整个会部署。部署打包的时候我们也需要通过一些实践来保证它怎样***进行自动化，并且是一个比较统一的自动化的关系，去完成整个产品的部署，这样对于后续的运维和运营有比较大的收益。
所有这些事情不单单是一个单纯的工具能够解决的问题，可能需要一些国外的指标，国外的实践，来保证我们大型企业项目的交付过程。包括后面从正常运营到延迟需求的回馈，这部分已经超出了持续交付要解决的问题，但是我们确实也是从企业级交付的时候必须要做的一个部分。
刚刚提到的这些是说我们这些开源的持续交付工具，可能不能非常好的满足企业级需求当中所需要的这么多，包括有指标性的，包括有实践性的东西。
第二个问题是关于数据的集成，刚才说在企业的应用当中我们更需要关注一些指标性的东西。因为对小团队来说的话，可能我们***眼就能看到这个项目当中每一部分的状态是什么样的，是不是现在已经部署过了，这个我们都能计算出来。但是对于大型项目的时候，我们可能需要一些额外的数据进行支撑，这些数据的整合，对于开元的工具来说也是没有的。这些数据就包括过去的数据，包括我们做代码测试，做产品测试时候的测试数据，包括我们对项目进行部署的时候会有一个部署周期，两点要匹配模块之间的部署的API的性能。假设我做了hos相关的，一般从1.0到2.0之后会升级，是否会存在问题，这些问题是通过数据可以暴露出来的。但是对于开源组建来说的话，它对数据这块的集成是缺失的，这是第二个问题。
第三个问题，刚才说到对于小型团队来说的话，它的关注点主要在于交付，我们把这个软件开发出来之后，把代码提交，我用自动化工具，把所有的东西进行测试，测试没问题之后，把测试内容看一下，没问题就自动化的部署上线，这样就是一个非常流畅的过程。但是如果对于比较大型的企业级应用，需要对软件质量，对软件的一些部署流程做更多的控制。这时候我们需要去集成很多额外的第三方工具，帮我们完成这些事情。对于这种开源社区里面，现在其实有非常多的工具，能够把这一点点的，逐个逐个的绑定，我们不需要去重新做连接，我们需要把这些一个个的能够平衡起来，并且用户体验上有可能不一致，能够接入一些企业级的系统，有的可能是单独一个系统，需要一些账号，本身能够接入的一些东西，我们直接就接入了，没有问题。但是上面没有插件的话，我们还接入不进来，就有这些问题，这是第三个比较大的问题。
除此以外还有很多很多，当我们做比较大型的软件应用的时候，我们可能需要考虑它的软件高可用，是不是一个崩溃掉了，我们全部的平台都不可以用了，这样整个团队的研发进度一耽搁就不是钱的问题了。
现在除了刚才讲的开源的工具以外，我们还有很多企业级的持续交付的工具，比较常见的话像teamcity、bamboo这些比较常见的，一些比较老牌企业的话可能还会用过IBM的Bluemix，Cloudbees是一个企业级方案，这套方案我个人认为不是特别好。这些工具就是解决了一些开源工具里面存在的一些问题，特别是性能的问题。但是当我们去使用这些工具做一些web集成的时候，可能它里面已经内置一些我们常用东西的集成，但是有的东西是我们企业用过的，每个企业都会有一些特殊的东西，比如说资源审查的时候需要切入一些企业内部的东西，这时候你会发现这些企业级产品在解决开源产品问题的时候，也引入了更大的封闭性。如果我发现一个问题不能解决的话，它就真的不能解决。它是开源工具的话，可能有一些社区方案，社区会提供一些插件，你不用干活，你拿过来用就可以。当你使用企业级方案的时候，它这个支持没有。我们有一个想法是，如果我们现在想要选择企业级的平台，但是我们又想让它能够具有这个定制性，具有这个性能的话，我们能够通过一些开源的工具，组合起来，让这个工具变成一个平台，变成一个企业级的平台。
刚才王老师讲的就是集成了各种各样华为内部开发者工具的云，包括持续交付，包括代码的构建、打包、部署等等这一系列的平台。答案肯定是可以的，包括像现在华为应该也是使用了一些开源组建，没有必要把数据全部重新存，这样会造成很大的完全没有必要的消耗。如果要做这件事情的话可能会遇到什么问题，刚才讲到各种各样的问题。首先是性能问题，数据的集成问题，集成工具的问题，还有刚才提到的很多很多其他需要解决高可用、审计、权限、登录等等，这些都是需要去解决的，它确实是有这个麻烦。以及一点我们信息要考虑现在比较流行的现代化的部署方式，我们也把它作为一个方案考虑进去。
我们现在看要解决这些问题的话有什么比较简单的方式，或者是不会太费事的方式，把这个问题解决过去。首先说性能问题，由于大部分开源工具本身都不是为了这种大规模应用设计的，它本身是确定存在的，但是它的规模上来之后，就会出现这种响应速度慢，不可用的问题。我们要么去改原代码，把它变成高可用的。
刚才提到的第二个问题是数据的集成，数据集成很简单，所有的构建，所有的测试，所有的部署，都在平台上面做的，什么数据都有。但是从实际实践来说的话我们可能会有多种思路，怎么去算这个数据。***种最简单的，我们在代码里面写一个服务，每小时算一次，每天算一次，把报表算出来。这样实现非常简单，但是它的一个缺陷是，我们预定要算什么样的数据就算什么样的数据。它的数据算出来只是在你的数据库里面的，如果持续算的话，对于数据库来说的，这种大量计算的压力很大，真正来做的话肯定是提前算好，大家让我查谁就去查谁，提前做成一个表。第二个方式，我现在知道这两年大数据这一块的生态是非常多的，有很多这方面的高手，每个企业多少都会有一些做数据的人。我们也可以把这个数据接入到平台来，无非就是一些数据表，我们可以分析具体到每一个人，具体到每一个子团体的变化，***可能是一个比较邪恶的平台，讲出来就不行了。但是这个方式成本会比较高，它能够实现的是实时的预算，也能够提供一个基于这个数据深层次的挖掘，提供很多从外面很难看出来的一些存在的问题。
下面一个方式是我们在座其中一个尝试当中去做的方法，在数据库里面进行操作性是比较低的，但是我们可能通过一些专门做检索，专门做搜索的工具，去做做搜索。
第三个是平台集成，平台集成对于开源来说是最最友好的事情，开源为什么叫开源，我们现在有大量可用的东西，是社区其他人开发出来贡献出来的，我们可能只需要找到这个组建能够用的。但是这个集成，如果这些东西我们在这个环境里面***都是一个，都是来自一些开发者，你去用，这个相当于增加了开发者的学习困难，他需要知道每个工具里面怎么用，甚至他可能会对这个不满意。
这边一般来说推荐一个做法，在我们真正的项目沟通需要集成的平台之间做一个服务的索引，这样的好处主要是为了方便升级，在这个上面可以做很多的事情。现在这种做法是比较推荐的接入第三方工具的一个做法。
其他的话，刚才提到的还有我们考虑高可用，需要考虑操作审计，权限等问题。高可用刚才提到了如果本身这个开源工具设置上就是高可用，我们要去做到高可用的话，就必须代到源代码。我们现在有一个团队在做这个事情，但是这个事情并不是没有人都去尝试的，因为从成本上很划不来。如果说我们把每个项目都做了一个性能之后，我们系统本身做的是统一的，但是对于高可用的点，我们可以把它的，比如说每个(32：02)，和具体的项目进行对应。当我们出现故障的时候，可能是单个的项目发生了问题，快速的重启一个(32：17)，这样只要把故障在一定程度上进行隔离，不会把这个故障延伸。这样从使用的组织方式来避免这种故障发生，故障出问题了，我把它锁定在一个项目组里面，或者锁定在一个子项目组里面，把它做一个关联，这是我们的事。
单点登录的话，如果我们前端做一个界面，去屏蔽比较复杂的其他软件的话，前端尽可能的把细节都屏蔽掉，屏蔽不掉的时候，当它暴露集成系统的时候，尽可能实现它的维护。就是它能够不用(34：00%，或者如果不能单点登录的话，就要账号统一。构建产物管理主要是为了部署做准备的，就是每个构建出来的包我们需要把它管理起来，需要知道这些管理的包是不是一个。当我们去进行后续部署的时候，才知道是这一个包，这样就能够实现部署。这些功能确切要求我们知道去布哪个包，但是对于用户来说的话，如果让用户来选择哪个包是你要做回购，他是找不出来的，就需要平台进行管理，这样比较节约时间，得到构建的序号，能够追溯这个东西。***这个东西是测试报告管理，测试报告主要是提供数据，提供后面的报表，或者是提供一些跟指标相关东西的内容。
***一点是关于部署的逻辑化，这个逻辑化展开说的话会有很多，但是普遍上来说使用逻辑化的思路就在于，对于企业级的这种产品我们肯定不会单独的使用，会在一个集群上使用。
我今天讲的主要就是一个纯技术的东西，不涉及到任何产品，也不涉及推荐任何东西的使用。这边顺便说一下，这个大家要做的话成本会比较高，虽然是我们低成本的开元工具的组合，但是如果你想要用这套工具的话，可以考虑刚才王老师提到的平台划分。谢谢大家，大家有什么问题。
