3 人のチームで Sharepoint の開発を開始し、現在開発環境をセットアップしています。開発者ごとに Server 2008 をインストールすることは避けたいので、リモート Windows を使用して各開発者のマシンで VS2008 インスタンスを起動する単一のターミナル サーバーをセットアップしました。ここで、開発者のテスト環境 (つまり、開発者ごとに異なるサイト コレクション) を分離したいと考えていますが、サイトで適切に表示するには、アセンブリを GAC にインストールする必要があることに気付きました。しかし、知る限りGACは1つしかないため、開発者は自分のものを個別にテストすることはできません.
多数の 2008 Server をインストールせずに個別のテスト環境を作成する方法はありますか?
では、Visual Studio を起動してリモートに移動し、コンパイルして IIS を再起動するなどということですか?
あなたはお互いのつま先を踏みつけるつもりです。
最近の賢明な選択は、Hyper-V (またはその他の仮想化) を使用することです。
ラップトップで Windows Server 2008 を使用し、Hyper-V を使用して開発環境を実行しています。次に、それぞれに開発環境 (サンドボックス) があり、これらには VS2008、SVN、Nunit などがあります。
私たちのコードは、唯一の共有 Hyper-V 上の CruiseControl のおかげで相互にテストされています。
これは私たちにとって素晴らしいことです...私たちは負荷を分散し、移動中に作業することができ、お互いのつま先を踏むことはありません.デモを行う必要がある場合は、Hyper-Vを切り替えて、デモからハイパー-V (環境がわかるように早い段階で dev から分岐)。
仮想に行き、振り返らないでください。
PS: 1 つのサーバーに関するあなたのコメントを見たところです...その上に Hyper-V を配置し、3 つのインスタンスを実行するだけです。それも私たちがしていることです;）
いいえ。GACに加えて、機能やサイトテンプレートなど、12個のハイブにはすべてのSharePointファイルがあります。サーバーのコストを節約する価値はありません。
（もちろん、GACを使用せずに、binフォルダーにデプロイし、12ハイブの何にも触れない場合は、各開発者に同じサーバー上の独自のWebアプリケーションを与えることができます。ただし、このアプローチでは、彼らができることには多くの制限がありますが、それでも価値はありません。）
仮想マシンは機能しますが、開発に時間がかかる場合があります。たとえば、GACをデプロイするたびにアプリケーションプールを再起動する必要があります。これは、アプリケーションをリロードするために15〜60秒の休止を意味します（ハードウェアによって異なります）。これは迷惑になります。
仮想マシンは、アプリケーションをそれほど頻繁に再起動しないテストと本番環境でより適切に機能します。
開発者ごとに物理サーバーをお勧めします。これにより、code-deploy-testのサイクルタイムが最小限に抑えられ、お互いに足を踏み入れることを心配する必要がなくなります。
サーバーをすべてにインストールすることについてはわかりませんが、これは物理マシンではなく仮想マシンにとって理想的なタスクのように思えます。
インストール プロセスなどのテストに関しては、スナップショットにロールバックできることも役立ちます。
あなたはターミナル サービスで間違った方向に進んでいます - それはあなたに分離を与えません。
多くの人が、W003/2008 サーバーで直接開発することを推奨しています。これにより、リモート デバッグなどのいくつかの作業が簡素化されます。
VMWare を使用して仮想マシンを実行する従来の方法を好みます。これらは、ローカル ホストまたはリモート ホストで実行できます。リモート デバッグはセットアップが少し複雑ですが、それでも可能です。
最後に、可能であれば、GAC ではなく bin ディレクトリにデプロイします。これにより、コンパイル後に自動的に展開することがはるかに簡単になります。
複数の開発者による単一サーバー環境には多くの障害があるという寄稿者の意見は正しいです。
最初の開発者は、同じ Web アプリケーション プロセス w2ps.exe に接続しようとするため、時間を共有してデバッグする準備ができていない限り、異なるポートで個別の Web アプリケーションを作成する必要があります。 sharepoint 2013 の開発環境のセットアップ方法
2 つ目の問題は、共有コンポーネント/機能を共同で使用しようとする場合です。別々に作業したいという願望を持つことには議論の余地がありますが、チームの開発者は協力して共有する必要があると私は信じています。複数の開発者による単一サーバー環境は、共同作業を試みるまでは完璧に機能します。チーム メンバーがまったく関係のないコンポーネントに取り組んでおり、IIS の再起動や IIS プロセスへのデバッガーの接続などの一般的なことを行う必要がない場合を除き、このタイプの環境は一般的にうまく機能しません。http://technet.microsoft.com/en-us/magazine/dn145990.aspx私たちは経験と知識が不足していたためにこの間違いを犯しましたが、一度犯してしまえば、それを回避することは可能です.
機能を共有するための最初の試みは、開発者 1 のプロジェクトを開発者 2 のソリューションにコピーし、開発者 2 のプロジェクトへの参照を追加して、すべての機能を開発者 2 のパッケージに追加することでした。これを展開すると、開発者 2 で問題なく動作しますが、開発者 1 がデバッガーからソリューションを切り離すと、ファームから、したがって各開発者の Web アプリケーションから、複製されたソリューション ID に基づいてソリューションが撤回されることがわかりました。したがって、開発者 2 は、ラグが下から引き出されています。これは部分的な解決策であり、しばらくは機能しているように見えましたが、何が起こっているのか、dev 1 と 2 の展開のどの組み合わせが互いに機能し、機能しないのかを理解するのにしばらく時間がかかりました。
そこで、より良い解決策を見つけました。Visual Studio の [SharePoint] タブのプロジェクト プロパティの下に、[デバッグ後に自動取り消し] というコンボ ボックスがあります。デフォルトでは、開発者が接続されたデバッガーを停止し、他の開発者の下から機能を引き出すと、ソリューションが取り消されます。このボックスのチェックを外すと、撤回が防止され、各開発者は個々のソリューションをファーム レベルでデプロイしたままになり、デバッガーに再アタッチすると、ソリューションが最小限の手間で置き換えられます。
私の経験では、IIS アプリケーション プールのリサイクルは他の開発者が気付かないほど高速ですが、チームが 2 人を超えると、これがより一般的になる可能性があるため、他の誰かが経験を追加する可能性があります。また、他の開発者がリサイクルが行われているのとまったく同時にアタッチしようとしない限り、それは問題ないと思います。したがって、時間の経過とともにクロスする可能性は非常に低く、単純にデタッチして再アタッチするだけでこれが修正されます。経験したことがあります。