WikipediaおよびここHabrでCIの概要と使用理由を読むことができます： 記事1 、 記事2 、 CIタグ 。
そして、プロジェクトにCIを選択する際に注意すべきこと、既成のサードパーティシステムを使用し、独自の「バイク」の作成に関与しない理由を説明します。
それは、あるIT企業で、近隣の部門の同僚との会話があったという事実から始まりました。
K1：継続的な統合はありますか？
K2：はい、テストはトランクの各コミットに対して実行されます。
Q1：彼らは何に取り組んでいますか？
K2：自分のスクリプト。 現在、Buildbotに移行しています。
Q1：何か分からないかもしれませんが、何がそんなに複雑なのですか？ 動揺し、テストを実行し、結果を送信します。なぜBuildbotなのか、自分で書くのは簡単ですか？
「なぜ継続的な統合以外の方法なのか、そこに複雑なものがあるのに、今は自分でスクリプトを取得している」という理由に出会ったのです。
そこで、「小さなスクリプト」を作成します。 私はシェバン、crontabでの仕事、手紙を送るための設定を含めて10行以内に収まりました。
スクリプトmicro_ci.shは、ファイルを実行可能にすることを忘れないでください。
#!/bin/sh cd /tmp/micro_ci/wc && mkdir /tmp/micro_ci/lock || exit 2 rev=`svn info |grep 'Last Changed Rev' |sed 's/.*: *//'` svn up if test `svn info |grep 'Last Changed Rev' |sed 's/.*: *//'` = $rev ; then rmdir /tmp/micro_ci/lock ; exit 0 ; fi make test || status=$? rmdir /tmp/micro_ci/lock exit $status
ディレクトリ/ tmp / micro_ciを作成し、/ tmp / micro_ci / wcにプロジェクトをチェックアウトします。
ファイル/etc/cron.d/micro-ci：
MAILTO=project-tests@company.ru */10 * * * * tests /path/to/micro_ci.sh
できた！ おもちゃのサイズにもかかわらず、このMicroCIは機能し、有益です。
そしてもちろん、彼女は「アダルト」システムと比較して多くのことを恋しく思っています。 もっと詳しく見てみましょう。
その他のアセンブリ
MicroCIの動作（スクリプトの6行目）：正確に1種類の「アセンブリ」-make
make test
（またはスクリプトにハードコードされた何か）。
望ましい動作：独立して、または連続して実行されるさまざまな種類のビルドを構成する機能（煙テスト、単体テスト、計算のためのアーティファクトのアセンブリなど）
リポジトリを操作する
MicroCIの動作（スクリプトの3行目から5行目）：作業コピー
/tmp/micro_ci/wc
れている1つのsvnリポジトリだけを操作します。
望ましい動作：さまざまなVCS（svn、git、mercurialなど）を含む複数のリポジトリのビルドを簡単に構成する機能
ブランチ（ブランチ）を操作する
MicroCIの動作（スクリプトの4行目）：正確に1つのブランチ（/ tmp / micro_ci / wcの作業コピーに保存されているブランチ）を操作します。
望ましい動作：リポジトリ内の一部またはすべてのブランチでテストおよびアセンブリを実行する機能。
組立スケジュール
MicroCIの動作（crontabの2行目）：10分ごとに実行され、リポジトリから更新を取得しようとします。
望ましい動作-ビルドごとに異なるさまざまなスケジュールオプション：
- 改訂ごとに;
- タイマーで;
- 毎晩;
- 特定の「興味深い」ファイルを変更する場合。
- など
分散作業
MicroCIの動作（スクリプトの2行目）：同じマシン上で同じ作業コピー内で正確に実行され、並列操作は提供されません。
望ましい動作：さまざまなワーカービルダーでの並列アセンブリの可能性、さまざまなサーバーでのワーカーの起動（負荷分散およびさまざまなアーキテクチャ/ OSでの操作の確認）。
通知配信方法
MicroCIの動作（crontabの1行目）：すべての起動の結果は、1つのアドレスに電子メールで送信されます。
望ましい動作：さまざまな電子メールアドレスへの通知の配信、およびjabber、irc、sms、rss経由-すべてが便利です。
通知フォーマット
MicroCIの動作（crontabの1行目）：アセンブリの出力全体が文字になり、それ以上はなりません。
望ましい動作：テスト実行システム自体に関するコメントとWebインターフェイスへのリンクを含む適応通知（ビルドの成功と失敗で異なる）。
通知条件
MicroCIの動作（crontabの1行目、スクリプトの6行目）：各テストの実行後に文字が送信されます。
望ましい動作-通知を送信するための条件を柔軟に構成する機能：
- 各開始時に;
- 失敗すると
- 特定のしきい値を超える失敗したテストの割合。
- アセンブリの状態を変更する場合：一連の成功後の最初の失敗時、および一連の失敗後の最初の成功時。
- 成功については、一般的なメーリングリストにのみ通知を送信し、失敗については、さらに問題の作成者にコミットを送信します。
実行間のクリアな作業コピー
MicroCIが欠落しています。
アセンブリが作業コピーに新しいファイルを生成する場合、それらは次の開始前に自動的に削除されます。
特定のリビジョンでテストを強制的に再起動します
MicroCIが欠落しています。
望ましい動作：以前のリビジョンの1つでテストを再開する機能-一時的な環境機能によりアセンブリが落ちたように見える場合。
他のイントラネットサービスとの統合
MicroCIが欠落しています。
望ましい行動-チームで使用される他のツールと簡単に統合する機能：監視、メッセージングシステム、wiki、内部ブログなど
予備組立
MicroCIが欠落しています。
望ましい動作：コミットする前にCIシステムにパッチをロードすることができます。システム自体がそれをプロジェクトコードに適用し、必要なすべてのアセンブリとチェックを実行します。 これは、テストが異なるアーキテクチャまたはOSバージョンで実行され、開発者がテストを起動することが難しい場合に特に役立ちます。
TeamCityの場合、このモードはRemote Runと呼ばれ、Buildbotにはトライアルビルドがあり、JenkinsにはPatch Parameter Pluginがあります。
ネイティブWebインターフェース
MicroCIが欠落しています。
望ましい動作：CIシステムには、アセンブリ履歴、統計などを表示できる独自のWebインターフェイスがあります。
ライセンス、オープンソース
CIシステムが無料ライセンスで配布されている場合に便利です。必要に応じて、コードに独自の変更を加えることができます。
CIが記述されている言語
MicroCIはシェルで記述されており、非常にコンパクトですが、プログラムのさらなる開発には非常に不便です。
CIコードに変更を加え、そのためのプラグインとモジュールを作成する可能性が高い場合は、他のすべてが同じであれば、すでに十分な専門知識がある便利で強力なプログラミング言語を選択する価値があります。
おわりに
もちろん、MicroCIには利点もあります。非常にシンプルで、「インストール」は簡単で、サードパーティのソフトウェアは必要ありません。 しかし、実際のプロジェクトでそれまたは同様の独立した開発を使用しようとする場合、遅かれ早かれ、上記の機能のすべてまたはほとんどすべてを実装する必要があります。 これの準備はできていますか？ よくわからない場合は、CI側を選び、メインプロジェクトに加えて新しいサポートプロジェクトを開発する作業を自分で加えないでください。
最後に、人気のあるCIシステムの一部： Atlassian Bamboo 、 Buildbot 、
ウィキペディアには大きなリストがあります。
レビューにCIの他の重要かつ有用な機能が含まれていない場合は、コメントを記入してください。
良い選択をしてください！