現在さまざまな方法でDevOps CI/CD環境を実現できます。 そういった分野でJenkinsも使われてきました。
以前は私もJenkinsを使っていたものの最近触っていないなと思い触り始めたのですが、Jenkinsのバージョン2以降、Jenkins Pipelineという機能が追加されてJenkinsというとGUIでぽちぽち設定するものと思っていたのが割と最近の流行にのっているなと思い、色々調べてみることにしました。
Jenkins Pipelineの基本
Jenkinsは従来の方法でジョブを作成する「フリースタイルプロジェクト」を使う方法もありますが、「パイプライン」というものが追加されています。
パイプラインは次のような形式で作業を記述していくものです。まずは一番単純な例です。 このパイプラインはPython 3.8を使って、Pythonスクリプトを実行するというジョブです。
pipeline { agent { label 'linux' } stages { stage('Tested with python 3.8') { steps { sh 'python3.8 /home/jenkins/test.py' } } } }
Jenkinsのダッシュボードから、「ビルド実行」をクリックすると、書いた処理が指定したマシンで実行されます。今回の例の場合、ノードに「linux」というラベルが含まれるマシンで処理が実行されます。
実行するここのような感じです。成功した、失敗したにかかわらずログを見ることができますので、安心ですね。
例えば一つのジョブで複数の作業をしたい場合、単純に「Stage」を追加するだけでよくなります。複数の「Stage」が含まれる「Stages」が正常に実行されるとジョブ成功、何らかの問題があればジョブ失敗になります。
pipeline { agent { label 'linux' } stages { stage('Tested with python 3.8') { steps { sh 'python3.8 /home/jenkins/test.py' } } stage('Tested with python 3.9') { steps { sh 'python3.9 /home/jenkins/test.py' } } } }
Slack側の設定も必要ですが、Jenkinsに「Slack Notification」 を追加すると、パイプラインの成功可否をSlackで通知できます。設定次第ではメール通知も可能です。
パイプラインは次のように書くことができます。
pipeline { agent { label 'linux' } stages { stage('Tested with python 3.8') { steps { sh 'python3.8 /home/jenkins/test.py' } post { success { slackSend( message: "py38testは成功 (<${env.BUILD_URL}|Open>)", ) } failure { slackSend( color: "#FF0000", message: "py38testは失敗 (<${env.BUILD_URL}|Open>)", ) } } } stage('Tested with python 3.9') { steps { sh 'python3.9 /home/jenkins/test.py' } post { success { slackSend( message: "py39testは成功 (<${env.BUILD_URL}|Open>)", ) } failure { slackSend( color: "#FF0000", message: "py39testは失敗 (<${env.BUILD_URL}|Open>)", ) } } } } }
このようなパイプラインをスクリプトの入力ボックスに入力すれば、ジョブの設定完了です。
実行すると、次のようにSlackで通知されます。
Git連携したJenkins Pipeline
これをGitと連動するには、JenkinsのGitとGitHubプラグイン(ともに標準インストール済み)を使ってジョブを作成することで実現できます。
例えば、次のようなリポジトリーでアプリケーションを開発している前提とします。
別の検証のためにGitLab CIのファイルもあったりしますが(それは見なかったことにしてもらって)、ここで重要なのはリポジトリーにあるJenkinsfileという名前のファイルです。
Jenkinsはデフォルトでこの名前のファイルをJenkinsのPipelineを定義したファイルとして読み込みます。このファイルは必ずしもプロジェクトのルートディレクトリに置く必要はありませんが、別のパスにおいた場合は設定で正しいパスを指定する必要があります。
あとは先ほどと同様に新しいPipelineを作って、Gitリポジトリーの設定を記述していくだけです。
コミットと連動させるためには「SCMをポーリング」を設定すると良いでしょう。
最後にJenkinsfileのパスを設定します。
こんな感じですね。
GitHub プロジェクトソースに対して変更を加えてコミットすると、Jenkins CIが自動的に走ります。
まとめ
全てのコミットと連動してCI処理が走ると困るという場合は、ブランチ戦略を考えてみるといいと思います。例えばFuture, Test, PatchのようなブランチではJenkinsのようなものを使ってCI/CD処理を行い、メインブランチでは特に行わないというのも一つのアイデアです。
Jenkinsは動かしている環境のリソースを使い潰さない限りいくらでもジョブを設定できますので、それぞれのブランチごとに別々の作業を自動実行するように設定するのも自由です。
特定のSCMに依存している限りそちらのAPI制限についても考慮する必要はありますが、自環境でJenkinsを動かしていればCI/CDについてはいくら実行しても課金されることはありません(電気代はかかりますけどね)。