いくつかのファイルをコピーし、exec タスクを介して makensis.exe を実行してインストーラー exe をビルドする nAnt スクリプトを使用して以前にビルドした NSIS インストーラーがあります。nant スクリプトが完了すると、CD とダウンロードの完全な構造が完成します。
ソースセーフから未使用のデスクトップに取得し、それをビルドボックスとして使用して、そこでコンパイルしていました。時には、いくつかのファイルをチェックインして、重要な問題を修正することもありました。そのような場合、私はビルド ボックスに移動し、それらのファイルのみを非常に選択的に取得して、まだリリースする準備が整っていない他の変更済みファイルを取得しないようにします。基本的に、私は開発を継続させ、特定の変更されたファイルを選択的にインストーラーに含めてリリースすることができます。
これで無料のボックスはなくなり、サーバーからビルドする必要があります。そのため、開発者がサーバーにリモート接続せずにビルドを開始できるように、CI Factory をセットアップしています。私が苦労している 1 つの問題は、この選択的な変更管理を引き続き行うための最善の方法です。CI Factory が実装する CI のデフォルトの概念は、社内開発の「頭」に適しています。ただし、この「公開リリース」タイプのビルドの強制ビルドを介してオンデマンドでのみ実行される CCNet プロジェクトもセットアップしたいと考えています。
これは私がこれまでブレインストーミングしたものですが、これがうまく機能するかどうかはわかりません (CCNet と CI Factory が何であるかはまだわかりません)。「パブリック リリース」CCNet プロジェクトの構成/ビルドは、最新のものにならないようにセットアップされます。変更は行われませんビルドをトリガーします。変更が検出されたときに最新のものを取得するデフォルトの CI 方法論 (「CI プロジェクト」と呼びます) を使用している他の CCNet プロジェクトでは、これら 2 つのプロジェクトは同じ作業ディレクトリを共有できません。したがって、「公開リリース」には別の作業コピーが必要になるため、CI プロジェクトのビルドがトリガーされたときにそのファイルが更新されません。開発者は、1 つの VSS であるサーバーにリモートでアクセスし、「パブリック リリース」の作業コピーに選択的にアクセスしてから、CI Factory を介して強制的にビルドする必要があります。
私がこれで見た欠点は、
1) 選択的に get を実行するためにリモートで接続する必要があることです。
2) 1 つの CI Factory プロジェクトが Product フォルダーの 2 つの異なる作業コピーを持つことを許可して、各プロジェクト構成ブロックが独自のものになるようにする方法がわかりません。
3) 私はこれがどのような奇妙さを引き起こすのではないかと心配している. CCNet プロジェクト構成ブロックでソース管理ブロックを指定する方法はまだよくわかりませんが、ビルド時に最新のものを取得しないようにします。私はまだ、スクリプトに何があり、他のものを壊すことなく簡単に取り出すことができるのか、いじられることを意図していないものや構成可能でないものとは対照的に、徐々に理解しています。
同様の状況があれば、他の人が変更を選択的にリリースするというこの問題にどのように対処しているかについて、本当に聞きたいです。私は VSS に制約されているので、それを念頭に置いてこれを解決することが当面の必要性ですが、同時に、他のソース管理システムでこれをどのように管理しているかを聞くことに興味があります。おそらく最新の開発ブランチであるブランチがあり、リリースしたいときはいつでも変更をトランクにマージすると思いますか? 私は分岐/マージに関して VSS を本当に信頼していません。分岐の概念は、このショップのオーバーヘッドと学習曲線が少し多すぎるのではないかと思います。私が言ったように、他のソース管理システムの話は、私にとって将来の有益な知識になるでしょう.
前もって感謝します。