DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ DevOpsツールとベストプラクティスの習得 - DevOpsナレッジハブ

Jenkinsと人気ツールの統合：実践的な概要

Jenkinsを必須の開発ツールと統合することで、CI/CDワークフローを強化する方法を学びましょう。この実践的な概要では、バージョン管理のためのGit、コンテナ化のためのDocker、およびさまざまなテストフレームワークとのシームレスな統合について説明します。ビルド、テスト、デプロイプロセスを自動化するための実用的な例とベストプラクティスを見つけ、より迅速なリリースとソフトウェア品質の向上を実現します。

Jenkinsと人気ツールの統合：実践的な概要

Jenkinsは、チームがすでに使用しているツール（コード用のGit、イメージ用のDocker、フィードバック用のテストフレームワーク、リリース用のアーティファクトリポジトリ）と連携できるようになって初めて有用になります。目的は、見つけられるすべてのプラグインをインストールすることではありません。目的は、コードをチェックアウトし、ビルドし、テストし、結果を公開する明確なパイプラインを構築することです。

この実践的な概要では、Jenkinsの統合が通常どのように組み合わされるか、そしてチームがよく間違えるポイントを示します。

ソース管理から始める

ほとんどのJenkinsパイプラインはGitチェックアウトから始まります。パイプラインジョブでは、Jenkinsはジョブで設定されたリポジトリを使用してcheckout scmを実行するか、Jenkinsfileでリポジトリを定義できます。

マルチブランチパイプラインの場合、通常はこれで十分です：

pipeline {
    agent any

    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
    }
}

マルチブランチジョブは、インストールおよび設定したプラグインに応じて、GitHub、GitLab、Bitbucket、またはその他のGitサーバーからブランチとプルリクエストを検出します。

単純なパイプラインジョブの場合、明示的なチェックアウトが表示されることがあります：

git url: 'https://github.com/example/app.git', branch: 'main'

プライベートリポジトリにはJenkinsの認証情報を使用してください。リポジトリURLにトークンを入れないでください。

ポーリングよりもWebhookを優先する

JenkinsはGitの変更をポーリングできますが、Webhookの方がクリーンです。Gitプロバイダーは、誰かがコードをプッシュしたりプルリクエストを開いたりするとJenkinsにリクエストを送信し、Jenkinsは該当するジョブを開始します。

典型的なセットアップは次のようになります：

  1. GitHub Branch SourceやGitLab Branch Sourceなど、Gitプロバイダー用のJenkinsプラグインをインストールします。
  2. マルチブランチパイプラインジョブを作成します。
  3. リポジトリまたは組織ソースを追加します。
  4. Jenkinsの認証情報に資格情報を保存します。
  5. Gitプロバイダーの設定にWebhook URLを追加します。

ポーリングは制限されたネットワークでも機能しますが、遅延が発生し、不要な負荷がかかります。

Dockerイメージのビルドとプッシュ

Jenkinsは、ビルドを実行するエージェントがDockerにアクセスできる限り、Dockerイメージをビルドできます。これは、DockerがインストールされたVM、KanikoやBuildKitなどのビルドツールを使用するKubernetesエージェント、または制御されたDockerソケットセットアップである可能性があります。

以下は、シンプルなDockerビルドとプッシュのフローです：

pipeline {
    agent any

    environment {
        IMAGE = 'registry.example.com/team/app'
    }

    stages {
        stage('Build Image') {
            steps {
                sh 'docker build -t $IMAGE:$BUILD_NUMBER .'
            }
        }

        stage('Push Image') {
            steps {
                withCredentials([usernamePassword(
                    credentialsId: 'registry-login',
                    usernameVariable: 'REGISTRY_USER',
                    passwordVariable: 'REGISTRY_PASSWORD'
                )]) {
                    sh '''
                        echo "$REGISTRY_PASSWORD" | docker login registry.example.com \
                          --username "$REGISTRY_USER" --password-stdin
                        docker push "$IMAGE:$BUILD_NUMBER"
                    '''
                }
            }
        }
    }
}

重要な詳細は--password-stdinです。これにより、コマンドラインでレジストリパスワードが公開されるのを防ぎ、docker login -pよりも安全です。

テストの実行と結果の公開

Jenkinsはテストを実行するためにテストフレームワークを理解する必要はありません。ビルドコマンドがJenkinsで読み取り可能なレポート形式を生成する必要があります。

JUnit形式のXMLレポートを使用するMavenプロジェクトの場合：

pipeline {
    agent any

    stages {
        stage('Test') {
            steps {
                sh 'mvn test'
            }
            post {
                always {
                    junit 'target/surefire-reports/*.xml'
                }
            }
        }
    }
}

post { always { ... } }ブロックが重要です。テストが失敗した場合でもテスト結果を公開するため、Jenkins UIで失敗を確認できます。

Python、JavaScript、Goプロジェクトでも、互換性のあるレポートを出力すれば同じパターンを使用できます。たとえば、多くのPythonチームはpytest --junitxml=reports/junit.xmlを実行し、その後reports/junit.xmlを公開します。

ビルド出力をアーティファクトリポジトリに保存する

Jenkinsワークスペースを長期ストレージとして扱わないでください。ワークスペースは一時的なものであり、エージェントがクリーンアップされると消える可能性があります。

リリース出力には、Nexus、Artifactory、コンテナレジストリ、クラウドオブジェクトストレージなどのアーティファクトリポジトリを使用します。JenkinsはarchiveArtifactsを使用して小さな診断ファイルをアーカイブできますが、本番パッケージは保持とアクセス制御のために設計されたシステムに保存する必要があります。

ビルドログやレポートを実行に関連付けて保持する例：

post {
    always {
        archiveArtifacts artifacts: 'reports/**', allowEmptyArchive: true
    }
}

これはビルド証跡として使用し、唯一のリリースリポジトリとしては使用しないでください。

認証情報をパイプラインではなくJenkinsに保持する

Jenkinsの認証情報は、ユーザー名、パスワード、SSHキー、トークン、シークレットファイルを保存できます。パイプラインは、シークレット値ではなくcredentialsIdを参照する必要があります。

シェルコマンドの場合、認証情報は必要なステップの周囲でのみバインドします：

withCredentials([string(credentialsId: 'slack-webhook', variable: 'SLACK_WEBHOOK')]) {
    sh 'curl -X POST -H "Content-type: application/json" --data "{\"text\":\"Build complete\"}" "$SLACK_WEBHOOK"'
}

スコープを小さく保ちます。これにより、ログや後続のコマンドを通じてシークレットが漏洩する可能性が低くなります。

後で追加すると便利な統合

コアパイプラインが安定したら、実際のワークフローのニーズに基づいて統合を追加します：

ツールタイプ 一般的な用途
Gitプロバイダー ブランチ検出、プルリクエストビルド、コミットステータス更新
Dockerまたはイメージビルダー コンテナイメージのビルドと公開
テストレポート 失敗、傾向、不安定なテストの表示
アーティファクトリポジトリ ビルド出力とリリースパッケージの保存
チャットまたはインシデントツール 失敗またはリリースされたビルドに関する適切なチャネルへの通知
セキュリティスキャナー リリース前の依存関係、イメージ、またはソースコードのチェック

統合は一度に1つ追加し、パイプラインが明確に失敗することを確認します。有用なJenkinsセットアップは、最も良い意味で退屈です。つまり、開発者がコードをプッシュし、Jenkinsがそれをビルドし、テストし、アーティファクトを公開し、失敗が発生した場所を正確に示します。