创业公司的开发流程改变公司的个开发流程
⇨⇦
大约一年前Graham和我参加了Google IO大会，为的是了解未来流行的技术，还有见见硅谷的技术人员。那次的经历非常好。我们见到了一群厉害人物，并且接触到了一些新技术。先不说其他的，那个大会上，我们收获最大的就是见到了一位技术/开发的前辈和一种新的创业公司开发流程。
随着HitSend的成长，我们依据自身所需调整了我们的开发以及开发流程。在最初我们采用了廉价的主机提供商，然后研究怎样克服它们的局限性。我们知道有其他的方法，但是它们似乎都会增加复杂的规则和流程。本来已经运转得很好了，为什么还要修改呢?
我们后来在Google IO大会里遇到了Ian。他答应分享一些由他反复思索得到的见解。Ian是一名在Sendgrid工作的高级网页开发者/架构师。Ian非常厉害，对他的建议我们真的很上心。下面你会看到很多证明他值得夸奖的地方(包括所开的玩笑也是从他那里偷来的)。
为了更好地管理我们的业务成长，我们改变了我们的创业公司的如下5个开发流程。如果你也认为它只会增加复杂规则和流程，那么在结尾处你会找到一些(非学术的)这些变化产生的结果。
Graham正计划着将来再发一篇文章，详细介绍每一个步骤是如何让我们开发和推送代码更快捷，而且还能提高我们的代码质量的。这个可以作为我们如何工作的良好的大纲。
第一步：正确地使用git(/GitHub)
把我们的app分割到更好的版本库中。这个工作目前还在进行当中。
＂产品＂分支是当前部署和运行在服务器上的分支。
＂暂存＂分支是处于要上线的队列里，而且总是可部署的分支。
其他的都分到它们自己的分支。新特性，维护和热补丁分支应该有个简短但富有描述性的名字：
* 特性分支以＂F-＂开头
* 维护分支以＂M-＂开头
* 热补丁分支以＂H-＂开头
我们合并(merge)分支到暂存分支。然后暂存分支再合并到产品分支。团队对两次合并都要做代码检查。(热补丁可以倒着来)
我们像GitHub那样使用Pull Request：
* 如果有个大的特性(一个＂Epic＂)，我们先为它新建一个issue。这个issue里我们策划好最佳的处理办法，如果它需要修改用户界面，我们还要画些草图。这样使得我们团队可以在任何人背道而驰之前被叫住。
* 当我们准备好开发某个特性，我们在暂存分支上发(或者从issue转化)一个Pull Request。我们在建立分支后就马上做这件事。这意味着我们的每次提交都有额外的可见性。
* 我们编程的时候会给团队屏幕截图或者提问。这可以做为该特征的某种生动的历史记录(想想Facebook墙)
我们还向GitHub issue跟踪器添加我们的产品路线图，向里程碑区域添加我们的sprint。它允许我们把issue指派到sprint，然后计划我们下面两周的工作。
第二步：轻敏捷开发
不需要进行＂敏捷开发＂，但是类似。理想中它结束于10天的sprint，尽管有时候第10天还在开发。
第一天：sprint计划日
第二天：Scrum。干活。测试。推送。
第三天：Scrum。干活。测试。推送。
第四天：Scrum。干活。测试。推送。
第五天：Scrum。干活。测试。推送。
第六天：调整Scrum。Back log grooming。测试。推送。
第七天：Scrum。干活。测试。推送。
第八天：Scrum。干活。测试。推送。
第九天：Scrum。干活。测试。推送特性分支。审查状态，为演示日准备。
第十天：演示加分析加反思加sprint计划日
这步联合第一步，在我们每天的开发过程里带来了很大的正面变化。
第三步：HitSend机器人部队
我们做了一个暂存分支部署机器人，他监听在SoapBox的暂存分支的代码改动。如果有改动，他取得代码然后放到服务器上。他快得让我惊奇。
产品分支部署机器人在产品分支上做的同样的事情。
我们还做了一个Hitbot，或者叫hubot 篝火聊天室机器人. 他连到我们的github账户，如果我们需要的话，可以提供我们的版本库的信息。我确信他会成为今后hack项目的中心。
第四步：集体意识的规划
我们为开发者贡献了我们创建的javascript和php代码风格指导。我们有些代码现在甚至也没有遵循它们，但是它们为我们提供了一个超前的结构，有希望能够让生产的代码，看起来像同一个开发者写的一样。
对于大型的项目，例如我们的新API，我们先把文档编写好。它们扮演的是提案文档的角色。因此(在开发的时候)我们不是在发明，而是在建造。这些指南让我们在风格约定上取得一致，让我们更加并行地工作。
第五步：测试一切
我们在HitSend下面建立了自己的Travis-CI，在各自的环境下构建和测试SoapBox。一旦运转起来一切都相当简单。
它在分支上测试：产品分支，暂存分支还有Pull Request对应的分支。下面是它如何工作在我们的开发流程上的：
* 建立Pull Request，或者提交代码到Pull Request上
* Travis获取代码，然后根据我们的设定，在虚拟机上进行配置
* 对php代码做PHP单元测试还有PHP语法检查
* 然后对javascript做QUnit和jshint
Travis-CI告诉GitHub测试是否通过。如果通过了，它会把＂合并＂按钮变为绿色，未通过就是灰色。并且提供一个指向测试失败的日志的链接。参见GitHub对这个特性的描述。
Travis持续集成，然后通过我们的篝火聊天室的Hitbot与我们交流信息。
现在留给我们的就是构建我们的单元测试。当我们的语法检查和jshint通过了后就只剩下少量的测试。
结果：
总体来看，开发的时光车从1995年驶到2013年，一路上都极其成功。我很愿意说第六步是啥啥啥，第七步是＂盈利＂，但是说实话每一步都对业务有帮助。
这些结果不是那么学术，但是是立竿见影的：
正确使用git提升了我们代码和代码库的质量，提升的还有生活质量。当要做热补丁时我们绝不用感到紧张。从产品线拉出分支，修改，合并，搞定。回到你的特性开发分支。
敏捷开发给我们带来了恰到好处的关注量。我们能够投身到某个任务2周，不用太担心其他开发任务。它给我们的代码和特性开发的质量带来了显著的效果。聚焦。