初創企業如何實現2天快速上線？

摘要： 初創企業在業務快速發展中，如何利用有限的資源，作高效快速迭代？如何減小手工操做的依賴，提升發佈效率，將跨組織的項目溝通效率提高50%？

雲小妹導讀：初創企業在業務快速發展中，如何利用有限的資源，作高效快速迭代？如何減小手工操做的依賴，提升發佈效率，將跨組織的項目溝通效率提高50%？

最近，初創企業愛賽因斯在雲效公有云上試點，實現初始項目2天上線的可喜成果。

本文做者：孫志梁，愛賽因斯技術總監，主要負責各業務線的技術開發和團隊管理工做。

案例重點介紹

經過雲效流水線功能大大提高了內部研發項目的發佈效率和質量，實現初始項目2天快速上線。外部託管項目經過雲效需求管理、缺陷管理功能，有效提高了工做效率，在與外部客戶、供應商的溝通效率上提高了50%以上。

關於愛賽因斯

愛賽因斯是一家以創新驅動的數字化信息服務集團公司，旗下擁有PMCAFF、外包大師、Nework、知一諮詢、光合孵化器、X-CLUB等子品牌，業務類型涵蓋社區、活動/會議、培訓、產品諮詢、軟件信息及研發、區塊鏈及相關服務、人才顧問及投資、創新項目投資孵化等。已得到爾法公社Pre-A輪融資。

其中外包大師做爲一個互聯網產品技術外包管理服務平臺，爲委託方提供從產品諮詢、設計、開發直至上線的全流程服務，因此除了咱們內部研發項目外，還有不少外部客戶委託的項目，這一類項目由甲方把項目需求委託給外包大師，外包大師會匹配和簽約外部供應商，而且對項目進行管理驗收，完成甲方需求。

愛賽因斯的痛點

• 內部項目

項目依賴較多手工操做，發佈效率低下並且難以造成知識積累。在項目上線時，構建部署主要都是人工在服務器上進行，安裝構建工具、執行構建過程均可能會遇到各類問題和進行解決，耗費時間比較長，即便有文檔或者操做手冊，又每每存在更新不及時的問題，新同窗通常要經過屢次詢問和本身登陸服務器操做等方式才能肯定正確的構建和發佈步驟。

發佈出錯率高，沒有有效的回滾機制。不少項目類型的開發語言是PHP等腳本語言，部署方式是在服務器的部署路徑下直接更新代碼，而且直接在部署路徑進行構建，一旦操做錯誤或者遺漏，就會影響線上服務。同時一旦發佈出現問題，判斷回滾的版本須要人工根據代碼提交記錄進行肯定，耗時長且容易回滾出現新的問題。

• 外部項目

沒有一個很好的協同管理工具能把流程串起來.外包大師項目總體項目週期偏長，大部分項目週期都超過1個月，以前對於交付鏈條很長的項目管理過程，更多的是經過一系列不一樣的工具管理項目實施的不一樣階段，好比石墨文檔、Teambition、Project、Jira等，很長時間內，並無找到一個很好的協同管理工具能一次性的串起這個流程，並解決其中的衆多問題。如：需求變動管理，版本迭代管理、成員權限管理、代碼分支管理、問題追蹤管理等等。

採用了哪些阿里雲產品？

• 阿里云云效一站式研發協同解決方案
• ARMS業務實時監控服務

爲何選擇阿里云云效？

內部項目

對內部項目，咱們主要想提升發佈效率和穩定性，同時減小構建和部署環節對人工操做的依賴。考慮過三個方案：

1. 使用Jenkins或者Teamcity等持續集成解決方案
2. 阿里雲的codePipeline
3. 阿里云云效

評估下來方案一雖然比較靈活，能夠知足需求，但初始的安裝配置成本和維護成本都比較高，並且做爲基礎設施服務一旦出現問題，團隊目前並不擅長解決，因此放棄。

方案二codePipeline很早以前使用過，功能相對單一，主要提供流水線服務，界面操做也不夠友好，和雲效相比，確定是優先選擇功能更豐富，使用更友好的雲效。

在雲效的使用上，咱們採用了新項目先嚐試，老項目後遷移的思路，一方面積累雲效使用經驗，同時也避免由於研發流程調整影響已有項目的迭代和穩定性。

目前咱們一個項目在雲效上從開始準備部署到可訪問，通常須要0.5天~2天（取決因而否以前已經配置過相同類型的項目），會經歷如下步驟：

第一天

1.採購和添加服務器 （耗時1h,若是以前沒有相同環境，須要安裝運行環境0.5d）

建立用於測試環境或者生產環境的ECS，在雲效企業設置中添加主機到雲效。咱們針對不一樣的語言運行環境建立了不一樣的鏡像，作到購買ECS後，不須要額外配置就能夠立刻投入使用。

2. 建立雲效應用 （耗時1h）

每一個能夠獨立進行構建和部署的研發項目，註冊爲一個應用。指定代碼倉庫、所屬項目以及項目語言類型，在雲效中建立應用。

3. 配置流水線 （耗時2h）

雲效配置流水線頁面

咱們的流水線通常只保留兩個步驟，構建和部署，測試環境的部署和正式環境的部署拆分爲多個流水線。若是是以前沒有配置過的項目類型，構建命令和部署命令通常是須要調試時間比較長的：

a)  構建命令，不一樣語言構建命令不同。咱們公司主要使用的PHP七、Java八、Nodejs8在雲效默認的構建環境已經都支持了。

b)  配置應用環境，爲應用的每一個環境指定服務器和部署路徑、部署命令。

構建命令和部署命令均可以，能夠先在服務器或者本地手動執行構建成功後，再配置到雲效，後續相同類型的項目能夠進行復用。

次日

4. 構建和部署 （耗時1h）

雲效構建部署頁面

流水線編輯完成後，就能夠運行調試了，順利的話能夠一次性成功，實際是每每由於代碼問題或者服務器環境致使不能一次性成功，好在雲效在構建和發佈階段都有詳細的日誌輸出，能夠看到構建命令和部署命令的執行過程和輸出，用於排查和修復問題。

5. 訪問入口配置 （耗時1h）

流水線運行成功後，應用已經能夠對外提供服務了，咱們的大部分項目都是web項目，這個時候會新建負載均衡指向新部署的服務，接着配置域名到負載均衡的IP地址，就能夠提供給測試同窗測試或者用戶訪問使用了。

6. 異常回滾 （耗時<1h）

平常發佈會，不免會有一些狀況致使線上服務運行異常，

藉助實時業務監控（arms），能夠把關鍵錯誤日誌、核心業務指標有效監控起來， 一旦發佈後收到報警或者指標異常 ，在雲效中直接操做回滾就能夠，雲效的回滾會清晰的列出歷史版本用於選擇，同時回滾直接使用以前構建成功的結果，不須要從新構建，回滾速度比手動服務器操做要快出一個數量級。

在經過新項目中熟悉了雲效的使用並體驗到雲效帶來的便利後，咱們把老項目也進行了遷移，這樣在雲效中，就能看到公司全部的研發項目，很大程度上避免了黑盒子項目的存在。

• 外部項目

在外面委託項目中，咱們做爲平臺方，須要協調甲方客戶和乙方供應商團隊，雲效平臺正好解決了在線協同問題，把甲乙方很好的聯繫在一塊兒。

以下圖：可經過成員管理把甲方參與人員和乙方開發團隊添加到項目成員中，甲方能夠看到項目實際進展，乙方也能夠及時更新項目進展。

雲效跨企業協做項目溝通

進度管理：當項目經理將工做包拆解到具體模塊並指定開發負責人後，負責人可按實際完成狀況勾選任務，就能夠相對準確的顯示項目的實際進度。

雲效進度跟蹤頁面

範圍管理：對於項目實施過程當中，新增的需求，產品經理能夠經過手動添加和自動導入兩種方式更新或調整需求，並按模塊和版本進行分配責任人，以下圖：

雲效項目權限分配頁面

效果檢驗：開發完成的代碼推送到遠端分支，就能夠自動部署到到測試環境，平臺QA和甲方客戶就能夠可及時檢驗效果。

雲效頁面截圖

 

BUG追蹤：測試負責人能夠添加BUG修復任務到缺陷模塊 並指定任務負責人，對於開發團隊成員，能夠單獨查看本身名下的待解決BUG，以下圖：

雲效頁面截圖

得到的成效

雲效平臺在咱們的內部研發項目的迭代開發和外部託管項目全週期管理中發揮着重要做用，從使用先後的一些數據顯示研發效能上有了顯著提高。

• 內部項目

1. 發佈效率：10分鐘的手動命令行操做 -> 5分鐘的界面自動化操做。

2. 回滾速度：10分鐘人工確認操做-> 2分鐘自動化操做。

3. 發佈質量：手動發佈/回滾出錯或者遺漏：10% -> 無。

4. 新人學習發佈上手時間：2天->0.5天。

5. 研發項目基礎信息：我的經驗和口口相傳 -> 清晰可靠的系統記錄。

• 外部項目

1. 多方協同再也不須要經過每日例會或日報的形式彙報項目進展，參與項目的甲方、平臺方、分佈式研發團隊均可以直觀的看到項目進展，溝通效率提高了50%以上。

2. 需求可按模板導入，對於大量需求須要初始化錄入時，導入的功能大大提升了效率，以及新增需求的錄入、管理等，相比以前人工經過Excel更新功能列表並同步給項目團隊，總體範圍管理的效率提高了30%。

3. 代碼的自動化構建部署，驗收效率提升了20%。

原文連接