PHPプロジェクトの継続的インテグレーションを評価および設定しています。各継続的インテグレーションツールには、多くのコマンドを実行し、これらのコマンドの戻りステータスをチェックする独自の「ビルド言語」があります。
.travis.yml
構成の例を次に示します。
language: php
php:
- "5.3"
- "5.4"
- "5.5"
script: phpunit test
notifications:
email:
- [email protected]
Jenkins構成はXMLであり、長すぎてここに貼り付けることができません。
circle.yml
構成の例を次に示します。
dependencies:
override:
- bundle install:
timeout: 240
environment:
foo: bar
foo2: bar2
pwd:
test_dir
私の質問は、Makefileを使用してテスト環境をセットアップし、CIサーバーで実行する代わりに、これらすべてのCIの一般的な独自の構成言語を使用する利点は何ですかmake test
?
Jenkinsの独自の「ビルド言語」とは何ですか? Jenkinsの「ビルド言語」がXMLファイルであると言うことは、makefileの「ビルド言語」がマシンコードであると言うようなものです。よくわかりませんが、要点は同じです。
Jenkinsが構成を保存する方法を気にする必要はありません。メイクファイルの実行後に生成されるマシンコードを気にする必要があるだけです。 JenkinsのXMLを手動で変更することは決してありません。
JenkinsはWebベースのGUIです(それを完了するためのCLIおよびWeb APIを備えています)。 Jenkinsの「ビルド言語」は、Maven
からAnt
からShell
まで、その他多くのものを使用できます。さらに、ビルドフローを好きなようにカスタマイズできる多数のプラグインが追加されています。
そして結局のところ、ジェンキンスでは、ビルドステップは「シェルの実行」であり、ここでmake test
コマンドラインで行ったように。 Jenkinsの利点は、ビルドを実行することではなく(すべてのスケジューラが実行できます)、すべてを整理してまとめ、Webを通じてチームがアクセスできるようにすることです。
Jenkinsが追跡するすべての優れた機能(SCMの変更、コンソールログ、テスト結果、アーティファクト、電子メールなど)を一覧表示することができますが、Googleの検索では、ジェンキンスのメリット/機能。
遅延編集:
このトピックについてのより詳細な回答
travis-ciは、スクリプトファイル(あなたの場合はmakefile)を取得し、最小限の設定で言語のさまざまなバージョン(あなたの場合はphp)で実行するように設定するように設計されています。
.travis.tml
ファイルは、テストを実行して実行するためにすべてをセットアップするように設計されており、約5行です!
また、設定して忘れるように設計されており、ドキュメントから5行ほどをコピーし、必要に応じて少し変更すれば、CIのセットアップについて心配する必要がありません。
独自のCIサーバーを実行する場合、異なる言語バージョンでテストする(または、気まぐれにバージョンを変更する)ことははるかに困難です。結果をGitHub UIで確認します。 TravisのようなクラウドCIサービスの5分のセットアップ。