私は 5 か月前に入社して以来、会社で継続的インテグレーションを推し進めてきましたが、私たちが取り組んでいるアプリケーションの種類を見て、すべてのプロジェクトをセットアップする労力に見合わないかもしれないと考え始めています。継続的インテグレーション。
平均的なプロジェクトに 2 ~ 3 週間かかる開発部門で働いており、一度展開するとほとんど気にする必要がない場合、継続的インテグレーションはセットアップの手間をかける価値があるでしょうか?
私は 5 か月前に入社して以来、会社で継続的インテグレーションを推し進めてきましたが、私たちが取り組んでいるアプリケーションの種類を見て、すべてのプロジェクトをセットアップする労力に見合わないかもしれないと考え始めています。継続的インテグレーション。
平均的なプロジェクトに 2 ~ 3 週間かかる開発部門で働いており、一度展開するとほとんど気にする必要がない場合、継続的インテグレーションはセットアップの手間をかける価値があるでしょうか?
おそらくあなたのプロセスに依存します。コードをカバーする単体テストがある場合、継続的インテグレーションはあらゆる価値があります。プロジェクトは 2 ~ 3 週間なので、皆さんは 1 つの作業モジュールに取り組んでいると思います。
コミットごとにすべてのテストを実行する人はいないと思いますが、ここでは継続的インテグレーションが大いに役立ちます。
もう 1 つの理由は、プロジェクトが高度にモジュール化されている場合です。私は、多くのモジュールがあり、開発者がコミットする前に Web サイト全体の機能テストを行わないシステムで働いてきました。開発者が完全なコードをチェックアウトしなかったため、他のモジュールがビルドされないため、適切にコンパイルさえされない可能性があります。
とにかく継続的インテグレーションをお勧めします。Hudson や Cruisecontrol などのセットアップを使用すると、セットアップに時間がかからず、すぐに元が取れます。
個人的には、CI とそれが促進するさまざまなプロセスは常に役立つと思います。サーバー自体をセットアップしたら、CI セットアップを取得するのはかなり簡単です。基本的には、1 つのプロジェクトから構成ファイルをコピーして編集し、新しいプロジェクトを作成するだけです。「すべてのプロジェクトをセットアップする努力」のために、CIを使用しません。
継続的インテグレーションはツールの問題であるだけでなく、一連のプロセスでもあります (定期的にコミットする、バージョン管理システムを使用する...)。
ICソフトウェアに関しては、Hudsonを10分以内にインストール、構成、および使用を開始できます。では、なぜICシステムなしで行くのでしょうか?
継続的インテグレーションは、作業が確実に機能するだけでなく、新しい開発者が行うのと同じように、リリースプロセスを文書化してテストすることもできます。
これにより、開発者がハードディスクから一緒に投げたものではなく、テストされたものを顧客が確実に入手できるようになります。
これは、メンテナンスの目的で非常に重要な場合があります。
多数のアプリが共通のコンポーネントやモジュールを共有している場合、CI とテストは問題に気付くのに役立つ可能性があります。それらがすべて本当に使い捨ての自己完結型スクリプトである場合、CI は必要ないかもしれませんが、それは困難な判断です。
他の人が指摘しているように、CI がセットアップされたら、新しいプロジェクトを追加するのは簡単なので、それを試してみるといいでしょう。目にする利点の 1 つは、プロジェクトのいずれかが変更された場合に、既に CI を取得しており、ユニット テストの準備が整っていることです。