CruiseControlのようなビルドサーバーを使用するよりも、継続的インテグレーションを実装するよりシンプルで安価な方法があります。 実際、非常に簡単なので、ビルドサーバーへのリクエストをまだ承認していないIT部門のために、 今すぐ実行して、気分が悪くなるのを止めることができます。
（少し非倫理的な秘密が必要ですか？私があなたに伝えるつもりは、CruiseControlを使用するよりも優れています！）
ステップ1：古い開発コンピューターを見つける
開発に使用した無料のシステムを見つけます。 古すぎない...彼はアセンブリを完了することができるはずです。 お粗末なモニターと自由な角度を取得します。 モニターを接続します。 古い壊れた椅子を彼の前に置きます。 快適さは必要ありません...あなたは長い間ここにいません。
ステップ2：ラバーチキンを入手する
いやいや。
2001年頃の私のオフィス
必要に応じて、ぬいぐるみなど他のものを使用できます。 それを楽しくし、「偶然」あまりにも激しく投げた場合（特に女の子の場合）、誰の目からも突き出ないようにしてください。 適切なものがない場合は、これを止めないでください。 即興。 楽しんでください。
ファサードを「装飾」するのに役立つと思いましたが、それは私を無能だと感じるだけでしたので、あなたは忘れることができます。
ステップ3：デスクコールを購入する
あなたが彼に触れると、彼はジンを作ります。 いいえ、電話はありませんので、やめないでください。 後で入手してください。 今、衝動があります。 お粗末なコンピューターがあります。 接続-あります。 面白いおもちゃ-利用可能。 継続的な統合から一歩離れています。 （資金が非常に限られている場合は、この手順を完全にスキップできます。）
ステップ4：ビルドを自動化する
ああ！ これが最も難しい部分です。 良いニュース：CruiseControlの最大の利点の1つは、ビルドの自動化を強制することです。 さらに良いニュース：継続的インテグレーション-あなたがやろうとしていることは、単に自動化されたCruiseControlアセンブリ以上のものです。 ただし、ビルドを自動化する必要があります。
さて、これは難しい、私は知っている。 その前にIDEをアセンブリに使用した場合、自動アセンブリの作成はおそらく多くの作業のように思えます。 現時点では、おそらくIDEを起動してビルドを要求するバッチファイルを作成できます。 これは長期的には十分ではないので、戻って正しく行う必要があります。
JUnit / NUnitテストなどの自動化された単体テストがある場合は、それらもアセンブリに含めます。
先に進む前に、脆弱なビルドコンピューター（手順1を参照）に移動し、バージョン管理システムからの最新のコードでビルドが適切に機能していることを確認します。 バージョン管理をまったく使用しませんか？ うーん...大丈夫...キーボードを下に置き、コンピューターから離れます。 今、私の後に繰り返します。「世界、私を赦してください。私は罪を犯しました。 バージョン管理システムなしでは二度とプログラムしません。 次に 、 TortoiseSVNをダウンロードしてインストールし、使用を開始します。 これから悪質なものはすべて放棄します。」ありがとう。
完全に自動化されたビルドの実行に10分以上かかる場合は、停止してください。 継続的な統合の準備がまだできていません。 ビルドの高速化に取り組む必要があります。 次のいずれかを実行するか、CruiseControlを使用できますが、実際の継続的統合は今日の目標ではありません。
ステップ5：バナーの下で全員を構築する
[原作では、著者は慣用表現「Drink the Kool-Aid」（Eng。）-「Sip Kool-Aid」を使用します。これはアメリカの専門用語ではリーダーに夢中になることを意味します。 -注 翻訳者]
これは、このリストの100％最も重要なステップであることは絶対に否定できません。 チームメンバー全員を1つの部屋に集めます。
誰かが尋ねると、いいえ、これは会議ではありません。 あなたは来て、何かをして、5分後に戻ってきます。 役に立つ まもなく。 これらの理由により、これは会議ではありません。
さて、身体に危害を加えることなく、全員に次のことに同意してもらいます。
「今日から、バージョン管理システムのコードは常にすべてのテストを正常に収集し、合格します。」
これが複雑すぎると不平を言う人がいたら、継続的インテグレーションでそれが簡単になることを知らせてください。 うーん、簡単です。 それでも複雑すぎると思う場合は、自分の仕事はソフトウェアを作成することであることを丁寧に思い出させます 。
ああ、あまりにも厳しい。 言わないでください。 くそ、私はちょうど10人の潜在的な顧客を失った。 おっと、別のものが出ています。 11。
実際、「これは良い考えだと誰もが同意する」ことは本当に重要です。ソフトウェアビルドシステムにいつでも真に依存する能力は、継続的インテグレーションの本当に革命的な部分です。バージョン管理システムから取得したコードが正常に機能することを知っていれば、それは命です。
少し話をさせてください。 NUnitAspと呼ばれるオープンソースプログラムの一部をサポートしています。 昨年、私は彼女についてのコースを教えました。 レッスン中に、NUnitAspにはない機能について誰かから私に尋ねられました。 コードを見て、簡単に変更できることがわかりました。 そこで、変更を行いました（数分かかりました）。 その後、ビルドを完了し、96秒後に新しいリリースファイルが表示され、配布しました。 実話。 報酬プログラムもありました。 私たちはそれを「間違いを見つけてください-マグカップを獲得してください」と呼びました。 （私たちは良かったです：たとえ間違いを見つけなかったとしても、私たちは皆に円を与えました）。
さて、あなたはおそらくそこにいなかったでしょう。 説明したようなバージョンをビルドおよびリリースするには、優れた自動テストが必要です。 別の話をしましょう。 あまり成功していない別のプロジェクトで、私たちはすべてコードのさまざまな部分に取り組みました。 毎日のチェックなどに最善を尽くしましたが、プロジェクト全体を収集せず、テストを実行しませんでした。 （テスト？自動テストはありませんでした。）6か月後、私たちは1つの全体に統合しようとしましたが、互いに結合するものはありませんでした。 プログラムが機能するまでに1週間かかりました。 私は、そのプロジェクトがどれだけ多くの間違いを抱えていたかについても説明しません。 継続的な統合は、大きなテストがなくても、この悪夢に二度と直面することはありません。
このことは良い考えだと人々に納得させたくありません。 私はあなたが歯を磨くと言っているのではありませんよね？ ただし、まだこれを行っています。 これはあなたに良いです 。 これをしたくないですか？ これをしないでください！ 私の問題ではありません。
12…13…14…15…16…クソ。
いずれにせよ、これを行うことに全員に同意してもらうと、プロセスは機能しません。 ドルに何を期待しますか？
ステップ6：始めましょう！
印刷可能なチェックリストについては、 こちらをご覧ください。
始める準備はできていますか！ 発売前のチェックリストを見てみましょう。
- コンピューターの組み立て？ あります。
- 面白いおもちゃ？ あります。
- 迷惑な電話？ オプション。
- 自動ビルドですか？ あります。
- グループ同意？ あります。
さあ、やってみましょう！
開始するには、変更を少なくとも1日2回記録します。 これは「継続性」の一部です。 手がいっぱいになったら、1〜2時間ごとに登録します。
バージョン管理システムから最新のコードを取得する前に、誰かがゴムのニワトリを服用しているかどうかを確認してください。 誰かが作業している場合は、変更登録が完了するまで待ちます。
変更を登録するときは、次の手順を実行します。
- ビルド/テストスクリプトをローカルで実行し、100％実行されることを確認します。
- 休息場所からゴム製の鶏を拾います。 彼がそこにいなければ、彼を連れて行った人を見つけ、彼が変更の登録を完了するまで彼を悩ませます。
- リポジトリから最新のコードを取得し、念のため再度ビルドスクリプトを実行します。 アセンブリが失敗した場合、受け取ったコードにいくつかの統合の問題があることがわかります。 泣き叫んで、鶏を戻し、最後の変更を行った人を助けてください。 準備ができたらやり直してください。
- コードを登録します。
- ビルドコンピューターに移動し、リポジトリから最新のコードを取得し、ビルドスクリプトを再度実行します。 合格しない場合は、登録を返却（キャンセル）します。 いくつかの新しいプログラムをインストールしたか、環境変数を変更したか、レジストリパラメータを設定したか、リポジトリにファイルを追加するのを忘れたか、または他の何か。 いずれにせよ、コンピューターの問題を解決してから再試行する必要があります。 しばらく鶏肉をつかむことができますが、誰かがそれを必要とするならば、それを返します（そして最初からやり直します）。
- ベルを鳴らします。 （他のすべての人にとって、これは何らかの形で喜びを称賛または表現するためのシグナルです。「Yeeee」）。 鶏肉を所定の位置に置きます。 できました。
ちなみに、ステップ5が失敗すると、ビルドマシンでこの問題を直接解決したいと思うようになります。 しかし、これを行うと、最新のコードを受け取った次の貧しい貧しい人はそれを収集できなくなります。
最後になりましたが、ビルド時間は10分以内にしてください。 5分未満、さらに良い。 時間がかかりすぎると、このプロセスは正午から午後にかけての楽しい休憩時間ではなくなり、ロバの本当の痛みになり始めます。 とにかく、ビルド時間が短いことは、テストアプローチの欠陥を意味することが多いため、ビルド時間を短くするのに適しています。
CruiseControlよりも優れている理由
- バージョン管理システムのコードは常にコンパイルおよびテストされます。 ポイント。
- 何かがうまくいかない場合は、問題が何であるかを知っています。 これは、コード（ステップ1の失敗）、または他の人のコードとの統合（ステップ3の失敗）、または環境の変更（ステップ5の失敗）のいずれかです。 すぐにそれについて学習し、修正が容易になります。
- CruiseControlが完了するのを待たずにランチに出かけたため、誰かの誤ったビルドを修正する必要はありません。
- 短いビルド時間（長い統合のように変更する動機はありません）を節約します。これは、より良いテストを意味し、プロジェクトのより良い設計につながります。
上級クラス
作業の基本がわかったら、継続的インテグレーションの実際の改善に進むことができます。 1つのオプションは、ビルドをスタンドアロンにすることです。 つまり、収集する必要があるのはバージョン管理システムだけであり、コードを受け取ったらすぐにネットワークから切断してアセンブリを完了することができます。 ビルドの信頼性が向上し、古いバージョンを簡単にビルドできるため、これは良いことです。 また、データベース構成と移行エラーを取り除くのにも役立ちます。
本当に驚くべきテストも良い選択です。 本当にすばらしいテストがある場合は、ためらうことなく製品を公開できます。
また、ビルドスクリプトでインストールパッケージを作成することも好きです。 多くの場合、テストと統合の方法でインストーラーを見逃してしまいます。その後、インストールパッケージを作成するときに苦労します。 これは、徐々に作成する方がはるかに簡単なことの1つです。 ただし、インストーラーの自動テストは依然として苦痛です。
そして...私はそれを認めたくありません...しかし、CruiseControlをインストールすることも良い考えかもしれません。 ただし、上級クラスを修了した場合のみです。 この時までに、あなたは本当に良い基盤（チームの合意、迅速なテスト、ビルドの失敗なし）を得ており、悪いプラクティスに陥る可能性は低くなります。
頑張って そして、私のドルを送ってください。