フロントエンドとバックエンドのソリューション組織

Question

私は、発展途上の開発グループの一員であり、最近まで、バックエンドの人たちからフロントエンドの人たちの努力を組織することに問題はなかった。

私たちはマイクロソフトのショップですから、フロントエンド（MVCプロジェクト）とバックエンド（WebAPI）はビジュアルスタジオのソリューションに共存し、すべてがうまくいきました。

私たちはフロントエンドに向かって動き出しています。フロントエンドのメンバーは、IDE、パッケージマネージャなど（WebStorm、NPMなど）を好んでいます。そして、まさにMSがこれらの新しいフロントエンド技術を採用するのが遅れているからです。

質問

どのように世界の残りの部分は、ソース管理/プロジェクト組織の観点からこれを調整しているのですか？プロジェクトのこれらの2つの「部分」は今や独自のソフトウェアとみなされ、独立して生きるべきでしょうか？

フロントエンドとバックエンドはもう共有されなくなり、2つの異なるソフトウェアとなるという自然な感じがします。チームの他の人たちは反対して、フロントエンドコードをバックエンドのVisual Studioソリューションに自動的に転記する方法を探しています。

私はこれに関する考えを探しており、最良の決定を前進させるのに役立ちます。

Answer 1

私が最後に行ったプロジェクトでは、VSを使い続けましたが、基本的にVCの理由からプロジェクトを分割しました。 gitでは個々のディレクトリをSVNで確認することはできないので、バックエンドを1つのディレクトリに、フロントエンドを別のディレクトリに配置する方法を見つけなければなりませんでした。

フロントエンドとバックエンドコードを更新する必要があるプロジェクトが複数ありましたが、コンテンツフォルダには独自の「調整」が必要でした。

基本的には、「app」ディレクトリを1つのリポジトリに配置し、それを解決ディレクトリであるより大きなレポのサブツリーとして使用しました。すべてのバックエンドプロジェクトを独自のディレクトリに移動しましたが、新しいソリューションからすべての個々のプロジェクトを指していました。仮想サブディレクトリで実行するようにサービスを設定し、ヒットしたら自動的に実行します（詳細はthis answerを参照）。あなたが同じソリューション内以外の場所からサービスを受けると、それがうまくいくかどうかわかりません。

基本プロジェクトを完了したら、クライアント用に行った新しいプロジェクトでは、ソリューションにマッピングされた親リポジトリのブランチと、「app」フォルダを含むリポジトリのブランチが作成されます。 "ソリューション"ブランチをそのクライアントのデータベースを指すように更新します。

私たちは常に、クライアントプロジェクトのブランチではなくオリジナルのプロジェクトブランチで新しい仕事をしました。アプリケーションコードを変更するたびに、元のプロジェクトのサブツリーからプッシュし、元のブランチからクライアントブランチにマージし、サブツリーをクライアントソリューションのappディレクトリにプルしてから、クライアントにプッシュバックしますソリューションのブランチ

このワークフローが競合を防止する最善の方法であることがわかりました。

これは実際にツールの問題には対処していませんが、問題へのアプローチ方法についてはいくつか考えています。つまり、Visual Studio + ResharperはWebstormよりはるかに快適です。 JetBrainsはWebstormとResharperの両方を作ったので、Webstormで探しているResharperと同じ機能を多数得ることができます。

NugetがJSライブラリをインストールするのを嫌うことに同意します。使用するときに何が入ってくるのかは決して分かりません。私は通常、NPMをハードドライブのどこかにインストールして、必要なファイルをScriptsディレクトリにコピーします。これはまた、NPMのインストールで得意なことをたくさん避けることができます。しかし、NPMやバウアーを使用したい場合は、VSプロジェクトでそれを使用できず、インストールするように設定されたディレクトリーをスクリプトに変更するか、BundleConfigまたはGrunt/Gulpスクリプトのパスをnode_modulesまたはそれぞれbower_componentsです。