概要
イノベーションは、今日の競争環境における新しい通貨です。 ライドシェア、ストリーミング コンテンツ、自動運転車、その他のサービスは、人々の毎日のリズムを根本的に変え、市場を逆さまで変え、競争環境が物理的な資産からデジタル エクスペリエンスにどのように移行したかを示しています。
このような優れたデジタルエクスペリエンスは、確立された企業がイノベーションを起こし、顧客に価値を迅速に提供できる企業との厳しい競争に直面する混乱を招きます。 競争し、混乱を避けるために、企業はイノベーションの文化を構築し、最適で最も適したツールとクラウド サービスを使用する必要があります。
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 を初めて使用する場合は、GitHub で azure-quickstart-templates リポジトリ を参照し、デプロイするテンプレートを見つけて、[ Azure にデプロイ ] ボタンを選択して動作をテストすることもできます。
![[Azure にデプロイ] ボタンのスクリーンショット。](media/deploy-to-azure.png)
クラウド パターン コンポーネントとベスト プラクティス
次のアーキテクチャ図では、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 などの他のクラウド アプリケーションへのアクセスを制御するマルチテナントクラウドベースの ID サービスです。
Azure App Service には、Web アプリを構築、デプロイ、スケーリングするためのフレームワークが用意されています。 このプラットフォームでは、組み込みのインフラストラクチャ メンテナンス、セキュリティ 修正プログラムの適用、スケーリングが提供されます。
Azure Policy は、チームがクラウド リソースにルールを適用できるポリシー定義によって、IT の問題を管理し防止するのに役立ちます。 たとえば、プロジェクトが認識できない SKU を持つ仮想マシンをデプロイしようとしている場合、Azure Policy は問題に関するアラートを送信し、デプロイを停止します。
Microsoft Defender for Cloud を使用すると、統合されたセキュリティ管理と高度な脅威に対する保護がハイブリッド クラウド ワークロードに提供されます。
Azure Monitor は 、パフォーマンス メトリック、アクティビティ ログ、およびその他のアプリケーション テレメトリを収集して分析します。 このサービスは、アプリケーションと担当者が不規則な状態を識別したときにアラートを生成します。
InnerSource
InnerSource の概要
多くの企業では、 InnerSource という用語を使用して、エンジニアリング チームがコードでどのように連携するかを説明しています。 InnerSource は、エンジニアが Kubernetes や Visual Studio Code などの大規模なオープンソース プロジェクトのベスト プラクティスを使用して独自のソフトウェアを構築する開発手法です。
大規模なオープンソース プロジェクトでは、何千人もの共同作成者間の調整とチームワークが必要です。 最も成功したプロジェクトは、スピード、信頼性、機能など、将来と日々のユーザーニーズのビジョンによって推進されています。 これらのプロジェクトが動作する規模は、いくつかのレッスンを提供し、企業が InnerSource でより迅速に優れたソフトウェアを構築するのに役立ちます。
GitHub のプル要求と問題により、コラボレーションとコード レビューが開発プロセスに組み込まれます。 社内チームと外部委託チームは、作業の共有、変更の話し合い、フィードバックの取得をすべて 1 か所で行うことができます。 これにより、組織は社内で専門知識を共有し、他のプロジェクト用に開発された現場テスト済みソリューションの再発明を回避できます。
InnerSource プロジェクトの構造
個人、チーム、リソースの適切な組み合わせによって、プロジェクトの成功を保証できます。 多くのオープンソース プロジェクトは、組織が InnerSource プロジェクトを管理するための部門間チームのセットアップに役立つ、同様の組織構造に従います。 一般的なオープンソース プロジェクトには、次の種類のユーザーが含まれます。
メンテナ（管理者でもある）： これらのメンテナは、プロジェクトのビジョンを推進し、組織面を管理する責任があります。 元の所有者またはコードの作成者ではない可能性があります。
貢献： これらの人々は、プロジェクトに何かを貢献したすべての人です。
コミュニティ メンバー: これらは、プロジェクトを使用するユーザーです。 会話の中で活発に活動している場合や、プロジェクトの方向性について意見を述べる場合があります。
大規模なプロジェクトでは、ツール、トリアージ、コミュニティ モデレーションなどのさまざまなタスクに焦点を当てた小委員会や作業グループを含めることもできます。 InnerSource プロジェクトは、同様の構造に従う可能性があります。 多くのエンジニアリング組織は、開発者をアプリケーション エンジニアリング、プラットフォーム エンジニアリング、Web 開発などのチームに分類します。 このように組織を構成すると、資格のあるユーザーを除外する盲点が残る可能性があります。 組織全体のチームがサポートする主要な意思決定グループを編成すると、問題をより迅速に解決するために必要な専門知識を集めるのに役立ちます。
企業内では、共同作成者は会社全体の開発者であり、保守担当者はプロジェクトのリーダーであり、主要な意思決定者です。
メンテナ： プロジェクトのビジョンを推進し、日々の貢献を管理する責任を負う社内の開発者、製品マネージャー、およびその他の主要な意思決定者。
貢献： 開発者、データ サイエンティスト、製品マネージャー、マーケティング担当者、およびソフトウェアの推進に役立つ社内のその他の役割。 共同作成者は直接プロジェクト チームの一員ではない可能性がありますが、コードの提供、バグ修正の提出などを行うことで、ソフトウェアの構築に役立ちます。
詳細については、ホワイト ペーパー 「InnerSource の概要」を参照してください。
Automation
GitHub Actions を使用すると、ユーザーは GitHub リポジトリに直接カスタム ワークフローを作成できます。 ユーザーは、CI/CD を含む任意のジョブを実行するアクションを検出、作成、共有し、完全にカスタマイズされたワークフローでアクションを組み合わせることができます。 また、さまざまなプログラミング言語で記述されたプロジェクトをビルドしてテストする CI ワークフローを作成することもできます。 例については、 GitHub Actions のガイドを参照してください。
GitHub Actions を使用すると、IaC の概念と CI/CD プラクティスを組み合わせて、エンド ツー エンドのデプロイ ライフサイクル全体を自動化できます。これには、反復可能な方法でのターゲット環境のプロビジョニングまたは更新、アプリケーション自体のパッケージ化とデプロイが含まれます。
例:
GitHub Actions for Azure は、Azure App Service、Azure Kubernetes Service、Azure Functions などの Azure サービスを対象とするデプロイ プロセスを自動化する方法を簡略化するために構築されています。 Azure スターター アクション ワークフロー リポジトリには、任意の言語と任意のエコシステムの Web アプリを構築して Azure にデプロイするためのエンド ツー エンドのワークフローが含まれています。 GitHub マーケットプレースにアクセスして、使用可能なすべてのアクションを確認してください。
セキュリティ
GitHub のシフトレフトセキュリティ機能
開発の最初の手順から始めて、DevSecOps はセキュリティのベスト プラクティスに準拠しています。 シフトレフト戦略を使用すると、DevSecOps によってセキュリティ フォーカスがリダイレクトされます。 最後に監査を指す代わりに、最初は開発に移行します。 堅牢なコードを生成するだけでなく、このフェイルファーストアプローチは、修正が容易な問題を早期に解決するのに役立ちます。
多くのセキュリティ機能を備えた GitHub には、DevSecOps ワークフローのすべての部分をサポートするツールが用意されています。
- 組み込みのセキュリティ拡張機能を備えたブラウザー ベースの IDE
- セキュリティ アドバイザリを継続的に監視し、脆弱で古い依存関係を置き換えるエージェント
- ソース コードをスキャンして脆弱性を検出する検索機能
- 開発、テスト、デプロイのすべてのステップを自動化するアクションベースのワークフロー
- セキュリティ上の脅威について個人的に話し合い、解決し、情報を公開する方法を提供するスペース
- これらの機能は、Azure の監視と評価の機能と組み合わせることで、セキュリティで保護されたクラウド ソリューションを構築するための優れたサービスを提供します
例:
GitHub DevSecOps のインストールでは、多くのセキュリティ シナリオがカバーされています。 次のケースの可能性があります。
- セキュリティ機能を提供する構成済み環境を利用する開発者。
- 最新の優先順位付けされたセキュリティレポートをすぐに利用でき、影響を受けたコードと推奨される修正についての詳細があることに依存している管理者。
- シークレットがコード内で露出した際に、新しくて未改ざんのセキュリティデバイスを自動的に取得する必要がある効率的な組織。
- 新しいバージョンまたはより安全なバージョンの外部パッケージが使用可能になったときに、自動アップグレードの恩恵を受ける可能性がある開発チーム。
詳細については、以下を参照してください。
- GitHub の DevSecOps: Azure ソリューションのアイデア
- Azure DevOps パイプライン内で GitHub の高度なセキュリティを使用して GitHub リポジトリをスキャンするコード
- ソフトウェア サプライ チェーンへの DevSecOps の適用
次のステップ
- 実装チーム (通常は開発者マネージャーと管理者として定義されたいくつかの開発者) を選択し、GitHub をデプロイします。
- GitHub の使用方法を強化するための一般的で高度な Git ワークフローについて説明します。
GitHub の詳細については、次のリンクを参照してください。