本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
# 組織和工作方式
如同所有架構策略，微型前端的影響遠遠超過組織選擇實作的技術。建立微型前端應用程式的決定必須符合業務、產品、組織、營運，甚至文化 （例如，授權團隊和分散決策）。相反地，這種類型的微型前端架構支援真正敏捷、產品驅動的開發，因為它可大幅降低其他獨立團隊之間的通訊負荷。
## 敏捷開發
敏捷軟體開發的概念近幾年來變得非常普遍，幾乎每個組織都聲稱能夠敏捷地工作。雖然*敏捷*性的最終定義超出此策略的範圍，但值得檢閱與微型前端開發相關的關鍵元素。
敏捷範式的基礎是 [Agile Manifesto](https://agilemanifesto.org/) (2001)，其推斷了四個主要原則 （例如，「個別和程序與工具的互動」) 和十二個原則。Scrum 和 Scaled Agile Framework (SAFe) 等程序架構已在 Agile Manifesto 周圍出現，並已進入日常實務。不過，背後的理念在很大程度上被誤解或忽略。
在微型前端架構的情況下，以下敏捷性原則對於接受很重要：
+ 「經常交付工作軟體，從幾週到幾個月，偏好較短的時間範圍。」
此原則強調以增量方式運作，並盡可能定期將軟體交付至生產環境的重要性。從技術角度來看，這是指持續整合和持續交付 (CI/CD)。在 CI/CD 中，用於建置、測試和部署的工具和程序是每個軟體專案不可或缺的一部分。權限也表示執行期基礎設施和營運責任必須由 團隊擁有。該擁有權在分散式系統中特別重要，其中獨立子系統對基礎設施和操作的需求可能明顯不同。
+ 「圍繞積極的個人建立專案。為他們提供所需的環境和支援，並信任他們完成任務。」
「最佳架構、需求和設計來自自我組織團隊。」
這兩個原則都強調擁有權、獨立性和end-to-end責任的優勢。當 （且僅當） 團隊真正擁有其微型前端時，微型前端架構將會成功。從概念到設計和實作，再到交付和操作的End-to-end責任，可確保團隊可以實際行使所有權。在技術和組織方面，團隊需要這種獨立性，才能對策略方向擁有自主性。我們不建議在使用瀑布開發模型的集中式組織中使用微型前端平台。
## 團隊組成和大小
若要讓軟體團隊行使擁有權，必須在組織施加的界限內自行管理，包括團隊交付的方式和內容。
為了有效，團隊必須能夠獨立交付軟體，並有權決定交付軟體的最佳方式。在未參與這些項目的規劃的情況下，從外部產品管理員或外部設計人員的 UI 設計接收功能需求的團隊無法視為自主。這些功能可能會違反現有的合約或功能。這類違規需要進一步的討論和交涉，可能會有延遲交付並導致團隊之間不必要的衝突的風險。
同時，團隊不應變得太大。雖然較大的團隊有更多資源，可以容納個別的缺席，但每個新成員的溝通複雜性呈指數增長。無法陳述通用有效的團隊大小上限。專案所需的人數取決於團隊成熟度、技術複雜性、創新速度和基礎設施等因素。例如，Amazon 遵循兩比薩規則：太大而無法在兩個比薩上饋送的隊伍應分割成較小的隊伍。這可能是一項挑戰。分割應該沿著自然界限進行，並且應該讓每個團隊對其工作擁有自主性和擁有權。
## DevOps 文化
DevOps 是指從組織和技術角度緊密整合開發生命週期步驟的軟體工程實務。與熱門的信心相反，DevOps 非常重視文化和思維，幾乎不重視角色和工具。
傳統上，軟體組織會有專家團隊，例如設計、實作、測試、部署和操作。每當團隊完成任務時，就會將專案交給下一個團隊。不過，透過專業團隊孤島交付軟體會在交接期間造成摩擦。同時，當專家被迫使用窄焦時，他們缺乏相鄰網域的知識，而且他們沒有產品的系統檢視。這些缺陷可能會導致軟體產品的一致性低。
例如，當軟體架構師設計將由不同團隊中的某人實作的解決方案時，他們可能會忽略實作的固有層面 （例如相依性不相符）。然後，開發人員會採取捷徑 （例如猴子修補程式），或在架構師和開發團隊之間啟動正式back-and-forth。由於管理這些程序的額外負荷，開發不再靈活 （從彈性、適應性、增量和非正式的角度而言）。
雖然 DevOps 一詞主要與文化相關，但它暗示了讓 DevOps 實際可行的技術和程序。DevOps 與 CI/CD 密切相關。當開發人員完成實作軟體增量時，他們會將其遞交至版本控制系統，例如 Git。傳統上，建置系統會建置和整合軟體，並使其在更或更不統一和集中的程序中進行測試和發行。透過 CI/CD，軟體的建置、整合、測試和發行是固有且自動化的。理想情況下，程序是透過專門針對指定專案量身打造的組態檔案，成為軟體專案本身的一部分。
盡可能多的步驟是自動化的。例如，應減少手動測試實務，因為幾乎所有類型的測試都可以自動化。以這種方式設定專案時，軟體產品的更新可以每天交付數次，並且具有高可信度。支援 DevOps 的另一項技術是基礎設施即程式碼 (IaC)。
傳統上，設定和維護 IT 基礎設施需要手動工作來安裝和維護硬體 （在資料中心設定纜線和伺服器） 和操作軟體。這是必要的，但有許多缺點。設定耗時且容易出錯。硬體通常過度佈建或佈建不足，導致過度花費或效能降低。透過使用 IaC，您可以透過可自動部署和更新雲端服務的組態檔案來 描述 IT 系統的基礎設施需求。
這與微型前端有什麼關係？ DevOps、CI/CD 和 IaC 是微型前端架構的理想補充。微型前端的優勢取決於快速且無摩擦的交付程序。DevOps 文化只能在團隊擁有具有end-to-end責任的軟體專案的環境中茁壯成長。
## 跨多個團隊協調微型前端開發
在跨多個跨職能團隊擴展微型前端開發時，出現兩個問題：首先，團隊開始開發自己的範例解釋，進行架構和程式庫選擇，並建立自己的工具和協助程式庫。其次，完全自主的團隊必須負責一般功能，例如低階基礎設施管理。因此，在多團隊微型前端組織中引進兩個額外的團隊是合理的：啟用團隊和平台團隊。這些概念廣泛應用於具有分散式系統的現代 IT 組織，並在[團隊拓撲](https://teamtopologies.com/key-concepts)中妥善記錄。
下圖顯示支援團隊為三個微型前端團隊提供工具、程式庫、標準和測試。平台團隊為相同的三個微型前端團隊提供基礎設施、共用執行期功能和網域服務。
平台團隊透過釋放微型前端團隊不受差異化繁重的負擔來支援這些團隊。此支援可能包括基礎設施服務，例如容器執行期、CI/CD 管道、協同合作工具和監控。不過，設定平台團隊不應導致開發與操作分離的組織。相反地，平台團隊提供工程產品，微型前端團隊擁有其在平台上服務的所有權和執行期責任。
啟用團隊透過專注於控管並確保微型前端團隊的一致性來提供支援。（平台團隊不應參與其中。) 啟用團隊會維護 UI 程式庫等共用資源，並建立架構、效能預算和互通性慣例等標準。同時，它為新團隊或團隊成員提供應用標準和工具的訓練，如控管所定義。
## 部署
微型前端團隊自主性的北極星是擁有自動化管道，其生產路徑與其他微型前端團隊無關。遵循共用原則的團隊可以實作獨立的管道。共用程式庫或依賴平台團隊的團隊必須決定如何在部署管道中管理相依性。
一般而言，每個管道都會執行下列動作：
+ 建置前端資產
+ 將資產部署至託管以供取用
+ 確保更新登錄檔和快取，以便將新版本交付給客戶
實際管道步驟會根據技術堆疊和頁面合成方法而有所不同。
對於用戶端合成，這表示將應用程式套件上傳至託管儲存貯體，並透過 CDN 的快取釋放至取用。搭配服務工作者使用瀏覽器快取的應用程式也應該實作更新服務工作者快取的方法。
對於伺服器端合成，這通常表示部署新版本的伺服器元件，並更新微型前端登錄檔，以便探索新版本。您可以使用藍/綠或金絲雀部署模式來逐步推出新版本。