本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
組織和工作方式
與所有架構策略一樣，微前端的影響遠遠超出了組織選擇實施的技術。構建微型前端應用程序的決策必須與業務，產品，組織，營運甚至文化保持一致（例如，賦予團隊能力和去中心化決策）。作為回報，這種類型的微前端架構支持真正敏捷的產品驅動開發，因為它顯著減少了其他獨立團隊之間的通信開銷。
敏捷開發
近年來，敏捷軟件開發的想法變得如此普遍，幾乎每個組織都聲稱工作敏捷。雖然敏捷的決定性定義超出了此策略的範圍，但值得回顧一下與微型前端開發相關的關鍵要素。
敏捷範式的基礎是敏捷宣言
在微型前端架構的背景下，以下敏捷原則對於擁抱很重要：
-
「經常交付工作軟件，從幾週到幾個月，偏好更短的時間尺度。」
這一原則強調了以增量方式工作，並儘可能定期和盡可能經常地將軟件交付到生產環境中是多麼重要。從技術角度來看，這是指持續集成和持續交付（CI/CD）。在 CI/CD 中，用於構建，測試和部署的工具和過程是每個軟件項目不可或缺的組成部分。priniciple 還意味著運行時基礎結構和操作責任必須由團隊擁有。在獨立子系統對基礎設施和操作的需求可能有明顯不同的分佈式系統中，該所有權尤為重要。
-
「圍繞積極進取的個人構建項目。為他們提供所需的環境和支持，並相信他們能夠完成工作。」
「最好的架構、需求和設計來自自組織團隊。」
這兩個原則都強調了所有權，獨立性和 end-to-end 責任的好處。當（且僅當）團隊真正擁有自己的微前端時，微型前端架構才會成功。E 從概念到設計和實施到交付和運營的nd-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 是微型前端架構的理想補充。微前端的優勢依賴於快速且無摩擦的交付流程。只有在團隊 end-to-end 負責擁有軟體專案的環境中， DevOps 文化才能蓬勃發展。
協調跨多個團隊的微型前端開發
在跨多個跨職能團隊擴展微型前端開發時，會出現兩個問題：首先，團隊開始開發自己對範式的解釋，進行框架和庫的選擇，並創建自己的工具和幫助程序庫。其次，完全自主的團隊必須負責執行一般功能，例如低階基礎架構管理。因此，在多團隊微型前端組織中引入另外兩個團隊是有意義的：支持團隊和平台團隊。這些概念在具有分佈式系統的現代 IT 組織中廣泛採用，並在團隊拓撲
下圖顯示支援團隊為三個微型前端團隊提供工具、程式庫、標準和測試。平台團隊為這三個微型前端團隊提供基礎結構、共用執行階段功能和網域服務。
該平台團隊通過使微型前端團隊擺脫無差別的繁重工作來支持他們。這項支援可能包括基礎架構服務，例如容器執行階段、CI/CD 管線、協同作業工具和監控。但是，建立平台團隊不應導致開發與作業分離的組織。相反的情況是：平台團隊提供工程產品，微型前端團隊對其在平台上的服務擁有權和運行時負責。
支持團隊通過專注於治理並確保微型前端團隊的一致性來提供支持。（平台團隊不應該參與此。） 啟用團隊會維護共用資源，例如 UI 程式庫，並建立如架構選擇、效能預算和互通性慣例等標準。同時，它為新的團隊或團隊成員提供了如何根據治理定義的應用標準和工具的培訓。
部署
微型前端團隊的自主權北極星是擁有一條獨立於其他微型前端團隊的生產路徑的自動化管道。遵循無共享原則的團隊可以實施獨立的管道。共用程式庫或依賴平台小組的團隊必須決定如何在部署管道中管理相依性。
通常，每條配管都會執行以下操作：
-
構建前端資產
-
將資產部署到託管以供消費
-
確保註冊表和緩存已更新，以便將新版本交付給客戶
實際的管線步驟會根據技術堆疊和頁面構成方法而有所不同。
對於客戶端構成，這意味著將應用程序包上傳到託管存儲桶，並通過 CDN 上的緩存釋放以消耗。搭配服務工作線程使用瀏覽器快取的應用程式也應實作更新服務工作線程快取的方法。
對於伺服器端構成，這通常意味著部署新版本的伺服器元件，並更新微型前端登錄，使新版本可被探索。您可以使用藍/綠或初期測試部署模式來逐步推出新版本。
