JenkinsからGitLabへのスムーズな移行

GitLabは、最も包括的なAI搭載のDevSecOpsプラットフォームです。GitLabには、ソフトウェアの計画、開発、セキュリティ確保、迅速なリリースに必要な機能がすべて揃っています。

プラットフォームを活用することで、さまざまなツールの統合（DIY DevOps）に苦労することなく、ソフトウェア開発ライフサイクル（SDLC）を実現できます。一方、Jenkinsはプラットフォームではないため、SDLCを実現させるには他のツールと組み合わせる必要があります。このようなDIY DevOpsのアプローチではツールチェーンの複雑さが増し、以下のようなデメリットが生じます。

• ツールの統合やオーケストレーションに特別なサポートが必要
• 個々のツールの保守、アップグレード、セキュリティ対策の負担が大きい
• 組織における変革の進捗を正確に把握しづらい
• デベロッパーエクスペリエンスが悪化する
• 管理コスト、時間、予算がかかる
• 生産性が低下する
• 頭の切り替えが必要となり、コラボレーションの効率が下がる

こうした理由から、Jenkinsを使用する多くのチームがDevSecOpsプラットフォームへの移行を検討しています。より強力で、信頼性と安全性の高いソリューションを求めているなら、GitLabが最適です。GitLabは無料で使い始められ、組織のニーズに応じたさまざまなサブスクリプションプランが用意されています。GitLab のプランや機能の詳細については、価格ページをご覧ください。

このブログ記事では、以下について学べます。

• 移行計画の立て方
• 他のソースコード管理（SCM）ツールからGitLabへリポジトリを移行する方法
• JenkinsからGitLabへCI/CDパイプラインを移行する方法
• 移行に関するその他の考慮事項

移行計画を立てる

他のツールからGitLab CI/CDへ移行を開始する前に、まず移行計画を立てる必要があります。移行計画は、期待値を明確にするための重要な技術的ステップです。CI/CDツールは、それぞれアプローチや構造、技術的な仕様が異なるため、単純にデータを1対1でマッピングできるわけではありません。適切な移行計画を立てることでもたらされるメリットを次に挙げます。

• 移行の目的を明確にして共有することで、なぜ移行が価値のある取り組みなのかをユーザーに理解してもらいやすくなります。作業が完了すればその価値は明らかになりますが、移行中の段階においても認識してもらうことが重要です。
• 関係する経営陣の支援や合意が得られ、移行の重要性や目的が全員に伝わりやすくなります。
• 移行後の環境の違いについて、ユーザーが理解を深める時間を確保できます。
• 移行の順序を決めたり、一部の移行を後回しにしたりすることで、未移行や部分的な移行状態が長引くのを防ぎます。
• GitLab CI/CDにより得られる改善点やメリットを文書化し、移行の一環として既存の実装を更新できます。

適切な移行計画を策定することで、業務への影響を最小限に抑えながら、GitLabへ徐々に移行できます。具体的には、JenkinsとGitLabを併用しつつ、一部のプロジェクトをGitLabに移し、Jenkinsの利用を徐々に減らしていくといった計画が考えられます。

変更管理プロセスを定める

移行計画では、効果的な変更管理プロセスを定める必要があります。デベロッパー、IT運用担当者、クラウド管理者、セキュリティ担当者、品質エンジニアなどの関係者は、GitLabの使用経験がなく、なぜあなたや経営陣がこの移行を決定したのかを理解していないかもしれません。

この移行によって影響を受ける人々に、以下の点を理解してもらう必要があります。

• なぜ：この変更が行われるのか
• 何が：移行後の状態として想定されているのか
• どのように：現在の状況から移行後の状態にするのか
• どこで：追加の情報やサポートを得られるのか

移行の影響を受ける各部門のへの影響を理解し、その変化を管理するには、以下の手順が必要です。

• 現在の状況を分析する：まず、現在のプロセスを文書化し、基準となる指標を収集します。次に、主要なチームメンバーへのインタビューを通じて、CI/CDにおいてうまく機能している点と機能していない点を特定します。課題を特定したら、定量的、定性的の両面から記録します。移行のビジョンと変更の理由を関係者に理解してもらう必要があるため、課題は明確に定義すればするほど、社内の合意を得やすくなります。
• ビジョンを確立する：現在の課題を、定量的な基準値と定性的なチームメンバーのフィードバックで明確にしたら、次に将来のビジョンを共有します。ビジネスの成功指標と結びつけて、なぜこの移行が重要なのかを説明します。また、望ましい状態の具体的な例をライブデモや録画を通じて示し、現在の状況と比較します。さらに、このメッセージを定着させるために、チャットグループ、全社ミーティング、メール通知、GitLab上のバナーメッセージなど、複数のチャネルやメディアを活用して発信します。
• 従業員を教育する：GitLabの専門家が実施するGitLab CI/CDトレーニングに投資し、GitLab認定を活用して、知識の習得度や定着度を測定します。
• ロードマップとリソースを共有する：チームメンバーに対し、移行の予定タイムラインや、移行に役立つリソースを案内します。また、チャットグループ、Q&Aボード、GitLabインフルエンサーによるオフィスアワーなど、コミュニティのリソースも案内し、質問に対する回答やサポートを得られる環境を整えます。さらに、早期に移行したチームを対象とした報酬制度を導入して、移行体験を他のアプリケーショングループと共有してもらうのも効果的です。

移行の開始時にこれらの要素が揃っていれば、成功へ向けたしっかりとした基盤を築けます。

移行目標を設定する

移行を実施する前に、目標とそれを達成する方法をしっかりと把握しておく必要があります。たとえば、以下のような質問に対する答えを用意しておくことが重要です。

• 移行のタイムラインはどのようになっているのか？
• 現在のJenkinsサーバーの構成はどうなっているか？
• 移行対象のプロジェクトはいくつあるか？
• パイプラインの複雑さはどの程度か？
• 外部依存関係、複数のパイプライントリガー、並列ビルドなどが必要か？
• コードのデプロイ方法とデプロイ先は？
• デプロイするコードのリリースやレビューのプロセスはどのようになっているか？
• Jenkinsに統合されているのか、それともJenkinsがトリガーする別のワークフローなのか？
• パイプラインの成功に必要なビルドアーティファクトやバイナリは何か？
• 現在Jenkinsのジョブで使用しているプラグインは何か？
• Jenkinsエージェントにインストールされているソフトウェアは何か？
• 現在使用しているSCMソリューションは何か？
• Jenkinsのジョブで共有ライブラリを使用しているか？
• Jenkinsで使用している認証方法は何か（Basic認証、LDAP/AD、SSOなど）？
• パイプラインからアクセスする必要がある他のプロジェクトはあるか？
• Jenkinsが外部サービスと連携する際に使用するアクセス用認証情報はあるか？

これらの質問に答えることで、移行の進め方、所要時間、どこから始めるべきかが明確になります。移行計画を立て、期待値や想定される課題をしっかり把握できたら、いよいよ移行プロセスの開始です。

移行の前提要件

移行計画を作成し、移行に関するすべての期待事項を整理できたら、GitLabのセットアップを開始できます。移行の前に推奨される前提要件をいくつかご紹介します。

• GitLabに慣れる。GitLab CI/CDの主な機能を読んで理解を深める。
• チュートリアルを活用し、最初のGitLabパイプラインと、静的サイトをビルド、テスト、デプロイするより複雑なパイプラインを作成する。
• .gitlab-ci.ymlのキーワード参照を確認する。
• GitLabをセットアップし、適切に設定する。
• GitLabインスタンスをテストする。

GitLabの理解を深め、インスタンスの設定が完了したら、移行計画に沿ってJenkinsからGitLabへのプロジェクト移行を進めることができます。その際、GitLabインスタンスがGitLabのベストプラクティスやリファレンスアーキテクチャに従って適切に設定されていることを確認してください。

リポジトリをGitLabに移行する

Jenkinsの主な欠点の1つは、SCMソリューションがないことです。Jenkinsを使用している場合、別のSCMソリューションにコードを保存し、そこにJenkinsからアクセスする必要があります。一方、GitLabにはSCMが組み込まれているため、Jenkinsからの移行に伴い、従来使用していたSCMソリューションからも移行でき、さらなるコスト削減につながります。

GitLabには、リポジトリやそのメタデータを簡単にGitLabへと移行できるツールが用意されています。プロジェクトをGitLabへ移行する際に活用できるインポーターは以下のとおりです。

• GitHub
• 別のGitLabインスタンス
• Bitbucket Cloud
• Bitbucket Server
• FogBugz
• Gitea
• Jira（イシューのみ）
• manifestファイルによるリポジトリのインポート
• URLによるリポジトリのインポート

各インポーターは、プロジェクトから異なる種類のデータをインポートします。インポーターによりGitLabへ移行できるデータの詳細については、インポートとプロジェクトの移行に関するるドキュメントを参照してください。さらに、グループやプロジェクトのインポートを自動化したり、組織のニーズに合わせたカスタムソリューションを構築したりすることも可能です。

• プロフェッショナルサービス
• 移行ユーティリティ
• 移行に関するよくある質問

リポジトリを移行する方法

GitLabには組み込みのインポーターが用意されており、リポジトリの移行は簡単に行えます。例として、GitHubからGitLabへリポジトリをコピーし、そのリソース（イシュー、プルリクエスト、マイルストーンなど）も含めて移行する方法をご紹介します。別のGitHubからGitLabへリポジトリを移行するには、以下の手順に従ってください。

1. 左側のサイドバーの上部で、新規作成（+）を選択します。
2. 「GitLab」セクションで新規プロジェクト/リポジトリを選択します。
3. プロジェクトのインポートを選択します。

4. GitHubボタンをクリックします。

• GitLab Self-Managedを使用している場合は、GitHubインポーターを有効にする 必要があります。
  • 他のインポーターも同様の方法で開始できます。

5. 次に、以下のいずれかの方法で認証します。
   • GitHub OAuthで認証する場合：GitHubで認証を選択します。
   • GitHubのパーソナルアクセストークンを使う場合：
     • https://github.com/settings/tokens/newにアクセスします。
     • ノートフィールドにトークンの説明を入力します。
     • リポジトリスコープを選択します。
     • オプションとしてコラボレーターをインポートするには、read:orgスコープを選択します。
     • トークンの生成ボタンをクリックします。
     • GitLabのインポートページの「パーソナルアクセストークン」フィールドに、GitHubのパーソナルアクセストークンを貼り付けます。
6. 認証ボタンをクリックします。
7. 移行するアイテムを選択します。
8. 移行するプロジェクトと移行先を選択します。
9. インポートボタンを押します。

これで、インポートされたプロジェクトがワークスペースに追加されます。GitHubからGitLabへの移行に関する詳しいガイドについては、こちらの動画をご覧ください。

リポジトリの移行が完了したら、JenkinsのパイプラインでGitLab内のJenkinsfileを活用できるように設定できます。これは、Jenkinsのパイプライン設定メニューから、新しくインポートしたプロジェクトのリポジトリURLを指定することで実行できます。

の方法は、移行の初期段階でもJenkinsの既存の機能を維持しながらGitLabと並行して使用できるため、CI/CD機能の移行作業中にサービスが中断されるのを防げます。

さらに、GitLab Jenkinsプラグインを活用することで、移行をスムーズに進めることができます。このプラグインを使用すると、GitLabからJenkinsのビルドをトリガーしたり、ビルドのステータスを取得したりできるようになります。

CI/CDパイプラインを移行する

リポジトリの移行が完了したら、今度はJenkinsのパイプラインをGitLabへ移行できます。このプロセスは比較的シンプルですが、JenkinsとGitLabの両方の概念や構文を理解する必要があります。

Jenkinsには、パイプラインを定義するための構文として宣言型とスクリプト型の2種類があります。今回は、最も一般的に使用されている宣言型パイプラインからの移行方法を解説します。

パイプラインを段階的に移行する

このチュートリアルでは、Jenkinsfile（Groovy）とGitLab CI/CDの設定ファイル（YAML）を比較しながら、Go言語で書かれたマイクロサービスをビルド、テスト、デプロイする方法を分析します。その後、GitLabでパイプラインを有効化し、実際の動作を確認します。このパイプラインは以下の処理を行います。

• alpineタグ付きのGo言語コンテナイメージを使用する
• Go言語のコードを実行可能なバイナリにビルドするジョブを実行する
  • ビルドしたバイナリをアーティファクトとして保存する
• ユニットテストを実行するジョブを実行する
• stagingステージにデプロイするジョブを実行する
  • コミットがstagingブランチに向けたものである場合のみ実行される
  • testステージが成功した後に開始される
  • 以前のジョブで作成された実行可能なバイナリアーティファクトを使用する

以下に、JenkinsとGitLabのパイプライン定義とコメントを示します。実際のパイプラインの動作はMeow Migrationプロジェクトで確認できます。

では、Groovyで記述されたJenkinsfileを見ていきましょう。

// 宣言型パイプラインの
// トップレベルを定義します。
pipeline {

  // ジョブ内で明示的に定義されていない場合に
  // デフォルトで使用するエージェントを
  // 指定します。
    agent any

  // 数値順に実行される
  // ステージを定義します。各ステージは
  // 1つのジョブのみを実行します。
    stages {

    // ステージの名前を定義します。
        stage('build') {
      // このジョブで使用する
      // コンテナイメージを定義し、
      //デフォルトの'agent any'を上書きします。
      // 実行にはJenkins Docker
      // プラグインの設定が
      // 必要です。
            agent { docker 'golang:alpine' }

      // ステージが実行される際に
      // 実行する処理の順序を
      // 定義します。
            steps {
                sh 'go build -o bin/meow-micro'
                sh 'chmod +x bin/meow-micro'
            }

      // ステージ完了後に
      // 実行する処理を定義します。
            post {
              always {

        // 他のジョブで使用するために
        // ステージアーティファクトを
        // 保存します。
                archiveArtifacts artifacts: 'bin/meow-micro'
                onlyIfSuccessful: true
              }
            }
        }

    stage('test') {
            agent { docker 'golang:alpine' }
            steps {
                sh 'go test .'
            }
        }

        stage('deploy') {
      // このジョブを
      // 実行するための
      // 条件を定義します。この場合、
      // stagingブランチでのみ
      // デプロイジョブが実行されます。
            when {
              branch 'staging'
            }
            steps {
                echo 'Deploying meow-micro to staging'
        // buildステージで保存した
        // アーティファクトを使用します。
                sh './bin/meow-micro'
            }
        }
    }
}

では、同じ機能をGitLabで作成する方法について見ていきましょう。

# ジョブ内で明示的に定義されていない場合に
# デフォルトで使用するイメージを
# 指定します。
default:
  image: alpine:latest

# 実行するステージの順序を定義します。
# 各ステージには複数のジョブを含めることができます。
stages:
  - build
  - test
  - deploy

# ジョブ名を定義します。
create-binary:
 # このジョブが実行されるステージを定義します。
  stage: build
 # このジョブで使用するコンテナイメージを定義し、
 # デフォルトの設定を上書きします。
  image: golang:alpine
 # ジョブ実行時に実行する
 # 一連の手順を定義します。
  script:
    - go build -o bin/meow-micro
    - chmod +x bin/meow-micro
 # 他のジョブで使用するために
 # ジョブのアーティファクトを保存します。
  artifacts:
    paths:
      - bin/meow-micro
    expire_in: 1 week

unit-tests:
  stage: test
  image: golang:alpine
  script:
    - go test .
 # ジョブの実行後に実行するコマンドを
 # 定義します。
 after_script:
  - echo "Tests Complete"

staging-deploy:
  stage: deploy
 # ジョブの実行前に実行するコマンドを
 # 定義します。
  before_script:
    - apk update
  script:
    - echo "Deploying meow-micro to staging environment"
    - ./bin/meow-micro
 # このジョブが実行される
 # 条件を定義します。この
 # 場合、stagingブランチでのみ
 # staging-deployジョブが実行されます。
  rules:
    - if: $CI_COMMIT_BRANCH == 'staging'
 # buildジョブで保存されたアーティファクトを
 # このジョブで使用できるようにします。
  artifacts:
    paths:
      - bin/meow-micro

ご覧のとおり、JenkinsとGitLabの構文には多くの共通点があり、パイプラインの移行は比較的簡単です。ここでは基本的な例を紹介しましたが、両ツールの詳しい機能や概念の比較もぜひご確認ください。

JenkinsからGitLabへのマッピング方法を理解したところで、GitLabで同じ機能を持つパイプラインの作成を始めましょう。以下の手順でCI/CDを移行できます。

1. 先程GitLabに移行したリポジトリを開きます。

• 左側のサイドバー上部で検索または移動先… を選択します。
• プロジェクトを検索し、開きます。

2. パイプラインエディタを開きます。

• 左側のサイドバーからビルド > パイプラインエディタを選択します。

• パイプラインの設定 ボタンをクリックします。

3. .gitlab-ci.ymlに入力します。

• GitLab CIのパイプラインコードを追加します。

• 構文が正しいか検証します。

• パイプラインの構造を視覚化して確認します。

4. ファイルをmainブランチにコミットします。

• コミットメッセージを追加します。
• ブランチがmainになっていることを確認します。
• 「変更をコミットする」ボタンをクリックします。

ファイルがマージされると、定義されたパイプラインが実行されます。プロジェクトページのビルド > パイプラインから、実行中のパイプラインを確認できます。今回はmainブランチで実行されているため、create-binaryとunit-testsのジョブのみが表示されます。staging-deployのジョブは、stagingブランチでのみ実行されます。

stagingブランチを作成すると、以下のパイプラインが開始されるのを確認できます。

ジョブをクリックすると、その出力を確認できます。

このように、create-binaryジョブで保存されたアーティファクトが、staging-deployジョブで使用されることが確認できます。これだけの手順で、JenkinsのパイプラインをスムーズにGitLabへ移行できます！

移行に関するその他の考慮事項

デプロイプロセスをよりシンプルにするために役立つポイントとして、以下の点を考慮することをおすすめします。

• タスクをそのまま1:1でGitLabのジョブに移行しようとしない：既存のパイプラインが何を行っているのか、どのような問題を解決しているのかを整理し、理解する時間を確保することが重要です。

• 一部のJenkinsジョブは複雑すぎてすぐにGitLabに移行できない場合がある：そのため、GitLab Jenkinsプラグインを活用し、JenkinsのパイプラインをGitLabから直接起動し、結果を表示できるようにするとよいでしょう。これにより、一部の処理を徐々にGitLabに移行し、最終的にパイプライン全体をGitLabへ統合できます。

• GitLabが提供する組み込みテンプレートを活用し、セキュリティスキャナーやコード品質チェックを最初から導入する：これにより、セキュリティのシフトレフトを行い、漏洩のリスクを低減できます。 また、CI/CDの設定を過度に複雑にしないようにし、すべての機能を一度に活用しようとするのではなく、コードをモジュール化し、複数の小さなステップに分けて導入するようにしてください。

• モニタリングとガバナンスを最初から実装する。

• GitLab Runner（Go）はJenkinsエージェント（Java）とは動作が異なる可能性があることを理解する：CPU使用率やメモリ消費量が異なる可能性があるため、時間をかけて比較しながら調整する必要があります。

• 自動スケーリングの導入を検討し、週末や業務時間外に不要なリソースをシャットダウンすることを検討する。

• ジョブのコンテナ化を進め、アプリケーション開発をモダナイズする：現在ではJenkinsのジョブはコンテナ上ではなく、仮想マシン（VM）として動作するJenkinsエージェント上で実行されます。

このリストはすべての考慮事項を網羅しているわけではありませんが、移行を進めるうえで重要なポイントを押さえています。さらにサポートが必要な場合は、GitLabのプロフェッショナルサービスを活用し、移行プロセスをスムーズに進めることも可能です。

関連リンク

ここまでお読みいただきありがとうございます！本ガイドが、JenkinsからGitLabへ移行するメリットと手順を理解する助けとなれば幸いです。まだ迷っている方は、ぜひGitLabの無料トライアルでDevSecOpsプラットフォームの価値を実感してください！

さらに詳しく知りたい方のために、GitLabの機能やDevSecOpsプラットフォームのメリット、Jenkinsからの移行に関する情報を学べるリソースをいくつかご紹介します。

• Jenkinsからの移行（英語）
• 移行計画の立て方（英語）
• GitLabプロジェクトインポーター（英語）
• チュートリアル：簡単にできるGitHubからGitLabへの移行（英語）
• 動画：簡単にできるGitHubからGitLabへの移行（英語）
• JenkinsからGitLabへ: CI/CD環境をモダナイズするための究極ガイド（英語）

監修：小松原 つかさ　 @tkomatsubara
（GitLab合同会社 ソリューションアーキテクト本部 シニアパートナーソリューションアーキテクト）