Professional Services EM スコーピング - CI/CD パイプラインマイグレーション
他の CI/CD システムから GitLab へのパイプラインマイグレーションのスコーピングプロセスについて説明します。
顧客の成熟度レベルを判断するための一般的なディスカバリ質問
CI/CD、コンテナ、リポジトリの衛生状態に関して、顧客がどの程度の成熟度にあるかを理解することは有益です。顧客が GitLab Ultimate または DevOps Platform Concent に関心がある場合、以下の質問を検討してください。また、SCM マイグレーション に関する会話が DevOps ライフサイクルの後段から追加のデータ要素のマイグレーションへ拡大している場合も、これらの質問を検討してください。
| 質問 | 回答 | 回答例 | 質問する理由 |
|---|
| 現在、ソフトウェア開発ライフサイクルでコンテナをどのように使用していますか? | | ソフトウェアアプリケーションをコンテナにデプロイしている、または、汎用コンテナを使用して CI/CD ジョブを実行している、または、厳密に管理された部品表(BOM)を持つ専用コンテナを使用して CI/CD ジョブを実行している。 | この質問は、コンテナとしてソフトウェアをデプロイすることと、CI/CD ジョブを実行するためにコンテナを使用することを意図的に区別することを目的としています。 |
| CI/CD コンピュート環境にインストールされ実行されるソフトウェアをどのように制御・管理していますか? | | 各アプリケーションチームが自身の VM/コンテナにソフトウェアをインストールして、ビルド/テスト/スキャン/デプロイを行えるようにしている。または、ビルド/テスト/スキャン/デプロイのジョブを実行できるベース VM/コンテナを中央集権的に管理している。アプリチームはそれらの VM/コンテナにソフトウェアを追加できる。 | 顧客が SDLC サプライチェーン をどのように管理しているか、また CI/CD エコシステムで実行されるソフトウェアの制御を失うことに伴うリスクを理解することを目指しています。 |
| コンテナを環境に取り込むのにどのくらいの時間がかかりますか? | | 月次でインターネットからコンテナをプルし、スキャンして社内に公開している。新しいコンテナが必要な場合、リクエストの承認と処理に約 1 週間かかると想定してほしい。または、現時点でスキャンアプローチがない。アプリチームは好きなコンテナを使用できる。 | サービスを適切にスコーピングするために、現在のセキュリティプラクティスを理解したいと考えています。 |
| リポジトリの構造はどうなっていますか? 構造化(単一のテックスタックが単一のソリューションに焦点を当てる)か、非構造化(多くのソフトウェアソリューションをホストする多くのテックスタック)か | | 多くの Git リポジトリは単一のソフトウェアソリューションに焦点を当てている。一部に非構造化リポジトリがあるかもしれないが、それらは例外。 | 構造化リポジトリを使用することで、GitLab CI/CD(特にパイプライン COE)をすぐに活用できるため、この質問をします。 |
| 現在、Debian や Red Hat パッケージなどのパッケージをどのように環境に取り込んでいますか? | | Red Hat Satellite を利用してこれを処理している。現在、開発者自身がパッケージをインポートできるようにしている。社内の Apt/Yum リポジトリを持っており、そこにパッケージをインポートしている。 | 顧客が現在持っている制御・標準化のレベルと、将来の状態でどのような制御・標準化のレベルを達成したいかを理解したいと考えています。 |
CI/CD「マイグレーション」の一般的なアプローチ
- フラッシュカット(Flash Cut) - レガシー CI プラットフォームから GitLab に、ジョブ定義、ジョブ出力、アーティファクトを含むすべてのデータをマイグレーションします。注: 新しいシステム上で履歴を再作成する必要があるため、これは通常より困難です。多くの顧客は追加コスト(スクリプト作成・テストの開発時間、より長いマイグレーション期間)に関心がありません。可能な限り、ネットニュー を推奨すべきです。
- ネットニュー(Net New) - すべてのパイプラインジョブ定義を更新し、GitLab CI を使用して顧客の GitLab インスタンス上で実行するようにします。すべてのジョブ履歴はレガシーシステムに残ります。すべての過去のパッケージとコンテナはレガシーシステムに残し、新しい GitLab システムで再構築します。
Artifactory から GitLab Registry へのマイグレーション
具体的なアプローチ
- フラッシュカット - 過去にビルドされたパッケージとコンテナを含むすべてのデータを Artifactory から GitLab レジストリにマイグレーションします。(推奨されません)
- ネットニュー - すべてのパイプラインを更新して GitLab レジストリにプッシュ・プルし、新しくビルドされたソフトウェアパッケージがビルド/パッケージステージで GitLab に保存されるようにします。次にデプロイステージで GitLab レジストリからプルします。あまり変更されない依存関係を徐々に GitLab レジストリにマイグレーションし、Artifactory を段階的にフェーズアウトします。(推奨)
スコーピング質問 - Artifactory マイグレーションの機会
| 質問 | 回答 | 回答例 | 質問する理由 |
|---|
| Artifactory にはどのようなアーティファクトが保存されていますか? | | ビルド済みのソフトウェアバイナリと Docker コンテナ。依存ライブラリはなし - これらはインターネット経由で取得している。 | これは上記の一般的なアプローチの決定に影響します。 |
| Artifactory には何個のアーティファクトが保存されていますか? | | 1,234 | マイグレーションプロジェクトのスコープの大まかな規模を示します。 |
| Artifactory サーバーは何台ありますか? | | 2 | これは複雑性の指標です。Artifactory サービスが多いほど複雑になります。 |
| 月あたり何個のソフトウェアパッケージ/イメージが Artifactory にプッシュされますか? | | 2345 | これは顧客が移行プロセス中に使用するためにこのデータを測定していることを示します。 |
| 月あたり何個のソフトウェアパッケージ/イメージが Artifactory からプルされますか? | | 2345 | これは顧客が移行プロセス中に使用するためにこのデータを測定していることを示します。 |
Jenkins から GitLab CI へのマイグレーション
具体的なアプローチ - Jenkins マイグレーション
- フラッシュカット - すべてのデータを Jenkins から GitLab CI にマイグレーションし、パイプラインファイルを一括で更新します。
- ネットニュー - すべてのパイプラインジョブ定義を更新し、GitLab CI を使用して顧客の GitLab インスタンス上で実行するようにします。すべてのジョブ履歴はレガシーシステムに残ります。すべての過去のパッケージとコンテナはレガシーシステムに残し、新しい GitLab システムで再構築します。
スコーピング質問 - Jenkins マイグレーションの機会
| 質問 | 回答 | 回答例 | 質問する理由 |
|---|
| Jenkins インスタンスは何個ありますか? それらをリストし、各インスタンスについて以下の質問に回答してください。 | | 2 インスタンス - US East と US West | マイグレーションのスコープを理解するためにこれを把握する必要があります。 |
| これらのインスタンスはどこに配置されていますか? | | AWS US East 1c、オンプレミスのサクラメントのデータセンター | Jenkins サーバーと GitLab 間の接続性を考慮するためです。 |
| ジョブの総数は? | | 6,400 | 規模の指標であり、プロジェクト期間の指標です。 |
| ユーザーの総数は? | | 900 | 規模の指標であり、プロジェクト期間の指標です。 |
| リポジトリの総数は? | | 6,400 | カーディナリティ(例: 各ソースコードプロジェクトに何個のジョブが関連付けられているか)を理解するのに役立ちます。エンゲージメントの規模の指標でもあります。 |
| 現在 Jenkins は SCM とどのように通信していますか? | | 単一のサービスアカウントが、SCM の変更をポーリングするために使用されている。 | 責任の移行(プラットフォームチームからアプリケーションチームへ)がある場合、GitLab プロジェクトの設定方法に関する教育サービスについて議論すべきかどうかを示します。 |
| 最も頻繁に使用している Jenkins プラグインは何ですか? | | maven プラグインを広く使用している。一部のチームは Ant/Gradle プラグインも使用している。.NET SDK の使用もある。 | ワークフローをサポートするプラグインについてより詳しく知ることで、GitLab のベストプラクティスに基づくアプローチを使用するワークフロー提案の構築にどれだけの時間を費やすべきかを理解できます。 |
| Jenkins フォルダーやジョブの作成を自動化するためにブランチ/ソースプラグインを使用していますか? | | リポジトリ作成時に Jenkins ジョブを自動作成するためにブランチ/ソースプラグインは使用していない。 | この自動化は通常、顧客が保持したいものなので、このようなアプローチには特別な配慮が必要です。 |
| Jenkins ジョブを取り上げるジョブエクゼキュータのタイプは何ですか? | | ジョブを実行するために常時稼働している仮想マシンのフリートを持っている。 | GitLab のベストプラクティス(コンテナ化されたビルドの活用)を使用するためにワークフローを移植する作業負荷を理解するのに役立ちます。 |