共用方式為

GitHub 如何加速雲端採用

概觀

創新是當今競爭格局中的新貨幣。 共乘服務、串流內容、自動駕駛車輛和其他服務從根本上改變了人們的日常節奏，同時顛覆市場，並展示競爭格局如何從實體資產轉向數位化體驗。

這些類型的卓越數位體驗正在引領一場變革，使成熟的企業面臨來自能夠更快創新並為客戶提供價值的公司激烈競爭。 為了競爭並避免中斷，企業必須建立創新文化，並使用最適合的工具和雲端服務。

GitHub 提供一系列功能，可協助公司：

  • 利用 Azure 服務和功能。
  • 將其做法現代化。
  • 在這個文化轉變中，變得更加靈活和創新。

公司可以利用 GitHub 與開放原始碼社群的連線，並從成功採用 Azure 服務的組織，找到數千個已重申、增強且已準備好部署的雲端解決方案範例。 他們可以輕鬆地借用這些解決方案，並反覆運算這些解決方案，使其符合其業務需求。

GitHub 可讓組織輕鬆地在其小組內共用，讓組織更快速地現代化和部署下一個應用程式或工作負載。 公司可以尋求 InnerSource，這是創新的重要原則，借用共用和重複使用、共同作業和通訊等最佳做法，以及來自開放原始碼社群的更多做法，並將其套用在其組織內。

從保護開放原始碼套件到每日撰寫的智慧財產權，保護整個軟體供應鏈應該是每個公司的主要優先事項。 此目標需要可在整個生命週期內併入和自動化的進階安全性技術，而 GitHub 進階安全性和 GitHub Actions 等原生 GitHub 功能可提供這種彈性。

利用開放原始碼資產

高效能的組織將開放原始碼軟體 （OSS） 辨識為新式軟體開發的必要與選擇性。 他們與相依的開發人員社群互動，並使用安全的平臺，策略性地投資 OSS。 因此，這些組織會快速創新、超越競爭對手，並降低成本，同時將風險降至最低。

OSS 是由併入應用程式之套件、連結庫、腳本和相依性所組成。 OSS 也包含數千個開放原始碼資產，其形式為基礎結構即程序代碼 （IaC）、檔和定義完善的 Azure 架構指引。 Microsoft、合作夥伴、廠商、客戶和個人將這些套件貢獻給 OSS 社群。 您可以在 GitHub 中找到它們，並修改、重複使用，並將其部署至特定的 Azure 環境。

基礎結構即程序代碼

IaC 是基礎結構的管理，其中包含描述性模型中的網路、虛擬機、負載平衡器和聯機拓撲。 IaC 使用 DevOps 小組用於原始程式碼的相同版本控制系統。 例如，DevOps 小組遵循相同原始程式碼產生相同二進位檔的原則。 IaC 模型也會遵循該原則，並在每次套用模型時產生相同的環境。 IaC 是您可以搭配 持續傳遞 （CD） 使用的重要 DevOps 做法。

IaC 進化為解決發行管線中的環境漂移問題。 如果沒有，小組必須維護個別部署環境的設定，且環境之間的不一致會導致部署期間發生問題。 每個環境最終都會變成雪花，這是無法自動重現的唯一設定。 使用雪花時，基礎結構管理和維護需要手動程式來造成錯誤且難以追蹤。使用 IaC 的基礎結構部署是可重複的，並防止因設定漂移或遺失相依性所造成的運行時間問題。

使用 IaC 時，小組會變更環境描述和版本設定模型，其通常採用 JSON 等記載良好的程式代碼格式：如需詳細資訊，請參閱 Azure Resource Manager 範本 。 開發人員可以在與應用程式原始程式碼相同的 GitHub 存放庫中裝載 IaC 程式代碼，並針對 由 GitHub Actions 提供的 IaC 採用相同的持續整合 （CI） /CD 做法，以簡化其工作流程。

如需如何在各種 Azure 範圍部署自定義 Resource Manager 範本的範例，請參閱 AzOps GitHub 動作。 如果您不熟悉 Resource Manager 範本或 IaC，您也可以瀏覽 azure-quickstart-templates GitHub 上的存放庫、尋找您想要部署的範本，然後選取 [部署至 Azure] 按鈕來測試其運作方式。

[部署至 Azure] 按鈕的螢幕快照。

雲端模式元件和最佳做法

下列架構圖表會醒目提示在 GitHub DevSecOps 環境的 GitHub 和 Azure 元件中執行的安全性檢查：

架構圖表，醒目提示在 GitHub DevSecOps 環境的 GitHub 和 Azure 元件中執行的安全性檢查。

  • GitHub 提供程式碼裝載平臺，開發人員可用來在開放原始碼和 InnerSource 專案上共同作業。

  • Codespaces 是在線開發環境。 此工具由 GitHub 裝載，並由 Microsoft Visual Studio Code 提供技術支援，可在雲端中提供完整的開發解決方案。

  • GitHub 安全性 可透過多種方式消除威脅。 代理程式和服務會識別存放庫和相依套件中的弱點。 它們也會將相依性升級至目前且安全的版本。

  • GitHub Actions 是自定義工作流程，可直接在存放庫中提供 CI/CD 功能。 名為「執行者」的電腦會裝載這些 CI/CD 作業。

  • Microsoft Entra ID 是多租使用者雲端式身分識別服務，可控制對 Azure 和其他雲端應用程式的存取，例如 Microsoft 365 和 GitHub。

  • Azure App Service 提供建置、部署及調整 Web 應用程式的架構。 此平臺提供內建基礎結構維護、安全性修補和調整。

  • Azure 原則 可透過可強制執行雲端資源規則的原則定義，協助小組管理和防止IT問題。 例如，如果專案即將部署具有無法辨識 SKU 的虛擬機，Azure 原則會傳送有關問題的警示，並停止部署。

  • 適用於雲端的 Microsoft Defender 提供跨混合式雲端工作負載的整合式安全性管理與進階威脅保護。

  • Azure 監視器 會收集並分析效能計量、活動記錄和其他應用程式遙測。 此服務會在識別不規則狀況時警示應用程式和人員。

InnerSource

InnerSource 概觀

許多公司會使用 InnerSource 一詞來描述其工程小組如何在程式代碼上共同運作。 InnerSource 是一種開發方法，其中工程師會使用 Kubernetes 或 Visual Studio Code 等大規模開放原始碼專案的最佳做法來建置專屬軟體。

大規模開放原始碼專案需要跨數千個參與者進行協調和團隊合作。 最成功的專案是由未來和每日使用者需求的願景所驅動：速度、可靠性和功能。 這些專案運作的規模提供一些課程，並可協助公司更快速地使用 InnerSource 建置更好的軟體。

透過 GitHub 的提取要求和問題，共同作業和程式代碼檢閱會內建於開發程式中。 內部和外包小組可以共用工作、討論變更，並在單一位置取得意見反應。 這有助於組織在內部共用專業知識，並避免重塑針對其他專案開發的現場測試解決方案。

InnerSource 專案的剖析

個人、小組和資源的正確組合可確保專案成功。 許多開放原始碼專案都遵循類似的組織結構，可協助組織設定跨功能小組來管理 InnerSource 專案。 典型的開放原始碼專案具有下列類型的人員：

  • 維護： 這些參與者負責推動願景和管理項目的組織層面。 它們可能不是程式代碼的原始擁有者或作者。

  • 貢獻： 這些人都是為項目貢獻了一些東西的人。

  • 社群成員： 這些是使用項目的人員。 他們可能會在交談中活躍，或表達他們對專案方向的看法。

大型專案也可以讓小組委員會或工作組專注於不同的工作，例如工具、分級和社區仲裁。 InnerSource 專案可能會遵循類似的結構。 許多工程組織都會將開發人員排序為小組，例如應用程式工程、平臺工程和 Web 開發。 以這種方式建立組織可能會留下排除合格人員的盲點。 組織一個由整個組織的各個小組支援的核心決策群組，有助於集結所需的專業知識，以更快解決問題。

在企業中，參與者是整個公司的開發人員，維護人員是項目的領導者和關鍵決策者。

  • 維護： 負責推動專案願景和管理日常貢獻的公司內的開發人員、產品經理和其他重要決策者。

  • 貢獻： 協助推動軟體向前發展的公司內的開發人員、數據科學家、產品經理、行銷人員和其他角色。 參與者可能不是直接專案小組的一部分，而是藉由參與程序代碼、提交錯誤修正等等來協助建置軟體。

如需詳細資訊，請參閱白皮書 InnerSource 簡介。

自動化

GitHub Actions 可讓使用者直接在其 GitHub 存放庫中建立自定義工作流程。 使用者可以探索、建立及共用動作以執行任何作業，包括 CI/CD，並在完全自定義的工作流程中結合動作。 他們也可以建立 CI 工作流程，以不同的程式設計語言建置和測試撰寫的專案。 GitHub Actions 指南中提供範例。

GitHub Actions 可用來結合 IaC 概念和 CI/CD 做法，將整個端對端部署生命週期自動化，包括以可重複的方式佈建或更新目標環境，以及封裝和部署應用程式本身。

範例︰

適用於 Azure 的 GitHub Actions 是為了簡化自動化部署流程而建置，目標對象是 Azure 服務，例如 Azure App Service、Azure Kubernetes Service、Azure Functions 等。 Azure 入門動作工作流程存放庫包含端對端工作流程，可建置及部署任何語言和任何生態系統的 Web 應用程式至 Azure。 請流覽 GitHub Marketplace 以查看所有可用的動作。

安全

GitHub 的左移安全性功能

從開發的第一個步驟開始，DevSecOps 會遵循安全性最佳做法。 使用左移策略，DevSecOps 會將安全性焦點重新導向。 與其在最後才指向稽核，不如在一開始就轉向開發。 除了產生強固的程序代碼之外，這個快速失敗的方法有助於在容易修正時儘早解決問題。

GitHub 提供許多安全性功能，可支援 DevSecOps 工作流程的每個部分：

  • 具有內建安全性延伸模組的瀏覽器型 IDE
  • 不斷監控安全性公告並更換易受攻擊及過期相依項的代理程式
  • 掃描原始碼是否有弱點的搜尋功能
  • 以動作為基礎的工作流程，可將開發、測試和部署的每個步驟自動化
  • 提供私下討論及解決安全性威脅的空間，然後發佈資訊
  • 這些功能結合 Azure 的監視和評估能力，提供絕佳的服務來建置安全的雲端解決方案

範例︰

GitHub DevSecOps 安裝涵蓋許多安全性案例。 可能性包括下列案例：

  • 想要利用提供安全性功能的預先設定環境的開發人員。
  • 依賴 up-to日期、依其指尖排定安全性報告的優先順序，以及受影響程式代碼和建議修正的詳細數據。
  • 需要系統在密碼洩露於程式碼中時，自動獲取全新且未受損的安全裝置的精簡組織。
  • 能夠在較新或更安全的外部套件版本可用時受益於自動升級的開發團隊。

如需詳細資訊，請參閱：

後續步驟

  • 選擇您的實作小組（通常是開發人員管理員和一些定義為系統管理員的開發人員），並部署 GitHub。
  • 瞭解常見的和進階的 Git 工作流程，以增強您使用 GitHub 的方式。

下列連結提供 GitHub 的詳細資訊。