大约一年前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周，不用太担心其他开发任务。它给我们的代码和特性开发的质量带来了显著的效果。聚焦。

作为一个警醒的小团队我们比大多数人都更加注意到要在更大范围内改变低效率。为Graham每天或每周节省一小时，对我们来说就是一个巨大而显著的好 处。机器人这样做了，而且有望随着时间推移做得更多。机器人犯错误更少……这就意味着我们永远不用担心需要的全部文件都会被推送到产品分支去。

第四步和第五步带来的好处我相信会清偿今年上课的花销。随着我们开发团队的壮大尤其如此。我相信会给他们就怎样工作做更多的方向性指导，并建立一个扩展性更好的劳动力。我认为当推送代码到服务器时，它还会给我们带来更大的自信。

这就是我们创业公司的开发流程。你们的公司是怎么干活的?我们总是在寻找改进我们流程的办法。我们觉得很好，但还不完美。我们想知道你有什么改进的建议!

转自：产品中国