0

SageSalesLogixWebアプリケーション用に組織のソース管理アーキテクチャをセットアップしようとしています。SVNを使用しています。

サーバーは3つあり、1つは開発者、2つはユーザー受け入れテスト用、2つは本番用です。各環境には独自のデータベースがあります。

トランクを整然と保ちたいのですが、SalesLogixが望む方法でVFSを管理する場合、これは難しい場合があります。

私がやりたいことはこれです：-すべての開発者にAppArchのSalesLogixのDEVインストールインスタンスを使用させます。-ローカルユニットのテストとレビューのために、変更をローカルマシンに展開します。-すべての開発作業が完了したら、提案されたリビジョンのすべての変更のバンドルを作成します。-1つのビルドマネージャーがバンドルをUATインストールインスタンスにインストールします。-コンパイルしてUATフォルダーにデプロイします。-拒否された場合は、バンドルをアンインストールし、変更後に再インストールします。-受け入れたら、本番サーバーでも同じことを行い、変更をコミットします。

これは、3つのVFSがあることを意味しますが、1つだけで開発していることを意味します。これは、私にとっては、進むべき道です。

私は自分の考えで正しい方向に進んでいますか？

4

1 に答える 1

1

正直なところ、私はSalesLogixモデルにSVNを使用していません。代わりに、GitをSalesLogixでのみ使用しています。これは、Gitの動作方法が、SalesLogixおよびアプリケーションアーキテクトの動作方法とよりよく適合しているためです。通常、SCMは重要ではありませんが、SalesLogixでは問題になります。SVNがSalesLogixモデルでうまく機能しないことは言うまでもありませんが、SLXでSVNを使用するものもあります（GitやMercurialほど簡単ではありません）が、正直なところ、SalesLogixは好みは別としてVFS /モデルは、完全に分散されたSCMでのみうまく機能します。

そうは言っても、あなたが説明しているのは、GitでSalesLogixをどのように操作するかです。私は開発ブランチを作成し、そこですべての作業を行います。マスターは基本的に本番環境にあるものを反映しているため、必要に応じていつでもマスターから本番環境に再デプロイできます。開発ブランチでは、すべての開発を行い、特定の機能の機能ブランチも作成します。次に、機能が完了したらマージし直します。このように作業することで、本番作業ブランチに移動する前に、すべてを開発してテストすることができます。デプロイの準備ができたら、本番ブランチに簡単に切り替えて、そこからデプロイできます。QAによって拒否された場合は、本番ブランチに切り替えるか、必要に応じてコミットをロールバックするだけです。また、このように作業すると、実際には単一のVFSまたはモデルのみが必要になります。

ただし、これらすべてを使用して、本番環境とは別の開発およびテストシステムを維持しています（主にSLXの顧客ではなくSLXのビジネスパートナーとして働いているため）。そうしないと、バンドルをテストして配信する方法がありません。開発システムでは、上記の分岐を使用して、新機能の開発がまだ進行中の間に修正を本番環境にリリースできるようにします。

より具体的なSVN情報があればいいのですが、使用するSCMに関係なく概念は同じです。

于 2011-07-08T20:04:00.053 に答える