1. 適切なCI/CDアーキテクチャの選択について学習します
  2. 最も適したアーキテクチャまたはソリューションの識別

最も適したアーキテクチャまたはソリューションの識別

一連の評価要因(またはストレス)を検討して、ニーズに最も適したリファレンス・アーキテクチャ(RA)またはソリューションを特定します。次のセクションでは、考慮すべき要因について説明します。

各要素について、アーキテクチャまたはソリューションがその要素をサポートしているかどうかを示します。必要に応じて、各係数に数値スコアを与えることで、より微調整できます。これらの推奨事項を使用して、情報およびデシジョン・マトリックスを使用します。

  • どの列が優先回答と一致するかを追跡します。
  • デシジョン・マトリックスを使用して、ニーズに最も適したRAまたはソリューションを各評価要素と比較します。
  • 他の要因よりも重要な要因に重みを追加します。

様々な評価要因の検討

各評価係数を検討し、各アーキテクチャおよびソリューションと比較して、ニーズに最も適した評価要素を決定します。

コンテナ、仮想マシン(VM)、またはスペシャリスト

Kubernetesなどのコンテナ・オーケストレーション環境内のコンテナにプロセスをデプロイすることで、より多くのコンピュート能力を必要とするプロセスのリソースを効率的にスケーリングできます。ユニット・テストや静的コード分析などのタスクには、この利点があります。コンテナの使用の欠点は、エンドツーエンド構成における複雑さの増加です。チームは、Kubernetesなどのコンテナ・オーケストレーション・ツールの使用方法を知っておく必要があります。また、コンテナを使用すると、コンテナが破棄されたときに、一時的な依存性や以前の状態データを誤って取得することを防ぐことができます。

単一のVMを構築してパイプラインのすべてのステップを処理できるため、VMの使用は簡単です。コンテナは本質的にモノリシックです。VMアプローチでは、開発者のホスティングを許可したり、WindowsホストとLinuxホストの使用の問題を回避したりといった問題が軽減されます。

一部のスペシャリスト・シナリオでは、ビルド・プロセスでサービスのアーティファクトを準備およびデプロイするPaaSまたはSaaS製品のみがサポートされます。これは汎用ツールを使用してオーケストレーションできます。場合によっては、要件に固有のツールを使用すると、より有益になることがあります。たとえば、Oracle Visual Builder Studioは、Visual Builderに関連するソリューション用に設計されています。

オープン・ソース/サードパーティ製品を使用したOCIネイティブによるパイプライン・オーケストレーション

Jenkinsなどのオープン・ソース・ツールを含むドメイン固有または非常にカスタマイズ可能なツールを使用して、OCIネイティブ・ソリューションの使用と比較して、実行時のビルド・プロセスの自由度を高めることができます。OCI DevOpsなどのツールは、新しい機能を定期的にリリースします。ただし、この柔軟性には、一般的なパイプラインを実行する場合でも、デプロイメント、パッチ適用、監視などの多くのプロセス・ステージを管理するというコストがかかります。

標準化されたデプロイメント・リポジトリまたは特別な製品リポジトリ

ネイティブ・サービスは、OCI Git、GitLabまたはGitHubなどの業界標準サービス、および同様のツールを使用して構成を管理する際の要件をサポートします。CI/CDプロセスは、部分的に統合されたレガシー・リポジトリで制約される場合があります。レガシー・リポジトリでCI/CDプロセスを使用できるように、パイプラインを大幅に変更する必要がある場合があります。

業界向けStandard構成管理ツールまたはレガシー・ツール

クラウド提供のサービスを使用する場合、GitやSVNなどの構成管理(CM)システムを使用した業界標準のソリューションのみをサポートすることが一般的です。これらのサービスプロバイダは、ベンダー独自の製品が必要とする特殊な構成管理メカニズムもサポートする場合があります。レガシーまたはニッチCMシステムを使用する必要がある場合は、CMシステム・プロバイダがサポートするサード・パーティ・ソリューションを検討する必要があります。たとえば、CVSをレガシー・ソリューションとしてサポートするには、ユーザーがサードパーティ・ツールを使用して構成を管理する必要がある場合があります。

マルチクラウドまたは単一のクラウド導入

同じコア・ソリューションを複数のクラウドにデプロイすると、複雑さが増す可能性があります。たとえば、デプロイメント・プロセスがTerraformサービスに組み込まれている場合、各クラウド・プロバイダには、様々なTerraformプロバイダとの違いを考慮したデプロイメント・プロセスが必要です。異なるイメージを作成する必要があるため、Dockerイメージのターゲット・チップセットなどのより微妙な考慮事項が必要になる場合があります。

セキュリティを強化するために、外部デプロイメント・ソリューションのデプロイメント・ターゲットを公開しないように選択できます。たとえば、Oracle Container Engine for Kubernetes (OKE)およびAzure Kubernetes (AKE)にデプロイする場合は、GitHubを使用して共通コードを保持し、GitHubアクションを使用してコンテナ・ビルドを編成できます。ただし、AKSおよびOKEを直接GitHubアクションに公開しないように選択できます。かわりに、AzureとOCIとのマルチステージ・ソリューションを検討してデプロイメント・オーケストレーションを提供し、継続的なビルド・プロセスまたはコア・コードにGitHubを使用します。

Infrastructure as Code (IaC)がデプロイメント・プロセスの一部である場合は、マルチステージ・ソリューションを検討してください。これにより、コンピュート、ストレージおよび管理対象サービスのプロビジョニング用に、各環境に異なるIaC構成を設定できます。Kubernetesを使用すると、このような問題を制限または削除できます。

プロセスのカスタマイズまたはビスポーク・プロセス

特別なプロセスまたはニッチ・プロセスが必要な場合は、ビルド・パイプラインをサポートするツールで、カスタム構成の拡張機能を許可する必要があります。独自の特注プロセスを構築するには、より多くの労力が必要です。検討し、将来の変更によってカスタマイズが機能しなくなる可能性があるリスクを評価する必要があります。

スケーリングの可能性

稼働日中の一般的な傾向などの要因により、開発ワークロードが変動する可能性があります。たとえば、CI/CDプロセスをトリガーする1日の終わりアクティビティをまとめるためにコミットすると、稼働日の終了時にワークロードが増加します。プロジェクトがビルド、リリースおよびデプロイのライフサイクルを進めるにつれて、ビルド・インフラストラクチャでは需要が増加しています。小さな問題がリリース/印刷サイクルの終わりに対処されるため、小規模な変更に対するリクエストの増加パターンがあります。

意思決定マトリクスのレビュー

アーキテクチャーとソリューションは、微妙な違いがある場所に基づいて、1a、1b、1cなどの共通の番号でグループ化されます。 たとえば、CI/CDソリューション用の単一ノード、または異なるツール構成を持つ同じソリューションでは、ソリューションがより大きな規模で動作できることを示しています。各グループはデシジョン・マトリックスの列ヘッダーで、各ファクタは行ヘッダーです。表内のコールアウト(1など)は追加情報を提供します。

アーキテクチャおよびソリューションのグループ化

  1. Jenkinsオーケストレーション(2つのバリアントあり)
    1. Jenkinsでのクラウド・デプロイメント用のCI/CDパイプラインの設定: スケーリングや自己回復性を備えずに、最小限のデプロイメント・アプローチで済みます
    2. マスター/エージェント・モードでのJenkinsのデプロイ: スケーラブルで自己回復性の高いデプロイメント
    3. Oracle DevOpsサービスを使用した継続的な統合およびデプロイメント・パイプラインの構築
  2. GitLab
    1. GitLabをデプロイして、OCIでCI/CDパイプラインを有効にします
    2. クラスタ自動スケーリングによるOracle Container Engine for KubernetesへのGitLabランナーのデプロイ
  3. OCI DevOps: サーバーレスおよびコンテナのバリアント
    1. Oracle Cloud Infrastructure DevOpsサービスおよびOCI Functionsを使用したCICDパイプラインの構築
    2. Oracle DevOpsサービスを使用した継続的な統合およびデプロイメント・パイプラインの構築
  4. GitHubアクション: GitHubアクションとOracle Cloud Infrastructure DevOpsサービスを使用して、クラウド・デプロイメント用のCI/CDパイプラインを構築します
  5. 最新のアプリケーション戦略: Oracle Cloud Infrastructure Devopsによる最新のアプリケーション・デプロイメント戦略の計画
  6. モバイル・ハブ: モバイル・アプリケーションのCI/CDパイプラインの作成
  7. ボット: ボット・カスタム・コンポーネントのCI/CDパイプラインの作成

次の決定マトリックスは、ビジネス・ニーズに適したアーキテクチャとソリューションのバリエーションを表します。

要素 1. Jenkinsオーケストレーション 2. GitLab 3. OCI DevOps 4. GitHubアクション 5. 最新のアプリケーション戦略 6. モバイル・ハブ 7. ボット
コンテナ、仮想マシン(VM)、またはスペシャリスト

VMおよびコンテナ

(提供されているソリューションのターゲットVM)

 VMまたはコンテナ VMおよびコンテナ VMおよびコンテナ VMおよびコンテナ スペシャリスト スペシャリスト
オープン・ソース/サードパーティ製品によるOCIネイティブまたは管理されていないパイプライン・オーケストレーション はい はい いいえ はい いいえ いいえ(Oracle Dev Cloud) いいえ
標準化されたデプロイメント・リポジトリ はい1、3 はい1 いいえ いいえ(RA実装では可能ですが) はい1 いいえ いいえ
サポートされている構成管理リポジトリ GIT、SVNなど ギット ギット ギット ギット ギット ギット
マルチクラウドまたは単一のクラウド導入 単一2、3 単一クラウドまたはマルチクラウド 単一2 単一クラウドまたはマルチクラウド 単一2 単一 いいえ
プロセスのカスタマイズまたは特注プロセス はい はい はい はい はい いいえ 限定
スケーリングの可能性

1a - いいえ

1b - はい

 はい はい はい はい いいえ いいえ

表の脚注

ノート:

  • 1 OCIRは標準に準拠しています。
  • 2 OCIを使用して、他の環境のプロセスを推進します。しかし、他の環境におけるサービスに対する望ましくないエクスポージャの課題も高めます。
  • 3オプション1aのデプロイ・フェーズでOCI DevOpsを使用するため、そのフェーズを単一のクラウドに制限します。