深刻なプロジェクトでは、ある時点で、CIプロセスを整理するという問題が発生します。したがって、現在市場に出回っている広範なものからその自動化の手段を選択するという問題が生じます。 豊富な選択肢があるため、適切なオプションを見つけるのは簡単ではなく、ターンキーソリューションが単純に複雑すぎる場合があり、それをサポートするためのリソースを割り当てるという欲求も機会もありません。 さらに、すべての卵を1つのバスケットに入れて、ディストリビューションを組み立て、テスト、保存するための単一のサーバーを持ちたくない...
当社では、分散化の世界的な傾向をサポートし、CIサーバーを複数のマシンに分割し、マシンと人の両方がアクセスできるユニバーサルプロトコルで接続するというアイデアが生まれました。 自転車の発明のように聞こえますか？ まったくありません。
このような通信手段の役割は、会社の内部通信の標準であるXMPPプロトコル（別名Jabber）に完全に適合していたため、すべての開発者、テスター、およびその他のCI参加者は、職場でJabberをサポートするIMを使用していました。 したがって、Jabberプラグインをサポートする既製のCIソリューション（およびほぼすべての継続的インテグレーションサーバーには現在1つがあります）は、一般的なスキームに簡単に適合します。
このアイデアを実装するために、次のことを行いました。
•Jabber名簿にbuildserver、testserver、deployserver、hudsonのサーバーアカウントを登録し、通信可能な各グループにこれらの「ユーザー」を作成し、これらのグループに入力して、1つまたは別の機能にアクセスできる実際のユーザーのリストを定義しました。
彼らは、コミュニケーションの言語を（初めて-最小限のコマンドセットで）作成しました。これは、新しいタスクを実装するために拡張でき、エンドユーザーにとって簡単に習得できます。 コマンド：ビルド、テスト、デプロイ、キル、禁止、承認、ヘルプ。 CIの実装プロセスにおけるこれらすべてのチームに対して、機能を大幅に拡張することを可能にするパラメーターが追加されました。
•jabber-net.dllライブラリを使用するCI要素のテンプレートを開発しました。これには、着信コマンドのハンドラーが含まれ、これらのデータの実行結果に基づいて発信ハンドラーが送信されます。
C＃のサンプルテンプレート：
using System; namespace Jabber { public class Jabberclnt : IDisposable { private jabber.client.JabberClient clnt = null; ~Jabberclnt() { Dispose(false); } public void Dispose() { Dispose(true); GC.SuppressFinalize(this); } public void Dispose(bool disposing) { if (clnt != null) { clnt.Close(); clnt.Dispose(); clnt = null; } } public void Init(string user, string pwd) { clnt = new jabber.client.JabberClient (); clnt.PlaintextAuth = true; clnt.Server = "pt.int"; clnt.NetworkHost = "jabber.ptsecurity.ru"; clnt.Port = 5222; clnt.User = user; clnt.Password = pwd; clnt.AutoLogin = false; clnt.OnMessage += clnt_OnMessage; clnt.Connect (); } void clnt_OnMessage (object sender, jabber.protocol.client.Message msg) { if (null == msg.Body) return; Console.WriteLine(string.Format("[{0}] {1}:{2}", DateTime.Now.ToString(), msg.From.User, msg.Body));
•imおよびjabberプラグインを使用してHudsonサーバーを上げて、他の参加者と通信できるようにしました。
このアイデアを実現すると、次のスキームが得られました。
このスキームでは、各モジュールは独立しており、他のサーバーのリソースを使用せずに、他の参加者を順番に待たせることなく、個別の機能を実行します。 開発者は、テストの後続の実行でBuildServerとして、またはアセンブリ後に追加のテストセットを実行する必要がある場合は直接TestServerとしてコマンドを提供できます。
すでに述べたように、開発者はJabber（私たちはMirandaを持っています）からIMの形で、あらゆるサーバーの既製の管理および通知ツールを受け取ります-もちろん、Jabber名簿に登録されているアクセス権を考慮に入れてください。
このサイクルの参加者と全サイクルの相互作用スキームは次のとおりです。
開発者がプロセスを開始します。
BuildServerは成功を報告し、TestServerに制御を渡します。
テストの実行後、成功メッセージも表示され、制御が展開サーバーに転送されます。
サイクルの終わりに、プロセスを開始した人と関係者のリストが通知されます。
ただし、フルサイクルを開始することは常に必要というわけではありません。チェーンから1つのアクションを実行する必要がある場合が非常に多く、その場合、分割サーバースキームは特に効率的に機能します。
したがって、このスキームは、次の一連の問題の解決に役立ちます。
•さまざまなプロジェクトや部門で既製のCIを選択することに制限はありません。それらは会社の一般的な構造に簡単に統合できます。
•リソース共有：輻輳ビルドサーバーは、テストと展開のタスクに影響しません。
•jabber CIライブラリを使用する際の既製の管理ツール（通知、自動化）は、任意のアプリケーション、ライブラリ、またはスクリプトから利用可能になります。
•単一のコマンド形式により、CIで現在何が起こっているかの全体像を確認できます。また、ユーザーは任意の段階で適合でき、任意のサーバーをシミュレートしてプロセスの純度を維持できます。
このアプローチの長所と短所について話し合うことをお勧めします。 詳細が興味深い場合-質問をしてください：経験を共有してください:)PSこのトピックに関するレポートは、Application Developer Daysで発表されました（
プレゼンテーションおよび
ビデオ ）。