TravisCIを使用してビルドパイプラインを作成する
1. 序章
最近のソフトウェア開発では、パイプラインという用語がよく使われます。 しかし、それは何ですか?
一般的に、ビルドパイプラインは、コードを開発から本番環境に移動する一連の自動化されたステップです。
ビルドパイプラインは、ソフトウェアの継続的インテグレーションワークフローを実装するのに最適です。 バグをより早く発見し、その影響を減らすことを目的として、より高い頻度で
このチュートリアルでは、 TravisCIを使用して単純なビルドパイプラインを構築する方法を見ていきます。
2. ビルドパイプラインの手順
ビルドパイプラインは多くの異なるステップで構成できますが、少なくとも次のものを含める必要があります。
- コードのコンパイル:この場合、Javaソースコードをクラスファイルにコンパイルすることを意味します
- テストの実行:単体テストや場合によっては統合テストの実行など
- アーティファクトのデプロイ:コンパイルされたコードをアーティファクト、たとえば jar ファイルにパッケージ化し、それらをデプロイします
アプリケーションが異なるテクノロジーを使用している場合は、追加の手順をビルドパイプラインに含めることができます。 たとえば、JavaScriptファイルを縮小したり、更新されたAPIドキュメントを公開したりする追加の手順がある場合があります。
3. Travis CIとは何ですか?
サンプルのビルドパイプラインには、クラウドベースの継続的インテグレーションツールであるTravisCIを使用します。
これには、ビルドパイプラインを開始するための優れた選択肢となる多くの機能があります。
- 公開されているGitHubリポジトリとすばやく統合します
- すべての主要なプログラミング言語をサポートします
- 複数の異なるクラウドプラットフォームにデプロイします
- さまざまなメッセージングおよびアラートツールを提供します
大まかに言えば、GitHubリポジトリで新しいコミットを監視することで機能します。
新しいコミットが行われると、構成ファイルで定義されているビルドパイプラインのステップが実行されます(これについては以下で詳しく説明します)。 いずれかのステップが失敗すると、パイプラインが終了し、通知されます。
箱から出して、TravisCIはほとんど設定を必要としません。 必要な構成はプログラミング言語を指定することだけです。
必要に応じて、パイプラインを調整するための構成をいつでも提供できます。 たとえば、ビルドをトリガーするブランチを制限したり、パイプラインにステップを追加したりできます。
3.1. 無料版と有料版
Travis CIには現在、無料バージョンと有料バージョンの2つのサービスがあることを知っておくことが重要です。
.org ドメイン名で示される無料バージョンは、すべてのパブリックGitHubリポジトリに対して完全な機能を提供します。 パイプラインの実行時にリソース制限が課せられますが、ビルドまたはリポジトリの数に制限はありません。
プライベートGitHubリポジトリには、.comドメイン名を使用する有料バージョンが必要です。 また、無料プランと比較して、より多くの同時ビルドと無制限のビルド分を提供します。 有料版をテストするために、最初の100ビルドの無料トライアルがあります。
4. TravisCIを使用したビルドパイプラインの作成
このチュートリアルでは、上記の無料バージョンを使用します。 任意のパブリックリポジトリを使用して、無料のパイプラインを作成できます。
GitHubアカウントを使用してTravisCIにログインし、認証するだけです。
GitHubアカウントにアクセス許可を付与したら、ビルドパイプラインの構成を開始する準備が整います。
4.1. リポジトリの構成
当初、すべてのパブリックリポジトリは非アクティブと見なされます。 これを解決するには、アカウント設定ページからリポジトリを有効にする必要があります。
これにより、すべてのパブリックリポジトリとトグルボタンが一覧表示されます。 トグルボタンをクリックすると、 master:のデフォルトのブランチを使用して、新しいコミットについてそのリポジトリの監視を開始するようにTravisCIが構成されます。
各リポジトリには設定ボタンもあることに注意してください。 ここで、さまざまなパイプラインの動作を構成できます。
- パイプラインをトリガーするイベント(プッシュ、プルリクエストなど)を定義します
- パイプラインに渡される環境変数を設定します
- 新しいイベントがトリガーされたときにビルドを自動キャンセル
このチュートリアルでは、デフォルト設定が正常に機能します。 後で、デフォルトの動作の一部をオーバーライドする方法を説明します。
4.2. Travis構成の作成
次のステップは、リポジトリのルートディレクトリに.travis.ymlという名前の新しいファイルを作成することです。 このファイルには、パイプラインの構成に必要なすべての情報が含まれています。 このファイルがないと、パイプラインは実行されません。
このチュートリアルでは、プログラミング言語を指定する最小限の構成を含める必要があります。
language: java
それでおしまい! これ以上の情報を提供せずに、TravisCIは次のような単純なパイプラインを実行します。
- ソースコードをコンパイルします
- テストを実行します
.travis.yml ファイルをコミットすると、Travisは最初のビルドを開始します。 master ブランチにさらにコミットすると、追加のビルドがトリガーされます。 ダッシュボードでは、コミットまたはプルリクエストを必要とせずに、いつでも手動でパイプラインをトリガーできます。
5. 追加の構成
前のセクションでは、ビルドパイプラインを実行するために必要なのは1行の構成だけであることがわかりました。 ただし、ほとんどのプロジェクトでは、意味のあるパイプラインを実装するために追加の構成が必要になります。
このセクションでは、パイプラインに追加する可能性のある、より便利な構成のいくつかについて概説します。
5.1. デフォルトのビルドコマンドの変更
Mavenプロジェクトのビルドに使用されるデフォルトのコマンドは次のとおりです。
mvn test -B
.travis.ymlでscriptディレクティブを設定することにより、これを任意のコマンドに変更できます。
script: mvn package -DskipTests
1つのコマンドで複数のコマンドをチェーンすることが可能です脚本を使用した行 && オペレーター。
一部のビルドコマンドは複雑で、複数の行にまたがったり、複雑なロジックを持っている場合があります。 たとえば、環境変数に基づいてさまざまなアクションを実行する場合があります。
このような場合、ビルドコマンドをスタンドアロンスクリプトに配置し、構成ファイル内からそのスクリプトを呼び出すことをお勧めします。
script: ./build.sh
5.2. コードのデプロイ
Javaプロジェクトのデフォルトのビルド設定は、コードをコンパイルしてテストを実行するだけです。 結果のアーティファクト(.jarファイルなど)は、どこかにデプロイしない限り、パイプラインの最後で破棄されます。
Travis CIは、さまざまな有名なサードパーティサービスをサポートしています。 アーティファクトは、Amazon S3、Google Cloud Storage、Bintrayなどの多くの一般的なクラウドストレージシステムにコピーできます。
また、 AWS、Google App Engine、Herokuなどの最も一般的なクラウドコンピューティングプラットフォームにコードを直接デプロイすることもできます。
以下は、Herokuにデプロイする方法を示す構成例です。 暗号化されたプロパティを生成するには、TravisCLIツールを使用する必要があります。
deploy:
provider: heroku
api_key:
secure: "ENCRYPTED_API_KEY"
さらに、独自のデプロイメントスクリプトを作成できる汎用デプロイメントオプションを提供します。 これは、ネイティブでサポートされていないサードパーティシステムにアーティファクトをデプロイする必要がある場合に役立ちます。
たとえば、アーティファクトをプライベートFTPサーバーに安全にコピーするシェルスクリプトを作成できます。
deploy:
provider: script
script: bash ./custom-deploy.sh
5.3. パイプラインをトリガーするブランチの管理
デフォルトでは、パイプラインはmasterのすべてのコミットに対して実行されます。 ただし、ほとんどの大規模プロジェクトでは、開発サイクルを管理するために何らかの形式のgitブランチを使用しています。
Travis CIは、gitブランチのホワイトリストとブラックリストの両方をサポートし、パイプラインをトリガーするコミットを決定します。
例として、次の構成について考えてみます。
branches:
only:
- release
- stable
except:
- master
- nightly
これは、masterおよびnightlyブランチでのコミットを無視します。 releaseおよびstableブランチへのコミットは、パイプラインをトリガーします。 onlyディレクティブは常にexceptディレクティブよりも優先されることに注意してください。
正規表現を使用して、パイプラインをトリガーするブランチを制御することもできます。
branches:
only:
- /^development.*$/
これにより、developmentで始まるブランチでのコミットに対してのみパイプラインが開始されます。
5.4. 特定のコミットをスキップする
git commitメッセージを使用して、個々のコミットをスキップできます。 Travis CIは、次のパターンについてメッセージを調べます。
- スキップ
スキップ
どこ
- ci
- トラヴィス
- travis ci
- travis-ci
- travisci
コミットメッセージがこれらのパターンのいずれかに一致する場合、パイプラインは実行されません。
5.5. 異なるビルド環境の使用
Javaプロジェクトのデフォルトのビルド環境はUbuntuLinuxです。 パイプラインは、 .travis.yml に次の構成を追加することにより、MacOSXまたはWindowsServerでも実行できます。
os: osx # can also be 'windows'
Linuxでも、次の3つのディストリビューションから選択できます。
os: linux
dist: xenial # other choices are 'trusty' or 'precise'
ビルドプラットフォームのドキュメントは、利用可能なすべての環境とその違いをカバーしています。
プラットフォームを変更する場合は、互換性を確保するために、カスタムbuildまたはdeployスクリプトも変更する必要がある場合があることを覚えておいてください。 構成で複数のオペレーティングシステムを処理する方法はいくつかあります。
5.6. 異なるJDKバージョンの使用
.travis.yml ファイルで次の構成を設定することにより、特定のバージョンのJDKに対してテストすることもできます。
jdk: oraclejdk8
異なるビルド環境でも、異なるLinuxディストリビューションでも、異なるJDKバージョンを使用できることに注意してください。 JDKバージョンの完全なリストを確認するには、各環境のドキュメントを参照してください。
6. マトリックスを構築する
デフォルトでは、パイプラインが実行されるたびに、単一のジョブとして実行されます。 これは、パイプラインのすべてのフェーズが、同じ設定の単一の仮想マシンで順番に実行されることを意味します。
しかし、Travis CIの優れた機能の1つは、ビルドマトリックスを作成する機能です。 これにより、以前に見たいくつかの設定に異なる値を使用して、コミットごとに複数のジョブを実行できます。
たとえば、ビルドマトリックスを使用して、LinuxとMac OSXの両方、またはJDK8と9の両方でパイプラインを実行できます。
ビルドマトリックスを作成する方法は2つあります。 まず、前に見た言語と環境の構成の1つ以上に値の配列を提供できます。 例えば:
language: java
jdk:
- openjdk8
- openjdk9
os:
- linux
- osx
このアプローチを使用すると、Travis CIは構成のすべての組み合わせを自動的に拡張して、複数のジョブを形成します。 上記の例では、結果は合計4つのジョブになります。
ビルドマトリックスを作成する2番目の方法は、matrix.includeディレクティブを使用することです。 これにより、実行する組み合わせを明示的に宣言できます。
language: java
matrix:
include:
- jdk: openjdk8
os: linux
- jdk: openjdk9
os: osx
上記の例では、2つのジョブが発生します。
繰り返しになりますが、複数のオペレーティングシステムでビルドする場合は、buildおよびdeploymentスクリプトがすべての場合に機能するように注意する必要があります。 たとえば、シェルスクリプトはWindowsでは機能しません。 さまざまなオペレーティングシステムを処理するには、適切な条件ステートメントを使用する必要があります。
より多くのオプションがあり、作成するジョブと障害の処理方法をよりきめ細かく制御できます。
7. 結論
この記事では、TravisCIを使用して簡単なビルドパイプラインを作成しました。 ほとんどすぐに使用できる構成を使用して、コードをビルドしてテストを実行するパイプラインを作成しました。
また、TravisCIがどのように構成可能であるかの小さなサンプルも見ました。 さまざまなプログラミング言語とサードパーティのクラウドプラットフォームで動作します。 1つの欠点は、現在GitHubリポジトリでのみ機能することです。