開発コードの複数のインスタンスのバージョン制御

Question

私は、コンピューターサイエンスラボではなく、エンジニアリングラボで働いています。そのため、社内ソフトウェアは成果物製品ではありません。代わりに、社内ソフトウェアを使用してエンジニアリングの問題を分析し、結果を提供します。

これにより、バージョンコントロールが生きている地獄になります。あるいは、標準の「トランクとブランチ」バージョンの制御ツリー構造が適用されていないようだと言うべきです。誰かが物事をより良い方法を提案できることを願っています。

たとえば、各エンジニアリングプロジェクトでは、ケース固有の入力ファイル、ランタイムファイル、および後処理ファイルを追加する必要があります。これらは一般的ではないため、実際にはトランクに属していませんが、新しいプロジェクトにはこれらのファイルが必要です。テンプレートをトランクに入れようとしましたが、テンプレートをいつマージする必要があるかについては明確なベストプラクティスはありませんでした。

同様に、新しい機能を追加するにつれて、社内コードは常に進化しています。これらの多くは、将来のアプリケーションで利用できるようにするため、トランクに統合する必要があります。ただし、トランクが表示する必要のないケース固有のハッキングもかなりあります。

この混乱をどのように整理する必要がありますか？明らかに、よりシンプルなほど良いです。

Answer 1

私たちは本当に私たちのプロジェクトを別々に保つために試みます：

• ソースファイル（SVNのように、選択した任意のVCで管理）
• 構成ファイル（チームまたは環境に固有）

ブランチはのためです 開発努力 そして、これらの「入力ファイル、ランタイムファイル、および後処理ファイル」は、独自のペースで進化します。

そのようなファイルについては、VCSで管理したのは次のとおりです。

• テンプレート
• そのテンプレートを取得し、適切な値を含む（バージョンではないようにプライベート）構成ファイルを生成できるスクリプト。
  値は、チェックアウト/チェックイン/マージに懸念なく、チーム（または環境管理者）が自由に更新できるデータベースのような別の参照からのものです。
  そのデータベースは、必要に応じて独自のVCSでバージョンにすることができます（これを参照してください だから質問 たとえば、または、代替として、 それです)

Answer 2

エンジニアリングバージョンでは、しばしば過小評価されていますが、実験を繰り返すために特定の設定を復元することが不可欠です。一般的な採用のために、ほとんどがGUI指向のツールが大いに役立ちます。

問題をコードコミットに関連付ける問題追跡でバージョン制御を活用すると、生産性が大幅に向上します。

リポジトリ構造に関しては、少なくとも転覆を見ると、規則はありますが、ツールによって課される厳格なルールはありません。すべての「共通コード」が管理される「トランク」と呼ばれるツリーを持っているのはどうですか。

すべてのエンジニアリングタスクについて、作成されたブランチがあります。これは、バージョン制御を備えた「プロジェクトフォルダー」に他なりません。他のプロジェクトに関連するソースコードは、トランクに統合されます。