創業公司的開發流程:改變公司的5個開發流程

1 評論 5252 瀏覽 21 收藏 10 分鐘

  大約一年前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每天或每周節省一小時,對我們來說就是一個巨大而顯著的好 處。機器人這樣做了,而且有望隨著時間推移做得更多。機器人犯錯誤更少……這就意味著我們永遠不用擔心需要的全部文件都會被推送到產品分支去。

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

這就是我們創業公司的開發流程。你們的公司是怎么干活的?我們總是在尋找改進我們流程的辦法。我們覺得很好,但還不完美。我們想知道你有什么改進的建議!

轉自:產品中國

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 有沒有git教程,我第一次使用,不懂用

    回復