単独プロジェクトで継続的統合ツールが提供する利点は何ですか？

ソロプロジェクトを行う場合-CIツールを使用してリポジトリからビルドしますか？私はチーム環境でハドソンとクルーズコントロールを使用しました。誰かがチェックインしたらすぐにビルドすることが不可欠です。

バージョン管理の価値はまだ明らかだと思いますが、ローカルマシンでビルドしたばかりで、誰もコミットしていないように、コミットするたびにビルドする必要がありますか？

さて、私はプロジェクトで継続的統合ツールを使用することを計画しており、私はユニークな開発者です。必要性が来るのは

1. 目標の1つはクロスプラットフォームにすることです。統合ツールを使用すると、統合リポジトリ（または中央のリポジトリなど）で変更をプッシュした後、複数のプラットフォームで暗黙的に（基本）アプリをチェックできます。信頼できるものとして使用されます）。
2. このプロジェクトは長期にわたって構築されているため、後でチームと協力する必要があります。2012年まで誰も採用するつもりはないので、1。が優先されるまで、継続的インテグレーションはしばらく待つことができます。

クロスプラットフォームおよびチームワークの準備以外には、必要性は見当たりません。主なものは、何らかの種類のソース管理ソフトウェアと、バックアップを保持するためのいくつかのリポジトリを持つことです。これは、必要なときにビルドツールをセットアップするのに役立ちます。

ビルドのタイミングについては、Mercurialを使用し、チームワークリポジトリではない統合リポジトリを設定しています。そのため、統合システムを構築しようとする時が来るまで、チームワークリポジトリの変更をプッシュします。次に、チームワークリポジトリから統合リポジトリにプッシュすると、ビルドがトリガーされます。次に、毎日1回、統合リポジトリのチームワークリポジトリをプルするスクリプトも追加します。

ここでは、ほぼすべての日を自分のプロジェクトに取り組んでいると想定していますが、必ずしもそうとは限りません。ビルドが必要な頻度に関連するビルドタイミングを設定する必要があります。私が以前働いていたゲーム会社では、CruiseControleを使用し、1時間ごとにフルビルドをビルドしました。必要に応じて、いつでもビルドを強制することもできます。

ホームプロジェクトの場合、1日1回は既に「頻繁に」行われている場合があります。主な要件は、ユーザーがビルドを強制的に起動できるようにすることです。

短い熟考の後、私はそれがチームよりもソロ開発者にとってより重要であるかもしれないことを提案します。

最も基本的なレベルでは、CIサーバーは、コミットされたソースからゼロからアプリケーションを構築できることを実証します-ゼロから構築および実行できることを実証する一連のテストと組み合わせます。

私がやろうとしていることの1つは、ビルドにデプロイ可能なパッケージが含まれていることを確認することなので、デプロイするもの（クリーンで既知の状態/バージョンから）を取得できることも知っています。

実際、File | New Projectを実行するときは、リポジトリの作成または追加、およびCIビルドスクリプトとデプロイメントセットアップのセットアップを含める必要があります（xcopyデプロイメント用に山積みするだけの場合でも）

補遺（2016）-現在、私のCIシステムは展開プロセスの不可欠な部分でもあるため、その価値は増加しており、それなしでは成果物プロジェクトを絶対に実行しません。自動化されたプッシュボタンの展開は、プロセスから多くのストレスを取り除きます。何らかの形で、ビルドサーバーを形成または形成することが不可欠です。

コミットするのが自分だけの場合、実際にコミットする前にビルドしてテストするだけです。通常、次のようなmakefileターゲットを使用します。

make sense

構成、ビルド、すべてのテストの実行（valgrind対応）、lintsの実行などです。私が唯一プッシュすることはわかっているので、Hudsonのようなものの力は本当に必要ありません。

また、メインリポジトリにフィードする複数のブランチがある環境では、コミットまたはプッシュする前に全員が常にプルを実行すると、CIサーバーが少し過剰になる可能性があります。最後のビルドを壊したものの作者が金曜日にピザを購入するというよく書かれたルールは、通常、物事を非常にスムーズに実行し続けます:)

プロジェクトが明確に独自のリーダーを持つサブシステムに分割される状況になった場合、ハドソンのようなものを使用することを本当に検討する必要があります。誰かがローカルでテストし、別のサブシステムとの競争に負けて、最終的に有毒なものを押し出すかもしれません。

また、動きの速いプロジェクトのフォーク（たとえば、Linuxカーネルへの独自のパッチセット）を維持している場合、そのプロジェクトで「ソロ」であっても、Hudsonのようなものの使用を本当に検討する必要があります。これは、メインラインから直接分岐/リベースする場合に特に当てはまります。

これは素晴らしいボーナスだとは言いません。ソロアーティストにとっては、高品質のソフトウェアエンジニアリングに不可欠だと思います。私たちのほとんどは、後で修正するのに十分簡単だと思う場合に急いでいる場合、品質基準を少しずらします。その状態でソフトウェアをコミットすると、本質的に価値のないコードベースがソース管理に保存されます。

適切に順守されている場合（つまり、テストをスキップせず、コミットするたびにビルドすることを確認します）、CIは、とにかくコミットする場合よりも高い品質基準を順守するように強制します。

待機時間を短縮して、すべてがまだ順調に進んでいるかどうかを確認する場合は重要です。保存するとすぐにIDEでコンテンツをコンパイルできますが、ユニットテストは自動的に実行されないため、CIサーバーにユニットテスト、テストケースカバレッジレポート、およびコードの他の品質分析を実行させます押します。

私がしなければならない唯一のトリガーは、現在の変更をバージョン管理にプッシュすることであり、コーディングに戻ることができます。そして、コーディングについて考えている間、CIシステムは、私の脳が落ち着いたときに時々見ている、長く曲がりくねった品質報告書の作成に追われています。

私はプッシュするコードのビルドを行う別のVMWareマシンを同じラップトップ上に持っています。これを行うには、Turnkey Linux VMWareイメージを取得し、apt-getを使用してジェンキンをインストールし、いくつかのマイナーな構成変更を行います。