はじめに

こんにちは。テクマトリックスの長久保です。

Part.1に引き続き、JenkinsでCIを構築する際にハマるポイントとして実際に経験したり、よくありそうな内容を整理していきたいと思います。

Part.1ではCI化する際の基礎知識や、バッチファイルをJenkinsから実行する場合によくあるトラブルについて整理していますので、併せて参照いただければ幸いです。

文字コード・改行コード

文字コード（Shift-JIS / UTF-8 の不一致）

• 状態：Jenkinsのコンソール出力で日本語が文字化けする。バッチ内の日本語パスやファイル名が認識されずエラーになる。
• 原因：バッチがShift-JIS前提で書かれているが、JenkinsのコンソールがUTF-8になっている(バッチとJenkinsのコンソールの文字コードの不一致)。

具体例

Shift-JISで保存されたbuild.batをJenkinsで実行すると以下のようにエラーになります。

繝薙Ν繝峨ｒ髢句ｧ九＠縺ｾ縺・  ← 文字化け
'src\荨鐺繝輔ぃ繧､繝ｫ.xml' が見つかりません  ← ファイル名を認識できずエラー

パイプライン側で吸収する方法

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                // chcp でコードページを Shift-JIS に設定してからバッチを呼ぶ
                bat 'chcp 932 > nul && build.bat'
            }
        }
    }
}

バッチを呼び出す前にchcpを使って文字コードを指定して実行することができます。chcpの詳細はこちらを参照してください。
コンソールの文字化けが気にならない(バッチファイルが正常に実行できていればよい)場合は、chcpだけで十分です。
また文字コードの指定については、Part.1の「おすすめのbatコマンドの使い方」で紹介した、batステップのencodingを指定して実行する方法もあります。chcpがバッチの実行時のコードページを変更するのに対し、encodingはJenkinsがバッチの出力をコンソールに表示する際のデコードに使用するものです。

steps {
    // encoding を指定すると Jenkins コンソール上の文字化けを防げます
    bat encoding: 'MS932', script: 'build.bat'
}

chcp 932でバッチ側のコードページを合わせつつ、encoding: ‘MS932’でJenkins側のデコードも合わせることで、ファイル名の認識エラーとコンソールの文字化けの両方を防げます。

Jenkins側で吸収する方法(非推奨)

Jenkins自体の文字コードを変更することでも対応ができますが、バッチだけでなく、Jenkinsfileの文字コードも考慮する必要が出てくるなど、影響範囲が大きくなります。もし可能であれば、該当のバッチファイルの文字コード自体を変更したり、 上記のパイプライン側で吸収する方法で対応するのが安全かと思います。
なお、Jenkinsの文字コードの確認は、Jenkinsのダッシュボード > Jenkinsの管理 > システム情報から確認できます。

もしこれをMS932に変更したい場合はJenkinsの起動オプションに追加します。
WindowsでJenkinsのインストーラーを使用してJenkinsを起動している場合、jenkins.xmlの該当の箇所に追加して、Jenkinsを再起動すると設定が反映されます。

-Dfile.encoding=MS932

ただ、デフォルトのencoding関連の設定だけで「file.encoding」「native.encoding」「stderr.encoding」「stdout.encoding」「sun.io.unicode.encoding」「sun.jnu.encoding」とあり、影響範囲も判断しづらいため、bat自体のエンコーディングを変更するか、上記の「パイプライン側で吸収する方法」で対応したほうが良いと思います。

改行コード（CRLF/LFの変換）

• 状態：バッチファイルの実行時に構文エラーが発生する。
• 原因：Gitのcore.autocrlf設定により、チェックアウト時にCRLFがLFに変換され、cmd.exeが正しく解釈できなくなる。

具体例

バッチ実行で以下のエラーメッセージが表示され、異常終了する。

\build was unexpected at this time.

レアケースかと思いますが、こういった状況も起こりうるかと思います。
参考：.cmd file gives error was unexpected at this time.

この場合、.gitattributesをリポジトリのルートに配置して、改行コードを指定するとよいでしょう。

*.bat text eol=crlf
*.cmd text eol=crlf

パス・ファイルシステム

Windowsの260文字パス長制限

• 状態：チェックアウトやビルド時に「ファイル名または拡張子が長すぎます」というエラーが発生したり、ファイルの削除・更新に失敗して意図しない動作をする。
• 原因：Jenkinsのワークスペースパス+リポジトリ内のパスがWindowsの260文字パス長制限を超えている。

具体例

Jenkinsのワークスペースの文字長を考慮する必要があります。
エージェントのリモートFSルートが「C:\Jenkins-agent」、ジョブ名が「my-organization_my-project」、MultibranchPipelineでmainブランチを対象として実行した場合、次のパスがリポジトリのルートディレクトリになります。

C:\Jenkins-agent\workspace\my-organization_my-project_main

同一ジョブが同時に実行された場合、my-job_main@tmpといった文字列になり、さらにパスは長くなります。このようにワークスペースのパスだけで60文字程度を消費し、リポジトリ内の深いパスが加わると260文字を超えてしまう場合があります。

現実的な対策

エージェントのリモートFSルートのパスを短くし、ジョブの名称も短くし、260文字を超えないようにすることで対応するのが良いでしょう。

Multibranch Pipelineでは実ジョブ名と表示名を変更することができます。

このような工夫をしても文字列が260文字を超えてしまう場合は、ソースコードのパスの方を変更することを推奨します。

パイプライン側で吸収する方法(非推奨)

pipeline {
    agent any
    options {
        ws('C:\\ws\\proj')
    }
    stages {
        stage('Checkout') {
            steps {
                checkout scm
            }
        }
    ……
}

agent {
    label {
      label 'test'
      customWorkspace "C:\\a\\${env.JOB_NAME}"
    }
}

customWorkspaceやws{ }を用いることで一時的にワークスペースを変更することは可能ですが、同時実行時に支障をきたしたり、冪等性が担保できなくなる要因になる可能性があるため、一時的な回避方法や特殊な例を除いて推奨しません。

同時ビルドのワークスペース競合

• 状態：うまくいくときもあるが、ビルドが「ファイルが見つからない」等で失敗したり、意図しないコードが処理されたりする。ログを見るとワークスペースがmy-job_main@2のようなサフィックス付きになっている。
• 原因：同一ジョブの複数ビルドが同時に実行された際に、Jenkinsがワークスペースを分離するためにサフィックスを付与する。その結果、ハードコードされたパスが破綻する。

具体例

以下のようにバッチ内でワークスペースのパスをハードコードしているとします。

@echo off
set OUTPUT_DIR=C:\Jenkins\workspace\my-job\build\output
xcopy /s /e "%OUTPUT_DIR%" "\\server\deploy\"

ジョブを1つ走らせる場合はうまくいきますが、2つ目のビルドのワークスペースは C:\Jenkins\workspace\my-job@2 になります。
しかしバッチはハードコードされたmy-jobを見に行くため、1つ目のビルドの成果物をデプロイしてしまいます。

バッチを改修する場合の対策

可能であればこちらの対策を推奨します。
ワークスペースのパスを引数として受け取るようにしパイプラインからパスを渡したり、Jenkinsが提供する環境変数を利用するように修正します。

pipeline {
    agent any
    stages {
        stage('Deploy') {
            steps {
                // バッチにワークスペースのパスを引数として渡す
                bat "deploy.bat \"%WORKSPACE%\""
            }
        }
    }
}

@echo off
REM OK: Jenkinsが提供する環境変数(%WORKSPACE%)を使う
set OUTPUT_DIR=%WORKSPACE%\build\output
xcopy /s /e "%OUTPUT_DIR%" "\\server\deploy\"

パイプライン側で吸収する方法

パイプラインのオプションで同時実行が走らないようにすることも可能です。

pipeline {
    agent any
    options {
        disableConcurrentBuilds()
    }
    stages {
        // ...
    }
}

ただ、このようにすると、ジョブがキューに待機し続け、スループットが低下するケースもあります。

Jenkins側で吸収する方法

こちらも根本解決にはなりませんが、一時的にJenkinsのエグゼキューターを1にすることで、「ジョブを同時に実行しない」状態を作ることは可能です。

ただ、ライセンスなどの制約がないにもかかわらず、並列処理を禁止するのはマシンリソースの無駄になる場合が多いので、バッチを修正し、相対パスでの実行ができる状態にすることを推奨します。

ファイル関連のレアケース

上記以外にも例えば、「ウイルス対策ソフトがファイルをスキャンしてロックしてしまい、パイプライン内でファイルを書き換えようとして失敗する」、「Jenkinsコントローラーマシンのディスク容量不足により、一時ファイルの作成に失敗する」なども可能性としてはあり得ます。

こういったケースの場合はログファイルを確認し、問題を切り分けていくことになります。

Jenkinsのログは各ジョブのコンソール画面以外にも、Jenkinsダッシュボード > Jenkinsの管理 > システムログからも確認することが可能です。

Add recorderボタンをクリックし、確認したいログを追加することができます。
ファイルロック系であれば「hudson.FilePath」 「hudson.FileSystemProvisioner」などを追加すると、何かログを拾えるかもしれません。

ネットワーク・認証

プロキシ

• 状態：外部リポジトリからの依存パッケージのダウンロードが失敗する。npm install、nuget restore、pip installなどがタイムアウトする。
• 原因：企業ネットワーク内でプロキシが必要だが、Jenkinsエージェントのサービスアカウントにプロキシ設定がされていない。

具体例

ブラウザではインターネットに接続できるのに、Jenkins上ではタイムアウトが発生します。

npm ERR! network request to https://registry.npmjs.org/express failed, reason: connect ETIMEDOUT

一般にブラウザはWindowsの「インターネットオプション」のプロキシ設定を使いますが、サービスアカウントで動くJenkinsエージェントにはこの設定が適用されないことがあります。
また、Jenkinsエージェントを利用して分散ビルドをしている場合、Jenkinsコントローラーのマシンにはプロキシ設定がされていても、エージェントマシンに設定がされておらず実行できないといった場合も考えられます。

Jenkins自体のプロキシ設定はJenkinsのダッシュボード > Jenkinsの管理 > System以下(古いバージョンのJenkinsを利用している場合はJenkinsのダッシュボード > Plugins > Advanced settings)で設定できます。

パイプライン側で吸収する方法

パイプラインの環境変数に埋め込むことで、batから実行する際にプロキシ設定を反映させることも可能です。

pipeline {
    agent any
    environment {
        HTTP_PROXY  = 'http://proxy.example.co.jp:8080'
        HTTPS_PROXY = 'http://proxy.example.co.jp:8080'
    }
    stages {
        ……
    }
}

Windowsの資格情報マネージャーがユーザーごとに設定されている

• 状態：手動実行時は認証が通るリポジトリやネットワーク共有へのアクセスが「アクセスが拒否されました」とエラーになる。
• 原因：資格情報マネージャーに保存した認証情報はユーザープロファイルに紐づくため、サービスアカウントからは参照できない。

具体例

例えばGitの認証として、開発者が手動でgit clone https://git.example.co.jp/repo.gitを実行すると、初回にID/パスワードを入力し、Windows資格情報マネージャーに保存され、以降は認証なしでアクセスできるようになります。ただ、Jenkinsエージェント（SYSTEMアカウントやサービスアカウント）で同じコマンドを実行すると「fatal: Authentication failed for ‘https://git.example.co.jp/repo.git’」といったエラーが発生することがあります。

基本的にJenkinsで宣言型パイプラインを書く場合は、Jenkinsに登録した認証情報を元にGitの処理を行うため発生しませんが、次のように明示的にパイプライン内でコマンドを実行した場合は発生することがあります。例えば以下のように単体のリポジトリだけではビルドができずパイプライン内で複数リポジトリからcloneする必要がある際に発生します。

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                git url: 'https://git.example.co.jp/repo.git'
                //処理
            }
        }
    }
}

前述の通り、資格情報マネージャーに保存した認証情報はユーザープロファイルに紐づくため、サービスアカウントからは参照できず発生します。ローカルマシンの資格情報マネージャーに認証情報を登録するか、パイプラインで認証情報を付与することで解消できます。

パイプライン側で吸収する方法

clone時にJenkinsの認証情報を参照して解決することもできます。

pipeline {
    agent any
    stages {
        stage('Checkout') {
            steps {
                // Jenkins に登録した認証情報 ID を指定
                git url: 'https://git.example.co.jp/repo.git',
                    credentialsId: 'git-server-credentials'
                //処理
            }
        }
    }
}

類似例として、git cloneの際に自己署名証明書のSSLエラーも考えられます。この場合はユーザーの証明書ストアではなく、マシン全体で有効にすることで解消できます。

実行ユーザー・権限

エージェントの実行ユーザー

• 状態：手動では動くバッチがJenkins上で「アクセスが拒否されました」等の権限エラーで失敗する。
• 原因：Jenkinsエージェントがローカルシステムアカウントやサービス用の限定アカウントで動作しており、開発者のユーザーアカウントとは権限が異なる。

具体例

現在動作しているJenkinsのアカウントは、Windowsでインストールしている場合は「サービス」から確認できます。

対策

Jenkinsエージェントのサービスのログオンアカウントを適切な権限を持つアカウントに変更する必要があります。また、必要に応じてフォルダ・リソースへのアクセス権をサービスアカウントに付与する場合もあります。

以下のパイプラインを実行すると問題の切り分けができるかもしれません。

pipeline {
    agent any
    stages {
        stage('Debug') {
            steps {
                bat 'whoami'
                bat 'echo USERPROFILE=%USERPROFILE%'
            }
        }
    }
}

開発者が実行した場合、whoamiの結果は mycompany\username のようなドメインアカウントになるため、アクセス権やプロファイルが異なることが確認できます。

環境変数の差異

• 状態：java、python、msbuild 等のコマンドが「認識されていません」エラーになる。
• 原因：ユーザー環境変数とシステム環境変数が異なる。サービスアカウントにはユーザー環境変数が設定されていない。

具体例

開発者PCや手動で実行した際は正常に完了するが、Jenkinsエージェントで実行すると以下のように表示されることがあります。

'java' は、内部コマンドまたは外部コマンド、
操作可能なプログラムまたはバッチ ファイルとして認識されていません。

これは環境変数がユーザー環境変数にしか付与されておらず、Jenkinsを実行しているユーザーには設定されていないことにより発生します。

パイプライン内でsetコマンドを実行するか、Jenkinsダッシュボード > Jenkinsの管理 > システム情報 > 環境変数タブ > Pathでも確認できます。

対策

Jenkinsの実行ユーザーを設定済みのユーザーで実行するか、Jenkinsを実行しているユーザーでも参照できるように環境変数を定義します。

これ以外にも実行ユーザーによる問題はGitの.gitconfigの設定やパイプライン内で実行するツールの権限情報など多岐にわたります。
Jenkinsを「なんのユーザーで実行しているのか」「どの権限が必要なのか」は常に意識すると良いでしょう。

実行環境の差異

タイムゾーン・ロケールの差異

• 状態：ログのタイムスタンプがずれる。日付を含むファイル名やフォルダ名が想定と異なる。日付の比較処理が誤動作する。
• 原因：Jenkinsサーバーのタイムゾーンやロケール設定が開発機と異なる。

具体例

バッチ内で %date% を使ってフォルダ名を生成しているケース。

@echo off
REM 日付でバックアップフォルダを作成
set BACKUP_DIR=backup_%date:/=-%
mkdir %BACKUP_DIR%

開発者のPCでは%date%が2026/03/16を返すところ、Jenkinsサーバーのロケール設定によっては Mon 03/16/2026 のような形式になり、フォルダ名に使えない文字（スペース）が混入してエラーになることもあります。またタイムゾーンの違いにより、想定と違った日付が取得されることもあります。

パイプライン側で吸収する方法

Groovyで日付を生成し、環境変数として渡します。

pipeline {
    agent any
    environment {
        BUILD_DATE = new java.text.SimpleDateFormat('yyyy-MM-dd').format(new Date())
    }
    stages {
        stage('Backup') {
            steps {
                bat 'mkdir backup_%BUILD_DATE%'
                bat 'backup.bat'
            }
        }
    }
}

ロケールだけでなく、タイムゾーンも指定する場合は以下のように記載することもできます。

def now = new Date()
def formatter = new java.text.SimpleDateFormat("yyyy-MM-dd")
formatter.setTimeZone(TimeZone.getTimeZone("Asia/Tokyo"))
def dateStr = formatter.format(now)

Jenkinsのログなども含め、Jenkins全体のタイムゾーンを変更する場合、起動オプションに「-Dorg.apache.commons.jelly.tags.fmt.timeZone=Asia/Tokyo」を追加すると、Jenkins UI上の表示タイムゾーンを統一できます。

パイプライン自体のハマりポイントや機能紹介

ここまでは、「すでにバッチファイルは作成済みの開発環境をJenkinsに乗せた場合にハマるポイント」を紹介してきました。

ここからはTips集のような、パイプラインで実現したいことをどう実現することができるか、という点をいくつか紹介します。

バッチの実行結果に応じて処理を書き換える

batステップはデフォルトでは終了コードが0以外の場合、ビルドを即座に失敗させます。
大前提として、パイプラインで条件分岐や複雑な処理を書くのは推奨しません。ただ、「失敗しても後続処理を続けたい」「終了コードに応じて処理を分岐したい」というケースがあったとします。

その場合、returnStatusおよびパイプラインのscriptステップを利用することで実現できます。

stages {
    stage('Build') {
        steps {
            script {
                def buildResult = bat(script: 'build.bat', returnStatus: true)
                if (buildResult == 0) {
                    echo 'ビルド成功'
                } else {
                    echo "ビルド失敗（終了コード: ${buildResult}）"
                    // ここで独自の後処理を記載する。
                    // エラーステータスを'UNSTABLE'として上書きする
                    currentBuild.result = 'UNSTABLE'
                }
            }
        }
    }
}

このように書くことでパイプラインの中で処理を分岐することができます。(ただし、パイプライン内で条件分岐を増やしすぎると、デバッグのしづらさから著しく可読性が落ちるため、最低限に抑えることを推奨します。)

バッチ内で動的に生成される値をパイプライン内で利用する

例えば、静的解析バッチを実行した際に作成される静的解析の違反件数やダッシュボードのURLを通知の文面に乗せたいといったケースです。

steps {
    script {
        def version = powershell(
            script: 'Get-Content -Path version.txt -Encoding UTF8',
            returnStdout: true
        ).trim()
        echo "バージョン: ${version}"
    }
}

returnStdoutを用いることで、上記のように取得することが可能です。

また、バッチ内でechoや、PowerShell内でWrite-Outputで標準出力し、パイプライン内でキャプチャし、文章を作成するということも考えられます。

REM Key・Value形式で出力し、パイプライン内でパースする
echo VIOLATION_COUNT=3
echo DASHBOARD_URL=https://example.com/reports/run/12345

冪等性のあるCI環境にする

冪等性とは「同じ操作を何度繰り返しても、結果が変わらない性質」のことです。CIは日に何度も実行するため、コードに依存しない箇所で実行結果が変わることは避ける必要があります。
手動でスクリプトを実行している場合、以下のような状態になっていることも多いです。

• 手動でワークスペースを削除してからビルドバッチを実行する。
• バージョン番号や参照するライブラリファイルを手動で入れ替えてから実行する。
• 環境変数を対象のプロジェクトに応じて変更する必要がある。
• 設定ファイルをリポジトリ管理外に配置しており、config.propertiesや.envファイルを手動で書き換える必要がある。

このような状態はCI環境を実現するときの大きな障害になります。
可能な限りCIに関連する設定ファイルやスクリプトはリポジトリ内に配置し、リポジトリ内のファイルのみで処理が完結するようにすることを推奨します。本ブログのPart.1「推奨するリポジトリ構成の例」でも触れましたが、以下のようにビルドスクリプトもリポジトリに配置する方が安定します。

リポジトリのルート/
  src/                   ← ソースコード
    ・・・
  scripts/               ← ビルド・デプロイ用バッチ
    build.bat
    deploy.bat
    test.bat
  Jenkinsfile            ← パイプライン定義

また、Jenkinsはデフォルトでワークスペースをビルド間で再利用します。これは不要なチェックアウトを避け、高速化に寄与しますが、前回のビルド成果物が残っていると誤動作の原因になる場合もあります。

よくある問題

• 前回ビルドの成果物が残っていて、今回のビルドが失敗しているのに成果物チェックが通ってしまう
• 前回のテスト結果ファイルが残っていて、テスト件数が二重にカウントされる
• 削除されたはずのソースファイルがワークスペースに残っていてコンパイルが通ってしまう

構成管理がGitの場合はJenkinsのジョブの設定で「Clean before checkout」や「Clean after checkout」があります。

また、cleanWs()を用いることで、明示的にパイプライン内でクリーンアップを指定することも可能です。

pipeline {
    agent any
    options {
        // チェックアウト前にワークスペースを毎回クリーンアップします
        cleanWs()
    }
    stages {
        ……
    }
}

cleanWs() はWorkspace Cleanup プラグインの機能です。プラグインを導入できない場合はdeleteDir()や直接ワークスペースフォルダを削除するbatコマンドを書いてもいいかもしれません。
毎回すべてのコードをチェックアウトすると時間がかかる場合は、成果物ディレクトリなど、特に関連する箇所のみ削除する方法もあります。

いずれにせよ、何回CIを実行しても結果が変わらないという状態を作ることはとても重要です。

Groovy Sandboxの制約

宣言型パイプラインはGroovy Sandbox(Script Securityプラグイン内の機能)の中で実行されます。new File()、System.getenv()、外部ライブラリの利用など、Sandboxで許可されていないAPIを呼ぶと以下のようにエラーが発生します。

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException:
  Scripts not permitted to use new java.io.File java.lang.String

ホワイトリストについては、GitHub上で確認が可能です。

対策1：そもそもGroovyでやらずにバッチで実行する

宣言型パイプラインのベストプラクティスとして「複雑なことはせずシンプルに保つ」という考え方があります。
宣言型パイプラインのGroovyは処理速度の面や、デバッグのしにくさ、Jenkins固有の制約による書きづらさといった課題があります。そのため、Groovy側にはパイプラインの流れの制御や外部スクリプトの呼び出し、結果の受け取りといった最小限の役割を持たせて、実際の処理はbatやPowerShell、Pythonなどの外部スクリプトに委ねるのが望ましいです。

対策2：Script Approvalで許可する
Jenkinsダッシュボード > Jenkinsの管理 > In-process Script Approvalで保留中のリクエストを承認します。

許可することで、次回以降パイプラインはエラーになることなく実行することができるようになります。

安全なCI環境を構築する

Jenkinsはデフォルトでは実行中のパイプラインを途中で中断することはありません。そのため、例えばデプロイスクリプトを実行し、たまたまネットワークエラーでスクリプトの応答が返らなかった場合、そのジョブは手動で停止されるまでハングします。
不安定なバッチやネットワーク依存の処理に対する防御策として、パイプラインにはタイムアウトの設定をする方が良いでしょう。

stage('Deploy') {
    options {
        timeout(time: 10, unit: 'MINUTES') // 10分間待機する
        retry(2)                           // 失敗したら最大2回リトライする
    }
    steps {
        bat 'deploy.bat'
    }
}

タイムアウトは上記のようにstageごとに設定もできますし、パイプライン全体にも定義することが可能です。
意図せずハングしたパイプラインはリソースの無駄遣いにもつながりますので、タイムアウト設定はしておいた方が無難でしょう。

まとめ

Part.1に続き、ここまでいろいろ書いてきました。
いままで手動で実行していたことをパイプライン化する際に、以下を順番に確認するとハマることが少なくなるかと思います。

• 実行ユーザーの確認：Jenkinsと手動で実行したときのユーザーの差異の確認をする
• 環境変数の確認：上記と関連して、Jenkinsの実行ユーザーのパスが通っているか、JAVA_HOME等が設定されているか確認する
• ネットワーク：プロキシ関連を確認する
• 文字コード：バッチのエンコーディングとJenkinsの設定が一致しているか確認する。異なっている場合、どちらで吸収するか確認する
• パス：ワークスペースの長さを確認
• バッチの挙動：終了コード、対話式コマンドを確認(Part.1を参照)
• 後片付け(冪等性の担保)：残プロセスや一時ファイルが連続して処理した際に影響がないか確認する
• タイムアウト：ハングした際の安全弁を作る

より良いCI環境を作るための一助となると幸いです。

宣伝

ここまで書いてきた私自身も「いろいろあるものだなぁ」という感想を持ちます。また、実際にハマったものでもまだ書いていないものもあります。

CI環境の構築は、一度動き始めてしまえば便利な反面、そこに至るまでの道のりは意外と険しいものです。本記事で紹介したような落とし穴は、実際に手を動かしてみて初めて気づくことも多く、「なぜか動かない」「なぜか結果が変わる」といった問題に頭を抱えた経験をお持ちの方も多いのではないでしょうか。

弊社テクマトリックスでは、JenkinsをはじめとしたCI環境の構築・導入支援を行っています。「自社でCI環境を整えたいが、何から始めればよいかわからない」「構築は進めているが、うまく動かずに困っている」といったお悩みをお持ちの場合は、ぜひお気軽にご相談ください。

また、Jenkinsのトレーニングも提供しています。Jenkinsの管理・運用の基礎から、パイプラインの書き方のベストプラクティス、チーム間でパイプラインの処理を再利用するための共有ライブラリの書き方まで、実践的な内容を幅広く扱っています。「社内でJenkinsを使いこなせるエンジニアを育てたい」「自分たちで運用・改善できる体制を整えたい」とお考えの方は、こちらもぜひご活用ください。