0

会社の開発方法と連携する GIT プロセス フローを思いつくのに苦労しています。私は他のソフトウェア会社と仕事をしたことがないので、私たちの方法が他の会社とどのように違うのかわかりません.

私たちが作成した 50 の異なるシステムがあります。それぞれが基本的に同じことを行いますが、顧客のビジネス ルール、評価バージョン (保険証券追跡システムを作成します) などに合わせてカスタマイズされています。 5 人の開発者) は、これらのシステムのうち約 15 にアクセスできます。彼らは、特定の週に、これらの 15 のシステムのそれぞれに簡単に変更を加えることができます。「必要に応じて」毎週ライブシステムに統合されるサポートと小規模な開発作業があります。つまり、「次のリリース」に含まれるものとして概説されているものは何もありません。来週ライブに行きます。さらに、期日を指定した主要な開発があります。これらの期日は、「

基本的に、どの週でも、マイナーなサポート/開発チケットと主要な開発チケットを本番環境に投稿できます。これらのチケットは、チケットが最初に作成された時点で確実なリリース日を持っていません。

フロントページ拡張機能を使用してきましたが、本当に現在に移行する必要があります. この開発方法に対応するために機能する git フローはありますか? 別のバージョン管理システムの方がうまく機能しますか?

4

2 に答える 2

0

変化するものを分離する

私たちが作成した 50 の異なるシステムがあります。それぞれが基本的に同じことを行いますが、顧客のビジネス ルール、評価バージョン (保険証券追跡システムを作成します) などに合わせてカスタマイズされています。

問題は Git でもワークフローでもありません。私が知る限り、問題は、コードのサブセクションが非常に多様であり、サブモジュールや外部リソースではなく、コア アプリケーションに変更を加えていることです。

経験則として、この種の問題を解決する最も簡単な方法は、変更するもの (ビジネス ルールなど) を個別に管理されるリソースに分離することです。そのリソースをどのように管理するかはあなた次第ですが、Git サブモジュールまたはPuppet ノード定義は 2 つの妥当なオプションです。

リソース ファイルとモジュール

次のことも検討してください。

  1. バリアント コードを、実行時に読み込まれる YAML、JSON、INI、またはその他のリソース ファイルとしてリファクタリングします。
  2. コンパイル時または実行時に条件付きで含めることができる、アプリケーションに適した一連のコード ファイル (Ruby モジュールなど)。

繰り返しますが、これらのことを行うポイントは、変更されたものを抽出し、すべての人にロードされるアプリケーション ロジックから分離することです。アプリケーションの言語とそのアーキテクチャに大きく依存します。ここには単一の「正解」はありません。

于 2013-06-03T16:26:21.033 に答える