私はこの設定をしましたが、それは完全に正しくないようでした。
複数の.NET(顧客)開発チームにわたるコンテンツ配信(CD)開発をどのように改善しますか?
CMSサーバー->プレゼンテーションサーバー環境
- CMSプロダクション->ライブおよびプレビューWebサイト
- CMS複合テスト+受け入れ(内部では「ステージング」と呼ばれます)->ライブ(「ステージング」)
- CMS開発(DEV)->ライブ(開発Webサイト)および場合によっては開発者ローカルマシン(ラップトップ)
期待と制限:
- 複数のチームと複数のウェブサイト
- 単一のDEVCMSライセンス(通常、顧客にとってはそうだと思いますか?)
- 各開発者に十分なCDライセンス
- できれば、開発者はローカルで変更をプログラムして実行できます-これは合理的な期待でしたか?
働いた
ローカルマシンとCDDEVの同じブローカーデータベースに対してContentDeliveryAPIを使用してASP.NETページを開発しました。ローカルマシンにはCDdllと独自のライセンスファイルがあり、クエリとコンポーネントプレゼンテーション呼び出しで正常に実行/デバッグされました。
悪い
時々、DevプレゼンテーションサーバーとDeveloperマシンの両方に公開しましたが、現在はそうではないようですが、ローカルマシンでスキーマファイルを取得することだったと思います。しかし、はい、私たちはDevブローカーデータベースを信頼していませんでした。
問題がある:
ローカルマシンにはTridionで公開されたページが必要な場合がありましたが、ローカルマシンに確実に公開できませんでした。
- 単一の「ローカルマシン」パブリケーションターゲットに複数のパブリケーション宛先を設定することは機能しません。これらの「サーバー」を家に持ち帰ることがよくあります。
- VPNは、オフサイトのラップトップへのアクセスをブロックしました(その時点で「着信」フォルダーを使用していました)。
各開発者のパブリケーションターゲットを管理し、新しいラップトップごとにCDを設定することは、良い習慣でしたが(演習のように、必ずしも良いアイデアではありません)、少し面倒でした。
これらの後知恵のアプローチは適用されますか?
- 物理ファイルを開発者からローカルマシンに自分で同期しますか?
- プレゼンテーションサイトをローカル(ローカルホスト)で実行するのではなく、dllをビルド、アップロードし、Devからテストしますか?
- 4番目のCMS環境が欠けていただけですか?セールスガイが好きだったのと同じくらい、別のCMライセンスを購入することに興味はありませんでした。
組織内の複数の開発者向けに.NETCDをより適切にセットアップするにはどうすればよいでしょうか。
編集:@DominicCroninは、これは適切なDTAPセットアップのサブセットにすぎないと指摘しました。用語を更新し、 Tridionを使用したDTAPを明確にするために別の質問を作成しました。