大約一年前Graham和我參加了Google IO大會，為的是了解未來流行的技術(shù)，還有見見硅谷的技術(shù)人員。那次的經(jīng)歷非常好。我們見到了一群厲害人物，并且接觸到了一些新技術(shù)。先不說其他的，那個大會上，我們收獲最大的就是見到了一位技術(shù)/開發(fā)的前輩和一種新的創(chuàng)業(yè)公司開發(fā)流程。

???????? 隨著HitSend的成長，我們依據(jù)自身所需調(diào)整了我們的開發(fā)以及開發(fā)流程。在最初我們采用了廉價的主機(jī)提供商，然后研究怎樣克服它們的局限性。我們知道有其他的方法，但是它們似乎都會增加復(fù)雜的規(guī)則和流程。本來已經(jīng)運(yùn)轉(zhuǎn)得很好了，為什么還要修改呢?

我們后來在Google IO大會里遇到了Ian。他答應(yīng)分享一些由他反復(fù)思索得到的見解。Ian是一名在Sendgrid工作的高級網(wǎng)頁開發(fā)者/架構(gòu)師。Ian非常厲害，對他的建議我們真的很上心。下面你會看到很多證明他值得夸獎的地方(包括所開的玩笑也是從他那里偷來的)。

為了更好地管理我們的業(yè)務(wù)成長，我們改變了我們的創(chuàng)業(yè)公司的如下5個開發(fā)流程。如果你也認(rèn)為它只會增加復(fù)雜規(guī)則和流程，那么在結(jié)尾處你會找到一些(非學(xué)術(shù)的)這些變化產(chǎn)生的結(jié)果。

Graham正計劃著將來再發(fā)一篇文章，詳細(xì)介紹每一個步驟是如何讓我們開發(fā)和推送代碼更快捷，而且還能提高我們的代碼質(zhì)量的。這個可以作為我們?nèi)绾喂ぷ鞯牧己玫拇缶V。

　　第一步：正確地使用git(/GitHub)

把我們的app分割到更好的版本庫中。這個工作目前還在進(jìn)行當(dāng)中。

“產(chǎn)品”分支是當(dāng)前部署和運(yùn)行在服務(wù)器上的分支。

“暫存”分支是處于要上線的隊列里，而且總是可部署的分支。

其他的都分到它們自己的分支。新特性，維護(hù)和熱補(bǔ)丁分支應(yīng)該有個簡短但富有描述性的名字：

* 特性分支以“F-”開頭

* 維護(hù)分支以“M-”開頭

* 熱補(bǔ)丁分支以“H-”開頭

我們合并(merge)分支到暫存分支。然后暫存分支再合并到產(chǎn)品分支。團(tuán)隊對兩次合并都要做代碼檢查。(熱補(bǔ)丁可以倒著來)

我們像GitHub那樣使用Pull Request：

* 如果有個大的特性(一個”Epic“)，我們先為它新建一個issue。這個issue里我們策劃好最佳的處理辦法，如果它需要修改用戶界面，我們還要畫些草圖。這樣使得我們團(tuán)隊可以在任何人背道而馳之前被叫住。

* 當(dāng)我們準(zhǔn)備好開發(fā)某個特性，我們在暫存分支上發(fā)(或者從issue轉(zhuǎn)化)一個Pull Request。我們在建立分支后就馬上做這件事。這意味著我們的每次提交都有額外的可見性。

* 我們編程的時候會給團(tuán)隊屏幕截圖或者提問。這可以做為該特征的某種生動的歷史記錄(想想Facebook墻)

我們還向GitHub issue跟蹤器添加我們的產(chǎn)品路線圖，向里程碑區(qū)域添加我們的sprint。它允許我們把issue指派到sprint，然后計劃我們下面兩周的工作。

　　第二步：輕敏捷開發(fā)

不需要進(jìn)行”敏捷開發(fā)“，但是類似。理想中它結(jié)束于10天的sprint，盡管有時候第10天還在開發(fā)。

第一天：sprint計劃日

第二天：Scrum。干活。測試。推送。

第三天：Scrum。干活。測試。推送。

第四天：Scrum。干活。測試。推送。

第五天：Scrum。干活。測試。推送。

第六天：調(diào)整Scrum。Back log grooming。測試。推送。

第七天：Scrum。干活。測試。推送。

第八天：Scrum。干活。測試。推送。

第九天：Scrum。干活。測試。推送特性分支。審查狀態(tài)，為演示日準(zhǔn)備。

第十天：演示加分析加反思加sprint計劃日

這步聯(lián)合第一步，在我們每天的開發(fā)過程里帶來了很大的正面變化。

　　第三步：HitSend機(jī)器人部隊

我們做了一個暫存分支部署機(jī)器人，他監(jiān)聽在SoapBox的暫存分支的代碼改動。如果有改動，他取得代碼然后放到服務(wù)器上。他快得讓我驚奇。

產(chǎn)品分支部署機(jī)器人在產(chǎn)品分支上做的同樣的事情。

我們還做了一個Hitbot，或者叫hubot 篝火聊天室機(jī)器人. 他連到我們的github賬戶，如果我們需要的話，可以提供我們的版本庫的信息。我確信他會成為今后hack項目的中心。

　　第四步：集體意識的規(guī)劃

我們?yōu)殚_發(fā)者貢獻(xiàn)了我們創(chuàng)建的javascript和php代碼風(fēng)格指導(dǎo)。我們有些代碼現(xiàn)在甚至也沒有遵循它們，但是它們?yōu)槲覀兲峁┝艘粋€超前的結(jié)構(gòu)，有希望能夠讓生產(chǎn)的代碼，看起來像同一個開發(fā)者寫的一樣。

對于大型的項目，例如我們的新API，我們先把文檔編寫好。它們扮演的是提案文檔的角色。因此(在開發(fā)的時候)我們不是在發(fā)明，而是在建造。這些指南讓我們在風(fēng)格約定上取得一致，讓我們更加并行地工作。

　　第五步：測試一切

我們在HitSend下面建立了自己的Travis-CI，在各自的環(huán)境下構(gòu)建和測試SoapBox。一旦運(yùn)轉(zhuǎn)起來一切都相當(dāng)簡單。

它在分支上測試：產(chǎn)品分支，暫存分支還有Pull Request對應(yīng)的分支。下面是它如何工作在我們的開發(fā)流程上的：

* 建立Pull Request，或者提交代碼到Pull Request上

* Travis獲取代碼，然后根據(jù)我們的設(shè)定，在虛擬機(jī)上進(jìn)行配置

* 對php代碼做PHP單元測試還有PHP語法檢查

* 然后對javascript做QUnit和jshint

Travis-CI告訴GitHub測試是否通過。如果通過了，它會把“合并”按鈕變?yōu)榫G色，未通過就是灰色。并且提供一個指向測試失敗的日志的鏈接。參見GitHub對這個特性的描述。

Travis持續(xù)集成，然后通過我們的篝火聊天室的Hitbot與我們交流信息。

現(xiàn)在留給我們的就是構(gòu)建我們的單元測試。當(dāng)我們的語法檢查和jshint通過了后就只剩下少量的測試。

　結(jié)果：

總體來看，開發(fā)的時光車從1995年駛到2013年，一路上都極其成功。我很愿意說第六步是啥啥啥，第七步是“盈利”，但是說實話每一步都對業(yè)務(wù)有幫助。

這些結(jié)果不是那么學(xué)術(shù)，但是是立竿見影的：

正確使用git提升了我們代碼和代碼庫的質(zhì)量，提升的還有生活質(zhì)量。當(dāng)要做熱補(bǔ)丁時我們絕不用感到緊張。從產(chǎn)品線拉出分支，修改，合并，搞定?；氐侥愕奶匦蚤_發(fā)分支。

敏捷開發(fā)給我們帶來了恰到好處的關(guān)注量。我們能夠投身到某個任務(wù)2周，不用太擔(dān)心其他開發(fā)任務(wù)。它給我們的代碼和特性開發(fā)的質(zhì)量帶來了顯著的效果。聚焦。

作為一個警醒的小團(tuán)隊我們比大多數(shù)人都更加注意到要在更大范圍內(nèi)改變低效率。為Graham每天或每周節(jié)省一小時，對我們來說就是一個巨大而顯著的好 處。機(jī)器人這樣做了，而且有望隨著時間推移做得更多。機(jī)器人犯錯誤更少……這就意味著我們永遠(yuǎn)不用擔(dān)心需要的全部文件都會被推送到產(chǎn)品分支去。

第四步和第五步帶來的好處我相信會清償今年上課的花銷。隨著我們開發(fā)團(tuán)隊的壯大尤其如此。我相信會給他們就怎樣工作做更多的方向性指導(dǎo)，并建立一個擴(kuò)展性更好的勞動力。我認(rèn)為當(dāng)推送代碼到服務(wù)器時，它還會給我們帶來更大的自信。

這就是我們創(chuàng)業(yè)公司的開發(fā)流程。你們的公司是怎么干活的?我們總是在尋找改進(jìn)我們流程的辦法。我們覺得很好，但還不完美。我們想知道你有什么改進(jìn)的建議!

轉(zhuǎn)自：產(chǎn)品中國