大約一年前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每天或每週節省一小時，對我們來說就是一個巨大而顯著的好處。機器人這樣做了，而且有望隨著時間推移做得更多。機器人犯錯誤更少……這就意味著我們永遠不用擔心需要的全部檔案都會被推送到產品分支去。
- 第四步和第五步帶來的好處我相信會清償今年上課的花銷。隨著我們開發團隊的壯大尤其如此。我相信會給他們就怎樣工作做更多的方向性指導，並建立一個擴充套件性更好的勞動力。我認為當推送程式碼到伺服器時，它還會給我們帶來更大的自信。