我们的目标是：通过持续集成，让所有软件项目的参与方都很容易，甚至是被迫的清楚当前项目的持续集成情况。
第一步，让所有人产生共鸣，下面描述几个场景，大家看看是否似曾相识：
场景1：
开发人员A更新代码，发现本地编译报错，开始询问同一开发组的成员。这时有些人继续埋头继续开发，有些人在编译自己本地的代码，发现没问题。
于是A只能自己查看出错地方的SVN Log，发现是开发人员B漏提交了一个文件。通知B，B检查了代码，确实是漏提交了，但是本地已经修改了其他代码，并且添加了一些别的文件，暂时不能提交。
于是B跟A说：“我现在不能提交，你先等一下，要不就把那段代码注释掉先，你急的话我先把文件发给你，你帮我提交一下也行”。
场景2：
开发人员A完成了一个保存订单的功能，本地编译、测试通过。提交代码，发包到测试环境。测试人员C发现该功能并没有完成，点击保存的时候会报错。于是通知A，A大声叫了一句：“我电脑上用的好好的啊，不信你来看”。然后郁闷跑到测试环境查看日志，发现是一个数据库脚本文件没有打倒测试环境，于是A找到DBA，问：“为什么这个脚本没打？”DBA回答说：“啊，这个脚本要打吗？哦，系统太多了，你们先等一下吧”。
场景3：
开发人员A身体不适，请假一天。恰巧他做的功能今天测试发现问题了。比较紧急，PM决定由开发人员B来完成该功能。B打开工程，费了好大力气找到相应的代码。然后发现一堆方法，长一点的甚至超多了1000行。头懵了一下，然后报告给PM：“太乱了，不知道改那里”。PM说：“打电话给A”，B与A通话10分钟，依然不知道怎么开始。
于是PM决定延期一天发布，等第二天A来改了问题后，PM对A说：“代码不能写的这么乱的，不好维护”A回答说：“时间太短了，下次我注意”。
于是该场景在整个开发过程中一直在循环。
场景4：
开发人员A接受了一个比较复杂的任务，涉及到好几个业务流程。A认真思考了一下，花了半天时间完成了该功能，并做了很认真的检查。但是还是觉得不放心，于是他就提交了代码，发布到测试环境。然后跟测试人员C说：“嘿，我刚提交了一个功能，比较复杂，帮我先测一下。”C很客气的说：“好”。
C首先花了20分钟阅读了该功能的需求。然后按照需求的描述对功能进行测试，很快就发现了几个问题，然后跟A进行讨论，A发现有一个问题是代码出现了Bug，但是还有几个问题他认为不存在问题，是C对需求不理解。然后他们一起找到了需求提供人D。
D很认真的花了20分钟跟A、C解释了需求，然后A跟C发现自己的理解都有偏差。于是A花了一段重新修改了代码，自我感觉应该没问题了，再次发布到测试环境，C又花了一段时间重新测试了该功能。跟A说：“可以了”。
第二天，项目集成测试，C突然发现，昨天已经通过的功能，现在又不行了。于是找到A，A研究发现，是做别的功能时影响到了相关的逻辑。于是再次修改该功能。再次发布。C再次测试。。。。。。。。。
场景5：
客户使用系统过程中发现了一个问题。开发人员A接收到了该问题，但是由于上次发布后，本地开发已经进行了很长一段时间，于是A通知CM需要一个现在正式环境系统对应的代码版本，然后checkout代码。
本地运行，发现系统无法运行，发现是由于数据库结构发生了一定的变化，为确保修改的正确性，A只能找出这段所有人修改的脚本，一个个手动还原回去。
此时开发人员E发现自己的程序调试出了问题。发现了自己添加的字段不见了。A只能跟其协商：“一会就好，这个问题解决了我就加回去”。
A改完问题提交到分支，通知测试人员C进行测试。C使用了一下系统，发现了报错的地方，找A沟通，A说：“当然，数据库都不一样，叫DBA导一份数据下来，重新建个库就好了。。。。。
场景6：
客户提出了一个很简单的需求，要求第二天就看到效果。开发人员A花了10分钟解决了，想快速的发布到正式环境供用户使用。但是测试人员C不同意了，说：“你确定这个修改不会影响到别的功能吗？”A说：“肯定不会”C心里嘀咕一下：“你上次也是这么说的，我也信了，最后不还是出问题了。”。。。。。。。。。。。。。。。。。。。于是我们的客户买了隔壁公司的软件。
当然类似的场景在开发过程中还有很多很多，只是选择了一些具有代表性的写了出来，不知道各位有没有一样的或者不一样的情况，欢迎补充，大家一起看看我们日常的开发究竟存在着多少问题。
最新评论