参加分享会让我收获很多----百度技术交流会

----百度技术交流会（京仪大酒店二层第一会议室）：我又迟到了，时隔比较久，还没有是整好路线图又下错地铁站，杯具了。[1] 乔梁Devops开发模式介绍：    之前在InfoQ上也看了一些DevOps相关的一些东西，其中我对一个问题比较感兴趣：现在的Facebook跟Tiwwer能够做到一天部署十几次，问，他们是怎么做到的？然后反观一下我实习公司的功能发布，有点囧啊——测试完成->清理修改文件->发布。 之前的一部分我也没有听到，迟到了...就听到他对DevOps的总结：DevOps 即代码工程师跟运维人中的一个集合体，运维的人懂代码人在讲什么，代码人也懂运维在讲什么，他们要争取做到一家，那么这个就是DevOps。同时，他理解的DevOps = 人 + 文化。有点深啊，不理解。从我的角度看，要是运维的人能很好的跟代码人员进行沟通，那么至少因为沟通所带来的问题会少很多，同时也没有必要多出很多的责任单，所以效率可能更多的是来自责任单上。这个也得自己加入到更大的团队才能慢慢的理解吧。先要求自己有果么一个意识，然后再慢慢加深。    之前在PHP手册上看到过乔梁的名字，一直赞啊。哈哈，这次会后还得到了他翻译的一要可持续付的书，灰常感谢了。    乔梁老大一直在强调一个思想：当出现了BUG时，其他的开发人员一定不要提交，一定要等当前的BUG被Fixed掉之后才能提交。同时，当出现了BUG，必须有人去马上Fix掉，在我的团队中，我不管这个BUG是谁提交导致的，我要的结果是BUG被很快的Fix掉。假如当前有三个人正在提交，那么你们三个给我负责，如果这个BUG在10分钟里还不能被Fix，那么我就要回滚到上一次成功提交的状态，我不能让这个BUG导致其他的员工不能正常工作。你们解决了问题再重新提交。    这段话一方面让我重新定义我该什么时候去Fix BUG，及我该叫谁去Fix这个BUG。之前我一直有一种观点：BUG应该是由写它的那个人去Fix。现在我发现我错了，在我上面的我想的事中，我也有讲到，这也不重复。总之，在公司这个比较大的环境下，公司对员工的期望值就是你能给公司当前所面临的问题带事一定量的解决方案，让当前的问题不断的减少，至于你是不是当前问题的制造者，他们不管，You needn't care anything, you just to fix this bug. [2] 虚拟技术跟云计算为持续交付提供保障：    此人讲的是跟他之前弄的一个项目结合来讲的，唉，感觉自己听的不是很进啊。可能是没有接触过，他show了一个他们的自动测试跟部署设备。哇是物理的啊，有指示灯！之前在InfoQ上看的一次Scurm的介绍视频里看到分享者有讲到这么一个东西，指示灯有三种状态：红，蓝，绿，分别代表：错误，编译，通过。灰常的酷啊。其它的真听不懂，有点乱...他讲到一个什么时候开始部署的问题，怎么才能让测试环境更加的接近生产环境，那么最好的办法就是让部署开始于程序的第一步，并每一个阶段性的进步都要进行一次部署，以防止出现测试机OK，而生产环境很多404的情况。他还讲到对于部署的工作是一个比较麻烦跟易错的事情，所以这样的事情最好由程序事自动化完成。这里他又重点强调了一下他们这个项目的代码量情况。最体的行数我忘记了，但他的介绍中，他们的Ruby代码即部署代码有跟项目的java代码相当的，同时他们的测试代码也暂有很大的比例。所以，要想得到可持续交付的代码，测试加自动化部署灰常的重要啊！