DevOps - 持续集成

最近在担任公司部门的DevOps Champion的角色，一直觉得这个只是一个协调者的角色(而不是一个SME的角色)，我的工作大概就是将每个项目的devops工具收集一下，然后用图表的形式去体现大家用devops的工具情况，再就是分享一下好的devops实践. 在我们部门里，我自己也是一个tech leader的角色，也带着两个项目在身上，我的项目可以说是部门的number one了，我们有自动化构建，部署，和部分自动化测试，在我收集的过程当中，有几个项目也说自己也都做好了自动化构建和部署，我也知道他们并不是实行的很好，但我就是找不出个问题来，另我非常的困惑，　前几天和我们的管理教练聊了以后，另我豁然开朗，其实做好这个工作，并不只是一个协调者，我还要推动整个部门的devops前进，就像敏捷实践一样，要让我们的问题暴露出来,让他们理解什么是持续集成，激发他们自己做持续改进。

我们是金融行业，众所周知，金融IT业是走得比较慢的，DevOps这个主题太大了，我们今天来聊聊持续集成吧，我们要是把持续集成做好了，说devops做好了一半也不出奇。

以前说起持续集成，我眼中就只有三个东西，自动化构建，自动化部署和自动化测试，然后就没了。难道我有这三个东西还没有达到持续集成吗？说你没达到，一点也不出奇，下面听我慢慢道来。

来说说我眼中的持续集成是怎么样的. 

1. 是否能自定义自己的流水线？

我相信，每个团队可能都有自己的流水线，比如有些会有sonar在里面，有些会有smoketest,等等之类，但团队是否能根据自己的需求去自定义自己的流水线呢？

我们之前用的buildforge是不可以自定义流水线的，现在用的Jenkins公司也不给我们自己定义pipeline的，我们是用了一个Jenkins的build pipeline插件将一个一个job连接起来的流水线，其中也自己写了不少的shell script去自定义我们的东西，在银行里搞devops真是道路曲折呀.

2. 开发人员提交代码后是否能得到快速反馈？即是否会运行JUnit去验证代码的正确性，部署后是否会运行E2E测试去验证代码的正确性.

敏捷的一个重要价值观就是持续反馈，但是怎么样实现呢？devops可以帮到我们，所以我们开发人员写完代码之后，能快速的运行JUnit, smoketest, E2E Test的话，这样才能快速给开发人员得到快速的反馈，同样，业务人员也可以要求部署团队尽快部署到UAT，快速在UAT的环境中得到快速反馈。 所以，如果在敏捷中得到快速反馈，scrum并没有告诉我们怎么做，但devops告诉我们，可以这样做 >_<

3.团队的JUnit的测试覆盖率是多少?

在TDD时候，我们是强调先写测试才写代码，但我们知道这样比较难行，因为太少公司能做到这样了，不过我们就因此不写JUnit了吗？不，我们要写，我们不得不写，但写多少呢？根据Mike Cohn的测试金字塔，JUnit的比例要达到80%，你的JUnit覆盖率达到了吗？

4. E2E的测试覆盖率是多少?(有些团队还会做服务测试0)

有这么多的JUnit我们还需要E2E测试吗？我们需要，当我们部署完后，我们需要运行一下E2E测试，以确保我们的系统是可以照常运行了，比例是多少呢？还是测试金字塔，Mike Cohn告诉我们是5%到10%，我们需要E2E测试，但我们并不需要太多，因为E2E的测试用例是成本比较大的.

5. DEV,SIT和UAT的部署是否是同一个二进制文件(即是否用同一个jar/war/ear去部署的)?

用同一个二进制包进行部署，我相信开发人员对这个深有体会，很多时候我们会遇到这样一个问题，明明在本地可以的呀，为什么上到SIT就不行了, SIT还是可以的呀，UAT怎么可能出问题呢？我加入这个项目前，我们的maven是用了profile的一个功能，对不同的环境运行不同的maven命令，这样打出来的二进制包是不一样的，就是说每个环境用的都是不一样的package,天哪，这不是反天理吗？后来我就将环境的property放到外面去了， 这才解决这个问题。所以确保每个环境使用的是相同的package，尤其要和production的要一样，否则出了问题的时候，你会很难发现是哪里出了问题。

6. 多久进行一次SIT部署和测试?

这里根据我的项目特点，我们是要求手动SIT部署，因为开发人员提交代码后，我们会执行DEV部署和DEV E2E测试，因为我们不知道开发人员什么时候提交代码，所以这样的话，我们的DEV环境就会非常的不稳定，当在部署的时候，DEV是不可用的，测试人员是在SIT测试的，所以为了保持稳定的环境，我们会对SIT进行手动控制。

7. 多久进行一次UAT的部署和测试?

为什么会有这一项呢， 因为通常QA或者用户是在这个环境测试的，如果UAT足够频繁，这说明你的产品被验证得越频繁，你的产品则越能得到快速的反馈。