SVNの変更を検知してソースを取得し、ビルドとテストを実行する構成は、JenkinsなどのCIツールで組めます。最初は一つの対象で、取得する版と実行結果を記録するところから始めます。
CIは変更の取り込みに合わせてビルドやテストを行う仕組みです。継続的デリバリーは検証済み成果物を配布できる状態に保つこと、継続的デプロイは本番への配布まで自動化することを指します。本番へ自動配布するかは、承認と復旧の条件を決めてから判断します。
ソースから配布までの流れ
図では、SVNから取得したソースをJenkinsでビルド・テストし、成果物を保存した後、承認を経て配布する例を示します。
図：SVNからJenkins、テスト、成果物保管、承認、配布へ進む流れ。画像を開くと拡大できます。
同じリビジョンを取得しても、コンパイラ、依存ライブラリ、設定が異なれば同じ結果になるとは限りません。ソースの版と、ビルドに必要な環境を併せて記録します。
変更の検知方法を選ぶ
| 方法 | 動き | 確認すること |
|---|---|---|
| ポーリング | Jenkinsが定期的に変更を確認する | 確認間隔、問い合わせ負荷、検知の遅れ |
| フックなどの通知 | コミット完了後にCIへ通知する | 提供元の対応、認証、到達性、通知失敗時の処理 |
post-commitフックはコミット後に動きます。通知に失敗しても、確定したコミットが取り消されるわけではありません。再通知や定期確認で取りこぼしを見つける方法を用意してください。
任意のフックスクリプトを実行できるかは、ホスティングの仕様によります。ポーリングで要件を満たす場合は、無理に通知方式へ変更する必要はありません。
Jenkinsで先に確認する設定
JenkinsにはSubversionプラグインがあります。利用するJenkinsとプラグインの対応バージョン、更新状況、認証情報の保存方法を確認してください。
- ビルド用アカウントに、必要なパスの読取り権限を設定する。
- 検証環境で接続とチェックアウトを試す。
- ビルドに必要なパスと外部依存の取得方法を設定する。
- テスト結果、ログ、成果物の保存先と期間を決める。
- 失敗時の通知先と再実行の条件を決める。
認証情報をソースやコマンドのログへ直接書かず、CIの認証情報管理機能を使います。ビルド以外の権限が必要な処理は、用途を分けて許可してください。
ビルドごとに残す記録
| 対象 | 記録する内容 |
|---|---|
| ソース | リポジトリURL、対象パス、取得したリビジョン |
| 外部参照 | svn:externalsや外部ライブラリの取得先と版 |
| 実行環境 | OS、コンパイラ、ビルドツール、設定の版 |
| 検証結果 | テスト・静的解析の結果とログ |
| 成果物 | 保存先、識別情報、配布先と承認記録 |
環境変数に表示されたリビジョンが、リポジトリ全体の取得版なのか、対象パスの最終変更版なのかを確認します。複数パスや外部参照を使う場合は、それぞれの取得結果を残してください。
リリースにタグを使う場合も、タグの変更制限と確定したリビジョンの記録が必要です。タグ名だけを保存して完了にしないでください。
クラウドCIでSVNを取得する構成
GitHub Actionsなどでは、Git側にワークフローを置き、ジョブ内でSVNクライアントを使って外部SVNを取得する構成も考えられます。SVNの内容をGitへミラーすることだけが方法ではありません。
これは個別に設計・検証する構成です。起動方法、SVNへの接続経路、認証情報、ランナーに保存されるデータ、利用料金を確認します。GitHub Actionsでは外部イベントによる起動方法も公式に案内されています。既存の認証や接続制限を満たす方式を選んでください。
配布と切り戻しを別に検証する
配布には、検証した成果物を使い、どの環境に何を配置したかを記録します。配布のたびに最新ソースから作り直すと、試験済みの成果物と異なるものになる場合があります。
切り戻しは前のタグを選ぶだけでは完了しません。データベース変更、設定、外部サービスとの互換性を確認し、前の成果物へ戻せる条件を試します。
tracpathとの接続を検討する場合は、CIの接続方式、取得範囲、認証方法、必要な通知をお知らせください。CIそのものと、リポジトリ側で対応できる機能を分けて確認します。
参考資料
確認日：2026年10月6日。
関連記事
この記事の著者
株式会社オープングルーヴ／tracpath編集部。バージョン管理サービスtracpathを提供。
