對新創項目而言，是idea更重要，還是執行力更重要？在沒有用戶時，我們該如何冷啟動？團隊、人、技術、產品、推廣和拜春哥，哪一個更重要？到底是什么決定了一個項目的生存或者毀滅？

    來吧，一起書寫51daifan的成長史吧。51daifan是一個同事之間分享午餐、特產的公益平臺。每天帶飯的同學，可以多帶幾份愛心便當，分享給身邊的同事。大家中午一起熱飯，一起桌上足球，一起品嘗同事帶來的愛心便當。讓午餐變成每天最快樂的時光。

    51daifan從5月底開始有想法，一周后6月初web版本上線，四周后7月中旬android版本上線，現在，8月初，ios版本即將上線。2個月時間，有過快樂，有過迷茫，也有過痛苦。它到底會不會成功，誰也不知道，這也許就是生活最富有魅力的部分吧。關注我們的微信公共號，一起來品味產品成長中的酸甜苦辣吧：

    一起來品味產品成長中的酸甜苦辣吧，每周一，我們將把51daifan上周所有滋味傾訴在這里：產品的運營數據、開發進度、對產品方向的思考、產品運營遇到的問題和想法。加入我們，一起來決定產品的進程吧，把你的想法告訴我們，我們一起來嘗試，不管結果如何，當我們的額頭爬滿皺紋，我們能做到的就是，不讓它們也爬在心里。

一、產品源起

產品想法緣起每天的午飯：

但是，我們周圍還有這樣一群人：

于是，我們想：

產品運營&數據

    目前產品上線8周，注冊用戶160人，app下載用戶22人，日活躍用戶在25人。有過訂飯/帶飯行為的用戶為62人，訂飯數據371人次。

產品運營分為3個階段：

1. 6月份中上旬在部門里試用，用戶數到達30人，日活躍用戶在20人，2人帶飯，日均訂飯數12；
2. 6月下旬在公司BBS進行了第一次推廣，一周內注冊用戶數達到90人，但帶飯人數依舊是2人，拓展新的帶飯同事困難（之前假設妹子有時間帶飯的路證明是不通的），日均訂飯數16；
3. 7月開始轉換思路，同時鼓勵同事可以分享自己家產的特產，進行了兩次自家蜂蜜和蜂王漿的團購，產品推廣集中在bbs發帖，人數緩慢增長到160，一位帶飯的同事退出（確實是太累了，純愛心活），為了增加網站粘度，增加了711免費帶飯服務，但效果并不明顯。因為沒有找到新的帶飯同事，目前日均訂飯數下降至10。

    對當前產品運營來說，最重要的工作就是如何找到更多愿意分享的同事。目前有兩種思路：一是降低分享的門檻，例如我們可以分享自己15分鐘家常菜的菜譜，通過降低門檻拉動社區的活躍度；二是推廣我們的網站，認為沒有更多分享同事是因為我們用戶數還很少。

    9月份有個大的分享活動是nanana同學家在五常，10月她家新稻米收割，我們會組織一次團購，五常稻花香大米在超市的價格在10元左右是陳米并且一定摻有其他米（這已經是所有大米收購時就有的潛規則），我們初步考慮的價格在7元左右，成本在于物流，真是個大問題，目前考慮是長途車送至四惠客運站，然后再包車拉到公司（可行性還在討論）。

 

對產品方向的不懈思考

    我始終認為產品大的方向絕對正確，就是基于社交關系的O2O（這里是同事關系）。在這個全國造假、連政府信用都已經破產的當下，冷漠、造假似乎是我們這個時代的代名詞。我們一定能做點什么，通過基于社交/同事關系的O2O，我們認為一定能重建人們之間的關心和溫暖。一方面我們能獲得綠色、環保、健康的食品，另一方面，能夠拉近同事間的關系。

 

當前開發進度

    目前web、android、ios開發全部在同步進行，全部是業余時間開發，代碼開源在：https://github.com/ronghao100。Android第一個版本已經發布，第二個版本將包含上傳圖片和消息通知，計劃下周發布，ios本周提交審核，計劃一周后發布。

 

對這個項目發展你有什么想法，來吧，一起決定它的未來！掃描二維碼立刻關注我們的微信公共賬號：

 

一、我們要解決的問題

無論是什么樣的解決方案，一定要牢記我們要解決的問題是什么，切不能將解決方案當做問題本身。具體到過程改進，不管是何種方式的改進，它們所要解決的問題永遠只有一個：縮短從產品想法到可用軟件之間的時間周期。自動化發布正是如此，如果軟件發布只做一次，我們說根本不需要自動化，但如果三次以上，那么軟件開發的黃金法則DRY就必須遵守，讓時間真正用到開發當中去。

 

二、與發布相關的問題

所謂自動化只不過是將原先手工做的工作謙讓給機器做，所以自動化之前一定要先清楚與發布相關的問題有哪些，即使不自動化，這些工作也一個也不能少：

1. 應用程序如何打包？ 發布包能否追蹤到SVN版本號？
2. 對目標機器環境有什么樣的要求？
3. 配置信息是否需要根據目標機器信息做出調整？
4. 應用程序如何安裝和啟動？
5. 應用程序啟動后如何切流量？
6. 應用程序如何升級？ 舊版本程序數據如何遷移？
7. 升級過程中和結束后如何切流量？
8. 應用程序如何卸載？

 

三、我們的方案

李安的少年Pi正在狂刷票房，我們的自動化發布方案也要跟上潮流：Puppet+CI我們的少年Pi。

Ø 使用CI自動化打包，追蹤每個發布包的SVN版本；

Ø 使用Puppet管理發布包、目標機器環境、應用程序配置信息以及應用程序線上生命周期；

Ø 使用伽利略系統提供應用程序的命名服務和進行流量切換。

現在應用程序的發布需要兩步：CI一鍵打包、puppet指定應用程序版本SVN提交。

 

四、具體方案

具體方案也就是如何解決與發布相關八個問題的過程。

1.         如何安裝、升級和卸載應用程序

我們使用操作系統原生包管理系統來安裝、升級和卸載應用程序，我們的應用程序打出RPM二進制包。免安裝，所有機器自帶，綠色的，有機的。

打包：rpm -ba ./team_member-1.spec

安裝：rpm –ivh team_ member-2.0.1-48.x86_64.rpm

升級：rpm –U team_ member-2.0.1-49.x86_64.rpm

卸載：rpm –e team_ member-2.0.1-48.x86_64.rpm

程序升級前要停舊版本服務怎么辦？舊版本數據要做處理怎么辦？RPM已經幫我們料理好這一切，只要寫出spec文件，剩下的交給我們。盡情的插入吧：

 

2.         如何管理目標機器環境和應用配置信息

應用程序已經打好rpm包了，但這還不夠，應用程序發布到哪臺機器上？應用程序對目標機器有什么要求？發布時需要修改哪些配置和參數？實際發布如何執行，難道需要登陸到每臺目標機器運行rpm命令嗎？

我們使用Puppet來搞定這一切，Puppet是現在應用第一的devops工具，它通過master/agent的工作模式管理機器。我們通過聲明來控制我們的機器達到目標狀態。同時，所有puppet文件全部在SVN里，所有對機器的修改全部codereview和可審計。

 

如何管理應用程序發布到哪臺機器上？在回答這個問題前我們必須將應用程序在線上的生命周期再進行一次封裝。

應用程序TeamMember被我們封裝成一個puppet module，配置文件和參數被封裝在對應templates和files里，每次發布前都要修改配置文件和傳遞不同的參數？out了吧，puppet幫你傳參搞定:

Teammember.conf文件內容：

封裝完成后的效果是這樣的：

最后在管理部署的site.pp文件里聲明一下，應用程序TeamMember的2146版本就被自動部署到10.128.34.141.test.back.shequ這臺機器上了，我們后續的工作也就是維護這個site.pp文件了，所有應用程序的部署信息都在SVN被集中管理起來：

登陸到每臺目標機器運行rpm命令？No!現在TeamMember已經被封裝，我們修改完畢site.pp并提交后，puppet就自動執行命令了，要不怎么說是自動化呢。（現在puppet默認在agent每半小時同步一次，但同時支持馬上觸發執行）。

 

3.         如何追蹤每次發布的SVN版本號

我們使用CI進行應用程序的打包，將build號作為包命名的一部分：

 

4.         如何在發布過程中切換流量

這是另外一個很大的話題，參見伽利略計劃。

 

五、下一步工作

使用CI將環境的自動化部署與自動化測試串聯起來，搭建起整個研發流程自動化平臺：

 

六、小結

沒有銀彈，自動化所做的只是將之前手工工作交給計算機完成，需要做的工作一個都不能少，此外，我們還要多做一些封裝或腳本工作，但是，當我們需要重復做這些事情的時候，價值就出現了。我們的目標永遠是縮短從產品想法到可用軟件之間的時間周期。讓時間真正用到開發當中去。