Hyperloop 是什么？

Hyperloop 是服務(wù)于美團(tuán)點評客戶端的組件發(fā)版、持續(xù)集成、App 打包構(gòu)建、資源調(diào)度等各個環(huán)節(jié)的發(fā)布調(diào)度系統(tǒng)。名稱起源于美國 Elon Musk 構(gòu)想的 Hyperloop 超級高鐵，象征著現(xiàn)代、簡潔、高效。

Hyperloop 提供了一站式的平臺，管理著美團(tuán)點評 iOS 業(yè)務(wù)的超過 300 個組件和包括美團(tuán) iOS 客戶端在內(nèi)的4個App。接入 Hyperloop 系統(tǒng)后，開發(fā)同學(xué)可以通過 Hyperloop 來管理自己的項目，配置發(fā)版和打包所需要的步驟和檢查項。開發(fā)完成時，用戶只需要登錄 Hyperloop 進(jìn)行相關(guān)操作，Hyperloop 就會根據(jù)項目的配置去調(diào)用不同的步驟，上報每個步驟的狀態(tài)，給出錯誤日志、狀態(tài)通知等。

為什么要有 Hyperloop？

說到發(fā)布，我們首先想到的就是持續(xù)集成和交付，而說到持續(xù)集成和交付，我們又會自然而然地想到 Jenkins。沒錯，我們之前的所有和發(fā)布工程相關(guān)的流程都是與 Jenkins 密切相關(guān)，其任務(wù)的調(diào)度、自動化的構(gòu)建等功能深受我們的喜愛。

可是隨著我們的業(yè)務(wù)爆發(fā)式的增長，加之對 Jenkins 的深入使用，一些問題逐漸暴露出來了：

1. 使用和維護(hù)成本加大

業(yè)務(wù)量的增多，導(dǎo)致參與到整個發(fā)布流程中的同學(xué)也越來越多，而因為 Jenkins 偏向于專業(yè)的配置和運維步驟，給我們普通的開發(fā)同學(xué)帶來很多 Jenkins 的使用和維護(hù)上的問題，讓我們發(fā)布工程的同學(xué)不得不花大量的時間來進(jìn)行答疑和維護(hù)。

2. Jenkins Job 的數(shù)量增多

Jenkins 中存在的 Job 數(shù)量也隨著業(yè)務(wù)的擴(kuò)張而變的十分龐大。

| 一級目錄數(shù)量 | 總 Job 數(shù)量 | | :—–: | :——: | | 74 | 569 |

為什么會有這么多的任務(wù)呢？因為我們發(fā)布流程會提供一些必要的功能，而每個業(yè)務(wù)方在使用這些功能的時候需要配置一些自己的業(yè)務(wù)參數(shù)，出于 Jenkins 的一些局限性，常規(guī)的做法就是復(fù)制一份示例 Job 然后改成自己的構(gòu)建任務(wù)。

所以說這么多的業(yè)務(wù)方乘以這么多的業(yè)務(wù)，就造就了這么多的 Job……

這么多的 Job 帶來了不小的問題，不管是新策略的推廣，還是 Job 的維護(hù)都是 N 倍的工作量。

3. 構(gòu)建數(shù)據(jù)難以統(tǒng)計

這么多的 Job，結(jié)果基本上沒有辦法集中統(tǒng)計。此外，Jenkins 中數(shù)據(jù)分析和呈現(xiàn)能力偏弱，而數(shù)據(jù)對于我們現(xiàn)如今的開發(fā)是尤為重要的，不僅能夠反應(yīng)出我們的工作成果，還能及時反饋出我們工作中的問題。

有人會說，我們可以利用 Jenkins 插件來解決上述的問題。

的確，Jenkins 憑借著自己豐富的插件和較為成熟的社區(qū)，有著較高的拓展性，但是經(jīng)過我們的調(diào)研和評估，發(fā)現(xiàn)由于整個系統(tǒng)的設(shè)計并不是一個集中式的管理系統(tǒng)，所以很多功能都局限于 Job 而非系統(tǒng)層面。

另外，由于對于數(shù)據(jù)的收集和存儲能力偏弱，所以我們經(jīng)常要考慮如何解決數(shù)據(jù)保存的問題。

如果能夠完美的解決上述問題，從成本上來說，通過對 Jenkins 的二次開發(fā)的性價比相較于打造一個全新的系統(tǒng)就低了很多。

因此，我們認(rèn)為一個擁有中央調(diào)度功能的系統(tǒng)可以為我們整個項目帶來諸多便利，所以打造一個 Hyperloop 這樣的系統(tǒng)的想法應(yīng)運而生。

如何去搭建 Hyperloop？

1. 系統(tǒng)架構(gòu)

從技術(shù)角度劃分，我們把 Hyperloop 劃分為 Web 前端、后端和工具鏈。前端專注于良好的用戶交互和清晰的數(shù)據(jù)展示，后端則負(fù)責(zé)數(shù)據(jù)收集分析、業(yè)務(wù)處理和任務(wù)調(diào)度，而工具鏈?zhǔn)秦?fù)責(zé)具體的發(fā)版、集成等任務(wù)的執(zhí)行。

后端接受來自前端用戶觸發(fā)的操作，反饋數(shù)據(jù)或者調(diào)用工具鏈執(zhí)行相關(guān)任務(wù)，所有的任務(wù)數(shù)據(jù)流都流經(jīng)后端，從而能夠保證構(gòu)建數(shù)據(jù)的完整性。

2. 業(yè)務(wù)模型

插件化檢查方式

組件的發(fā)布和集成階段都需要有準(zhǔn)入，但實際上每個組件的準(zhǔn)入步驟并不一定完全一致，并且隨著業(yè)務(wù)的需要，準(zhǔn)入步驟也會相應(yīng)的調(diào)整。面對這樣的需求，將準(zhǔn)入步驟插件化則是一個比較靈活方式。

能力

工具鏈會先行開發(fā)準(zhǔn)入步驟，這是一個可以接受參數(shù)的 fastlane 的 action。完成開發(fā)后，我們會在 Hyperloop 后臺上線對應(yīng)的能力。

組件在自己的設(shè)置界面可以看到 Hyperloop 中所有已上線的能力，有一些是必選的，則默認(rèn)就已經(jīng)選上了，其他非必選的能力，則有該組件配置權(quán)限的同學(xué)可以根據(jù)自己業(yè)務(wù)需要勾選。

有一些檢查，例如 warning 數(shù)，是可以設(shè)置一個目標(biāo)值的，在未來的某個時間點達(dá)到什么樣的目標(biāo)，之后每一次準(zhǔn)入都會由后臺動態(tài)計算本次需要達(dá)到的目標(biāo)。

App 的打包集成準(zhǔn)入則是通過打包模板的方式來配置準(zhǔn)入步驟，相較于發(fā)版的簡單方式，集成打包則需要有多種情況供用戶選擇。除了和組件一樣，可以配置目標(biāo)值，打包模板還可以靈活設(shè)置參數(shù)配置方式。

策略

將某個能力勾選之后，組件或者打包模板中就會生成對應(yīng)的策略，不同于能力的是，策略中保存了組件或打包模板中業(yè)務(wù)方配置的參數(shù)。

步驟

每一次組件發(fā)版，每一次集成打包，都會生成一個版本，Hyperloop 后臺會根據(jù)能力和策略生成本次執(zhí)行時具體的步驟，和策略類似，不過步驟中參數(shù)則是更為具體的值。

隨著發(fā)版和集成任務(wù)被觸發(fā)，工具鏈被調(diào)用后會請求 Hyperloop 后臺，下發(fā)本次執(zhí)行的步驟，工具鏈拿到后就會按照具體的步驟和參數(shù)來執(zhí)行任務(wù)了。

這樣插件化的模型設(shè)計，大大減少了工具鏈的開發(fā)成本，并且增加了整個準(zhǔn)入步驟的靈活性，更加符合業(yè)務(wù)方自己的需求。

3. 功能實現(xiàn)

組件發(fā)版

組件是支撐整個美團(tuán) iOS 客戶端的基礎(chǔ)，前面也提到了，現(xiàn)在有超過300個組件通過我們的這個系統(tǒng)來發(fā)布，而在整個開發(fā)周期中，又有超過700次的發(fā)布需求。而作為整個客戶端的發(fā)布流程的起點，組件發(fā)版又有著尤為重要的作用，所以在整個系統(tǒng)搭建之初，組件發(fā)版是我們優(yōu)先考慮的功能。

在第一階段，我們實現(xiàn)了基本的組件發(fā)布能力，業(yè)務(wù)方已經(jīng)可以通過 Hyperloop 來對自己的業(yè)務(wù)組件進(jìn)行發(fā)版。

但是對于一個全新的發(fā)布調(diào)度系統(tǒng)，僅僅用于發(fā)版是遠(yuǎn)遠(yuǎn)不夠的，既然我們可以做到數(shù)據(jù)的匯總分析，那么就可以通過在準(zhǔn)入中添加一些特殊的能力，使項目中一些可以優(yōu)化的指標(biāo)得以實現(xiàn)，例如 warning 數(shù)的分析和限制。所以在完成了基本的發(fā)版準(zhǔn)入后，我們又增加了一些可選的優(yōu)化能力。

提到限制，可不僅僅是設(shè)置一個數(shù)值這么簡單，Hyperloop 允許用戶設(shè)置目標(biāo)值和目標(biāo)時間，動態(tài)地計算出每一次需要達(dá)到的數(shù)值，從而通過程序這種強制性的手段，來實現(xiàn)工程上面的優(yōu)化。

有了準(zhǔn)入限制，只能說完成了這個功能的一大部分，數(shù)據(jù)的的展示有多種多樣，既然我們拿到了組件發(fā)布時的全部數(shù)據(jù)，那就讓它有一個很好的展示。所以第三階段，我們又完善了整個組件發(fā)布的信息，以及添加了一些功能性的能力，例如 Changelog 的生成，以豐富整個發(fā)布過程，讓用戶能夠更清楚地了解到這一次發(fā)布的狀況。

如果發(fā)布失敗了，我們會在出錯的步驟中展示錯誤的原因和建議，以及出錯的 log，方便大家調(diào)查出錯原因。

打包集成

組件發(fā)布后，就去集成到美團(tuán) iOS 客戶端的主工程里面，所以完成了發(fā)布功能后，我們就開始著手實現(xiàn)打包集成。

作為美團(tuán)點評最大的 iOS 項目之一，美團(tuán) iOS 客戶端不管是從業(yè)務(wù)量級，還是整個打包集成發(fā)布的流程，都是非常復(fù)雜的，參與 RD 人數(shù)也很多。當(dāng)我們對全公司 iOS 項目分析后發(fā)現(xiàn)，如果實現(xiàn)了美團(tuán) iOS 客戶端的打包集成，那么別的獨立 App 也都能夠適用。

在這個功能的第一階段，我們簡單的適配了之前的集成流程，為了讓整個發(fā)版集成流程盡早可以完整的連起來。滿足了基本可用的條件后，我們參考組件發(fā)布的步調(diào)，開始完善整個集成的流程。第一步，就是增加準(zhǔn)入限制。

如果說組件發(fā)版是整個美團(tuán) iOS 客戶端搭建的第一步，那么集成就是第二步，也是至關(guān)重要的一步。作為集成來講，準(zhǔn)入尤為重要，可以說客戶端的各項性能指標(biāo)是否符合要求，基本上就看集成準(zhǔn)入是否能夠過濾掉不合格的組件。

所以我們會在基本的集成能力中加入例如包大小檢查這樣的增強型準(zhǔn)入檢查，而在集成包構(gòu)建完成之后，會進(jìn)行自動化測試，保證本次集成除了沒有編譯錯誤，還不會有運行時問題。

當(dāng)然了，作為二進(jìn)制集成，我們還需要保證我們的組件間 APIs 調(diào)用正確，所以我們還會進(jìn)行全源碼編譯，來確保沒有調(diào)用不一致的問題。

同樣，Hyperloop 在集成時所收集的信息，都會展示出來。不同于組件發(fā)布，集成后有諸多產(chǎn)物，各位 RD 可能會有下載需求，我們還會把所有的產(chǎn)物都打包上傳到美團(tuán)云上，提供下載鏈接。

我們雖說有內(nèi)部的分發(fā)平臺，但是高頻次的集成帶來的集成包數(shù)量也是非常多的，在集成詳情界面提供可以掃一掃就能下載的二維碼，方便 RD 和 QA 下載下來驗證自己的需求。

除了集成，我們還有個很重要的功能就是打包。作為一些小一點的業(yè)務(wù)方，自己并沒有什么集成的需求，而更多的是希望能夠按照自己的需求來打一個包出來。例如用于驗證功能的 feature test，用戶每日構(gòu)建的 daily build，或者說用于提交 iTC（iTunes Connect） 的 App Store build。

之前的做法是，業(yè)務(wù)方自己創(chuàng)建 Jenkins job，自己配置構(gòu)建腳本，雖說業(yè)務(wù)方之間任務(wù)獨立，但是基本上很大程度都是重復(fù)的。

Hyperloop 為各業(yè)務(wù)方提供通用的打包能力，業(yè)務(wù)方可以根據(jù)需求組成自己的打包模板，每一次打包的時候只需要根據(jù)自己的需求選擇相應(yīng)的打包模板即可。

雖說能力都有參數(shù)，但是在設(shè)置打包模板的時候可以固定配置一些參數(shù)，簡化每一次的操作步驟，甚至像 App Store build 就可以做到完全零配置，點一下打包即可完成構(gòu)建觸發(fā)。

同樣的，完成打包后，相應(yīng)的界面也能看到本次構(gòu)建的詳細(xì)信息。

去 Jenkins 化

從一開始我們就提到 Jenkins 對于我們普通的 iOS 開發(fā)者而言，不管是使用成本還是維護(hù)成本都是比較高的，而其他方面諸多限制致使我們想要搭建一個這樣的系統(tǒng)。

雖說是因為要去 Jenkins，但是我們在一開始也只是降低了對 Jenkins 的依賴，但還是利用 Jenkins 來分配執(zhí)行任務(wù)。

而仔細(xì)審視一下，我們不難發(fā)現(xiàn)，我們對 Jenkins 的使用也僅僅是分配任務(wù)了，為了這一個簡單的需求我們還要保留 Jenkins，維護(hù)兩套系統(tǒng)，并且通過系統(tǒng)間 APIs 來通信，非常惡心。

比較巧合的是，后臺和工具鏈都是 Ruby 棧的，這樣來看，工具鏈完全可以成為后臺模塊中的一部分，通過消息隊列就能達(dá)到我們想要的效果，并且直接對數(shù)據(jù)庫的操作，統(tǒng)一的功能開發(fā)，也讓整套邏輯變得十分優(yōu)雅。

這樣來看，Jenkins 就徹底的從我們的視線中消失了。

通知能力

如何才能讓用戶知道整個流程的結(jié)果？如何才能更好地向用戶反饋出現(xiàn)的問題？除了前端界面展示詳細(xì)數(shù)據(jù)外，主動通知能力也是個非常重要的功能，畢竟大家不可能一直守在 Hyperloop 面前。

我們提供有內(nèi)部 IM 工具（大象）的消息通知，重要的問題我們還有郵件通知。

如果出現(xiàn)問題，用戶會第一時間收到來自 Hyperloop 的消息，當(dāng)然了，如果順利結(jié)束，系統(tǒng)也會恭喜你順利完成了此次構(gòu)建。

除了常規(guī)的構(gòu)建通知，一些重要事項的提醒我們也是有能力告知的，例如開發(fā)者證書是否要過期？ Provisioning Profile 是否要更新？Hyperloop 有什么需要通知大家的新聞等等……

能否解決我們的問題？

說了這么多，Hyperloop 是否能夠解決我們之前所遇到的問題呢？

1. 通過新版工具鏈和系統(tǒng)后臺解決 Jenkins 所帶來的問題

我們通過新的系統(tǒng)來取代 Jenkins，人性化的界面和交互流程，清晰的信息展示和問題反饋，基本上讓用戶能很輕松地完成自己的發(fā)布流程，大大降低了他們的學(xué)習(xí)操作成本。

2. 中央集中式系統(tǒng)取代分散式的管理方式

Hyperloop 是一個中央集中式的系統(tǒng)，所有的業(yè)務(wù)方可以根據(jù)自己的業(yè)務(wù)來使用我們提供的能力，減少了各自為政所帶來的冗余，重復(fù)的任務(wù)配置，也方便我們流程維護(hù)和技術(shù)升級。不管是運維成本還是技術(shù)推動成本都極大地降低。

3. 著重凸顯數(shù)據(jù)的重要性

不同于之前的流程，Hyperloop 有著強大的數(shù)據(jù)匯總和分析能力，由于對于整個流程的參與，所有的信息都存儲在 Hyperloop 中，方便分析和展示。作為日常工作的重要指標(biāo)，數(shù)據(jù)扮演著尤為重要的角色。

有了數(shù)據(jù)，我們就能從數(shù)據(jù)中發(fā)現(xiàn)問題，解決問題，從而優(yōu)化我們的項目，也能從方向性上提升我們的工作效率。

展望未來

Hyperloop 雖說已經(jīng)能夠處理解決大多數(shù)發(fā)布流程相關(guān)的任務(wù)，但是未來依然任重而道遠(yuǎn)。

1. 監(jiān)控統(tǒng)計

雖說我們能夠匯總和分析數(shù)據(jù)，但是很多方面的監(jiān)控和統(tǒng)計力度仍然不夠，例如靜態(tài)分析問題，重復(fù)代碼檢查等等。只有不斷豐富整個工程中的監(jiān)控指標(biāo)，才能逐漸暴露出隱藏在項目中的一些問題，解決并且優(yōu)化整個項目。

2. 上下游關(guān)系

目前整個 Hyperloop 上下游中已經(jīng)充斥著 Git 托管平臺，美團(tuán)云，iTC 以及 IM 等諸多系統(tǒng)，可是作為整個開發(fā)流程來講，我們可能還需要和更多系統(tǒng)之間的通信，例如在構(gòu)建完成后可以自動管理相應(yīng)的任務(wù)，可以在一個階段完成后自動產(chǎn)生一個統(tǒng)計報表輸出到 wiki 中等等。通過上下游多系統(tǒng)聯(lián)動，從而進(jìn)一步提升我們的開發(fā)效率。

3. 多端支持

Hyperloop 目前僅僅是支持 iOS 業(yè)務(wù)，但是整個發(fā)布工程可是不限于 iOS 的，所以我們未來希望能夠讓所有還在發(fā)布工程中掙扎的同學(xué)們都能搭乘上 Hyperloop，讓開發(fā)專注于開發(fā)的本質(zhì)，發(fā)布僅僅是點一個鍵的事情。

4. 流程優(yōu)化

上面也提到過，我們一些功能是延承自之前的流程，而作為一個全新的系統(tǒng)，我們完全可以用更高效的流程來提升構(gòu)建效率，運用政治經(jīng)濟(jì)學(xué)中生產(chǎn)力和生產(chǎn)關(guān)系的理論，我們有了更強大的生產(chǎn)力，那也需要有與之相適應(yīng)的生產(chǎn)關(guān)系才能保證和進(jìn)一步提高生產(chǎn)力。流程，正是如此。

我們做了這么多，其實本質(zhì)就是讓 RD 專注于開發(fā)，減少無謂的時間消耗，而發(fā)布的事情就讓系統(tǒng)化的東西來解決。同時又能通過集中式的系統(tǒng)來保證整個流程的管控力度和數(shù)據(jù)統(tǒng)計，從另一個方面反推我們的開發(fā)。這就是 Hyperloop 名字的意義，不僅僅是個 loop，還是個現(xiàn)代、簡潔、高效的 loop。

作者簡介

恩生（@zesming），美團(tuán)點評高級工程師，2014年加入原美團(tuán)，曾負(fù)責(zé)美團(tuán) iOS 客戶端的首頁、訂單等重要業(yè)務(wù)。目前負(fù)責(zé) iOS 發(fā)布工程的流程制定、Hyperloop 的功能設(shè)計和整個系統(tǒng)后臺開發(fā)。

總結(jié)

以上是生活随笔為你收集整理的Hyperloop，让发布简洁高效的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。