在產品的開發過程中，對資料量要求較高的**進行架構設計時如何部署是個很複雜的問題，涉及到多個層面的不同要求，七牛首席架構師李道兵在部署工具和測試以及持續整合方面給出了自己的思考。在七牛的開發者實踐日中與大家分享《從開發到上線 實戰持續交付》。
李道兵首先從不同的層面來分析目前的**的架構的設計，從資料庫、緩衝層的方面引出部署的概念。然後開始介紹部署工具的進化史，從最初的安裝文件、ftp/sftp、war包、系統安裝包到一鍵部署工具，一直到最近興起的docker，逐個分析了每種部署工具的優缺點。針對capistrano+puppet，進行了重點的講解和說明。最後結合七牛的例項分析了如何從**到上線的整個部署、測試、持續整合過程和其中可能會遇到的問題。下面是完整的現場記錄：
這次想和大家分享的是從開發到上線，特別是我們七牛在這方面關於一些持續交付的事情。在演講之前我推薦兩本書，一本是《精益創業》，更多講的是從想法變成實現的。其實從想法變成乙個**，再到運營的階段，通過運營階段反饋修整你的想法，形成這樣乙個迴圈，達到使用者的快速增長或者快速試錯調整你的產品。我今天講的是從想法到**，從**再到運營階段。第二本書是《持續交付》發布可靠軟體的系統方法，講的是你需要做哪些事情，包括持續整合和一鍵部署，大家有興趣的可以看一下。
最後乙個是可以做到一鍵部署，配置檔案比較簡單案件，比如說現場有一些小錯誤，你可以五分鐘之內把這個錯誤修復掉，不用等到漫長的部署流程。puppet和salt可以用來解決配置問題。在這樣的情況下，基本上就把這個東西解決了。現在有一些比較新興的部署方面的技術方向是docker，現在有一定程度上可以取代一些虛擬機器的東西，也可能成為一種新的軟體分發方式。但是現在來講，在我們看來有一些地方不太成熟，有一些嚴重的錯誤繞不過去，我們正在做研究，但是還沒有完成採用。
puppet/salt這兩套系統是來幫助你解決這個問題的，首先第乙個所有的配置入庫，你的所有機器上不管是要預裝哪些軟體或者怎麼樣，都可以在版本庫里看到資訊。第二個是胸模板簡化配置，十臺或者一百臺不需要把所有檔案拷貝，只需要指定一下就可以了，對應的哪些功能有哪些自然就知道了。而且也不用一台一台的應用這個配置，而且會定期做一些安全更新，或者其他的一些配置調整的東西，哪些需要重啟，它可以引入一些依賴或者訊息，通過這些指令使你不用想配置哪些配置了，類似的也會有一些其他的需求，這些需求都可以通過它來滿足。
對於我們來講cap+puppet的問題是我們要考慮的，我們回滾的時候只能回滾程式，如果程式和配置偶合的很緊的時候，新版本程式需要乙個新配置，你可以用程式設計來解決，這樣程式設計師就有很大負擔了。第三個有中心架構，但是優化的不夠好。當數量達到一千台往上的水平，它有一點支撐不住了，這是我們另外重新開發的理由。我們做雲儲存對資料安全非常關心，我們去線上裁判資料。開發人有很強的需求了解你的日誌，你線上的一些情況。比如說網路流量，一些連線數等等都是我們開發人員想去了解的。這樣的情況下，你就需要很多的指令碼幫助你的開發人員了解這些情況，這些也是之前不夠用的，需要我們另外開發一套新的部署系統的理由。這個新的系統我們現在已經逐步在採用了，也許將來有機會可以對外發布一下。
前面講了從**到上線的整個流程，儘管回滾很方便，但是你肯定不希望把錯誤的版本放上去。更何況有時候回滾並不能解決問題，因為有的錯誤已經發生了。比如說轉賬轉錯了，錢損失了，也挽回不了。你要保證**的質量就是要測試，我們推崇的是自動測試和持續整合。首先來講你的開發人員要寫你的單元測試和一些整合測試。第二個是你每次做一些合併請求的時候，所有單元測試和整合測試都會跑一遍，保證你所有的提交不會干擾你原有的業務邏輯。負責這個**的人員會特別注意，針對你寫的新功能或者錯誤修復是否補充了測試？如果沒有補充，直接就被拒絕了。最後發布的時候我們會有乙個更加好的測試，我們這個軟體可以決定跑乙個大規模的測試，來決定我們這個是不是最好的版本。但是一些**質量的視覺化工作是它做不了的，比如說單元測試的總數量是否隨著時間緩慢上公升，你的測試覆蓋率是否穩定在可接受的水平，這些都是很方便量化的。量化的視覺化能夠幫助主管或者其他人也好，很方便的知道這個團隊或者說**質量是否有裂化的問題，也方便大家介入。
從頭串一下工具鏈，我們怎麼做乙個小事情的呢？第乙個是提交issue，所有的工作跟它關聯起來。第二個是修改**提交你的pr(pull request)，如果持續整合通過了，這個pr就合併掉了。持續整合通過，通過之後進行部署，部署上線之後再次檢驗issue，然後就可以關閉了。我們把這個流程做的個很短，十幾二十分鐘就會完成，使得我們的試錯週期更短一些。這裡面有一些我們的經驗教訓，第乙個是所謂的正規化。
正規化是幾個點，第乙個是所有的原碼需要入庫，特別是第三方軟體，你遲早有一天對它修改。你盡早把它入庫，針對入庫的**做乙份發布系統的話，即使是第三方軟體也納入到部署流程裡面來，這對你以後是乙個好事。第二個是你線上的配置永遠不要入**庫，因為涉及一些隱私，特別是安全問題。如果說開發人員拿到線上資料庫密碼的話，我們認為是乙個風險。第三個是你線上的配置要入庫，不是入**，是入乙個部署庫。最關鍵的密碼和私鑰的部分不要做到庫裡面，比如說你把模板配置做到裡面，讓我們的整個過程很安全。整個程式也不需要上級領導蓋章和批准，全部可以自動化，又比較安全
我們有乙個遺留問題，第乙個是go語言的問題，是乙個編譯性語言，我們不希望它到伺服器去做，因為對我們伺服器擾動很大，我們通過可執行程式做分發。第二個問題是可執行程式分發的時候，內網達到一定程度的話，會使你的伺服器扛不住。我們自己是做儲存、分發的，最簡單的方法是檔案加一步推送到內網的分發節點，這樣就可以支撐你內網上千台伺服器。第三個是很多依賴外網的東西，我們很多機器是完全跟外網不能連線的。不僅外網訪問不了它，它也訪問不了外網。比如說像安全中心，或者說安裝部署的配置指令碼，就需要它去外網做一些東西，我們可以做一些包安裝的，剩下的問題我們可以通過它繞過來。
謝謝！該分享來自七牛首席架構師李道兵在此次的沙龍活動中帶來了題為《從開發到上線 實戰持續交付》的分享。
「開發者最佳實踐日」是由七牛雲儲存發起並聯合各方小夥伴為開發者舉辦的系列技術沙龍，關注開發者在實際應用中可能遇到的技術問題。致力於為勇於創新的開發者們提供行業內最前沿最熱門的技術乾貨，以技術驅動應用創新，讓更多的開發者享受技術帶來的生活樂趣。
遊戲從開發到上線的流程
現如今，我們經常都能看到遊戲的收購新聞，讓很多創業蠢蠢欲動，紛紛想踏入這個市場，又怕自己什麼都不知道，受到欺騙。今天就簡單總結一下遊戲從開發到上線的具體步驟，經歷的具體過程包括 1.調查市場，做出開發某款棋牌遊戲的決定。2.準備好自己的開發需求和遊戲的具體玩法 功能設定，找到優秀的開發商。3.投資者...
新產品從開發到上市的階段流程
產品構思與選取 這個階段主要是尋求產品構思，並不是每個企業都把這個階段作為流程的正式階段，但是，它卻是產品創新過程的乙個必經的階段，因為，任何乙個可產品化的構思 都是從無數多個構思中篩選而來的，這個階段的過程管理往往是非常開放的，它們可以來自於客戶 合作夥伴 售後 市場 製造以及研發內部，這些來自各...
nuxt從開發到部署
經過幾個週六週日的嘗試，終於解決了服務端渲染中的常見問題，也成功說服了公司新專案採用前後端分離的解決方案，當seo不在是問題的時候，或許才是我們搞前端的真正的春天，其中也遇到了一些小坑，nuxt.js官方還是很給力的，提issue後很積極的給予幫助，再次感謝nuxt.js的開發團隊。第乙個攔路虎就是...