monorepo

CodePen的DevOps實踐：回歸單體代碼庫(monorepo)的優勢

雖然我不是大型DevOps專家，但CodePen正在轉向單體代碼庫(monorepo)，這與多個小型代碼庫的系統相比，具有諸多優勢，至少對我們而言是如此。您的挑戰和結論可能完全不同。

我讀了Ben Nadel的“為什麼我在InVision將微服務合併回單體架構”後，想到了這一點。儘管我們的結論相似，但我可以看出他面臨著一組完全不同的問題。

微服務解決技術和人員問題

技術問題是指應用程序的某個方面給基礎設施帶來了過大的負擔，進而可能導致糟糕的用戶體驗(UX)。例如，圖像處理需要大量的CPU。如果此CPU負載過大，它可能會開始使應用程序的其他部分缺乏處理資源。這可能會影響系統延遲。而且，如果情況嚴重到足以影響系統可用性。

人員問題另一方面，與應用程序幾乎無關，而與團隊的組織方式有關。在應用程序的任何給定部分工作的人員越多，開發和部署就越慢，越容易出錯。例如，如果您有30名工程師都在爭先恐後地“持續部署”(CD)相同的服務，那麼您將獲得大量的排隊；這意味著，許多本來可以交付產品的工程師實際上是在等待輪到他們部署。

單體代碼庫(monorepo)的優勢（對我們而言）

• 一統天下。您只需git pull一個代碼庫，就能與其他人完全同步，並擁有完整開發環境所需的一切。
• 井然有序。 GitHub上的操作位置不會造成混淆。您針對單體代碼庫進行拉取請求。您在單體代碼庫上打開問題。這避免了分散的活動而導致信息丟失。
• 代碼共享。您可以共享代碼。在整個代碼庫中共享實用程序或組件特別有用。我們嘗試過將共享部分發佈到npm供其他代碼庫使用，但與在一個地方擁有代碼相比，該工作流程很笨拙。
• 統一維護。只有一個代碼庫，不存在舊的和被忽略的代碼庫。對於我們的小團隊來說，擁有數十個代碼庫意味著其中一些代碼庫具有舊的過時依賴項、舊版本的Node、與其他代碼庫不同步的代碼風格檢查和格式化規則等。

單體代碼庫(monorepo)的劣勢（對我們而言）

• 部署複雜性。我認為我們最初拆分代碼庫的主要原因是這些代碼庫中的代碼需要部署到不同的位置。它們可能代表某個單獨的Lambda或其他服務器上的單獨服務。單個代碼庫意味著更容易連接特定於該服務器/服務的組件，例如CI/CD。

是的，我知道這有爭議。

我其實不太在意。我不會像空氣炸鍋愛好者和CrossFit狂熱者那樣對此過於激烈。這是Matt Klein對單體代碼庫的強有力論證。

我只是說：這對我們來說非常有用。我可以看出其他公司的情況會有所不同。我可以看出，與承包商合作的公司可能希望將其訪問權限限制在小於整個單體代碼庫的範圍內。我可以看出git代碼庫可能會變得龐大而難以管理。這些目前對CodePen來說都不是問題，因此單體代碼庫的優勢勝出。

以上是monorepo的詳細內容。更多資訊請關注PHP中文網其他相關文章！