西安软件园OPEN-PARTY之旅
下午在软件园听了两个座谈，一个是Baidu的乔梁(@乔梁QL，持续交付，闲亭信步（KISS）)，讲的持续集成的更进一步——持续交付(deploy)。在互联网公司中，更新周期是非常短的，为了能得到用户的最新回馈，为了能将产品最快速的部署上线，不停的进行产品feature的升级，持续交付是一个良好的思路。能够在开发人员编码结束后，自动化的进行测试和部署是一个主要的环节。在这个环节中，会用到一些敏捷开发中常用的工具，比如CruiseControl，以及ThoughtWorks开发的持续集成工具go，这些工具可以辅助开发人员(dev)与测试人员(QA)更好的协调工作。
对于部门划分比较明确的公司，提供业务能力的主要障碍有以下几个：
- 冗余的决策
- 部门目标与优先级之间的冲突
- 避免承担风险的文化
- “筒仓式”的信息孤岛
其中部门目标优先级的冲突是比较明显的。各个部门的优先级不统一，比如运维部门希望一次部署长期稳定的运行，而开发部门又要不断的进行产品的更新，因此这是一个必须要解决的conflict。
对于目前的有些互联网公司，例如在code.flickr.com的网站下部可以看到
Flickr was last deployed 10 hours ago, including 5 changes by 1 person.
In the last week there were 68 deploys of 384 changes by 24 people.
他们的部署频率是非常高的的，即可以随时适应改变。
还有几个比较典型的网站，如
- WordPress
- WealthFront
- Quora
- Linked in
对于某些项目，有大量的hot-fix，对于每个fix都从主干划分出一个branch未必是一个好主意，可能直接在主干上开发会有更高的效率，这样可以尽可能的缩小发布周期。不过这种方式似乎不适合软件公司，因为软件公司具有一个更长的可接受deploy周期，故而要具体问题具体分析。
我也提出了一个问题，如此频繁的feature发现，是建立于大量用户feedback的基础上的，然而，这些feedback并不是“免费的午餐”，如何获取它们是需要代价的。互联网公司相对有较为廉价且海量的反馈信息，然而对软件公司，可能这些条件是不被允许的。乔梁的回答是Baidu会有自己的运营与分析团队，软件公司也会有相应的解决方案，二哥给出了更贴切的回答：我们会有BA来与客户进行业务方面的交涉，这种交涉周期可以根据软件展示周期而进行调整，也可以在需要时主动去确认用户需求，做到客户成为开发角色的一部分。公司不会专门的安排这些BA，因为团队中的每一个人都应该有这样的素质，胡凯在文章《建设全功能团队》上有这方面的论述。这对于提高团队中每个人对于项目的全面理解有很大好处，同时可以使团队在项目推进能力上有比较大的提升，不至于因为一些人员的因素导致项目推进受阻，这是我个人的理解。
由于这种持续交付的交付周期短的需要，开发人员在开发代码是要开发production-ready code，个人也没有很好的理解，可能是开发风格方面的问题，首先各个开发人员代码风格要保持一致，要有更明确的目标，彼此的对接性要够好。这是我个人的理解，还请批评指正。
在feature的开发部署过程中，要推行流水线的式的方法。将一个feature分成不同的Model，将每个模块进行模块测试，测试通过后合并为子系统，进行自动化子系统测试，再整合进大的系统机型系统测试，然后将系统放到与发布同环境的platform(这里称为Staging)上进行平台的测试，最后部署为最终的产品。后续的测试过程尽量的自动化进行，可以大大加快整个deploy时间。如下图所示。
整个流水线在开发过程中处于最高的优先级，如果任一环节出现问题，整个团队都要放下手头工作进行流水线的问题处理(PS:感觉这里有点问题，似乎可以设置这样的流水线控制人员，来负责整个流水线崩了的可能性，毕竟一人的工作好过让全员停下)。
在feature部署中，为了更快的上限，有一些策略，比如feature toggle，这就像一个特性开关一样，很有意思，即使某个feature没有开发完成也可以先上线，最快的得到feedback，然后再将此特性关闭，进行修改，再讲开关打开，成为更符合用户口味的产品。而且对于互联网公司来说，为了避免在反复部署过程中down机，也有一些策略，比如Canary(金丝雀) Release，即先放出几台服务器给少量用户进行下“内测”，如果效果好再全面“公测”。还有一个Blue-green deployment，要用两组服务器，通过路由策略进行快速转移，不过设计到数据库的同步问题，所以内部有些比较复杂的流程。
这些看起来复杂，但并不是不可能的，有三件事是这个过程的关键：
- Automation
- Practise
- People
最后放一片乔梁的一篇文章，持续集成之戏说Check-in Dance。
后来又听了tw冯智超(chaojiwudi.com)的云虚拟方面的一些东西，大约是搭建在amazon云端服务器的一个项目，涉及了一些项目的东西，不太懂，不过分享了下他的“yun”，放在github上，地址是github.com/flanker/yun，以及一个展示github.com/flanker/infoq-demo。
最后一个环节是创业者和风投的座谈，谈了创业的故事，挺有意思的。风投是低调的华丽，像转山里的晓川一样的男人，一直在强调创业一定要“抱团”，也就是有自己的创业团队，而且要各有特长。这也是我非常同意的一点，就像One Piece一样，打造自己的专业团队。然后在创业初期就要有明确的利益分成规划，最大程度避免后续的利益冲突。创业很艰难，但是怀揣理想的人们，平凡的生活是无法满足他们的，哈哈。马云也说过，“今天很残酷，后天很美好，但是大部分人在明天就死掉了，根本看不见后天的太阳。”创业也就是这样的，孤注一掷，破釜沉舟，谁笑到最后，谁笑得最好，哈哈。
PS:最后分享几张不清楚的照片，看来该换手机了，╮(╯▽╰)╭
