私はまだCommerce Serverとその開発ツールをよく知っていません。 私は、売却されるものを保持するためのDBが含まれていることを理解します。 1台のテストサーバーと複数の開発ワークステーションがある場合は、devインフラストラクチャをセットアップして、これらを共有しても構いませんか？ CVSリポジトリを格納した別個のサーバもあります。複数の開発者が手動でCVSサーバからプルして作業し、チェックインします。 テストサーバのビルドとデプロイツールはCVSから引き出され、テストサーバーに展開します。 私の心配は共有DBであり、各デベロッパーワークステーションには独自のDBが必要ですか？ 複数の開発者、1つのテストサーバー、およびソース管理システムの処理方法に関する一般的な概要を探しています。Websphere Commerceのソース管理を使ったセットアップ。
私は決してデータベースを共有しようとはしませんが、すべての開発環境が（DBの）他の開発者の変更を上書きする可能性があるので、それは良い考えではないと思います。
デベロッパーがデータベース構造を変更する必要がある場合、それは誰にも害を与える可能性があります。
各開発環境にデータベースを用意することをお勧めします。テスト環境と同じである必要はありません。
テストサーバー用のビルドとデプロイには適しています。
チームの大きさによって異なりますか？小規模なプロジェクトのほとんどで、私はチーム内の全員が独自のDBを持っており、特にDBがDerby/Cloudscapeの場合はDB2やOracleを使った大きなプロジェクトになると、他のマシンに格納されている共有DBを使うことをお勧めします誰のローカルマシンよりも。片方の人がデータを削除すると共有システムが問題を引き起こす可能性がありますが、これは小さなバックアップなどで解決することができます。一方、チーム内の全員が独自のDBを持っている場合は、LeadがすべてのDBを（つまり、毎日の仕事であるCVSからコードを同期させるたびに、ワークステーションを動作させるために、小さなSQLSqlのアップデートが必要です）
これは可能です。 IBMはその構成をサポートしています。ほとんどの開発者は、WCS Developerに付属の埋め込みWCS環境を使用します。これはデータベースとしてApache Derbyと共にランタイムを持っています。
また、IBM製品の専門家と相談することをお勧めします。彼らはベストプラクティスを教えて、ソフトウェア購入の一環として彼にアクセスすることができます。 PMRを開き、あなたの質問をしてください。
開発者ごとにローカルデータベースを使用します。
次に、liquibaseのようなものを使用してデータベース構造の変更を管理します。 すべてのデータベースの変更がスクリプト化され、ソースリポジトリに配置されるように要求し、次にliquibaseサーブレットをStoresプロジェクトに追加します。そうすれば、開発者が新しいものをチェックアウトするときに、サーバを再起動するときにローカルデータベースが自動的に更新されます。
これは、SQLスクリプトがチームの開発者の少なくとも1人で実際にテストされるという利点があります。
今、理想的には、開発者にもwcbdを使用しています。しかし、それはあなたのシステム上で既に実行されているスクリプトを追跡しないので、（このテーブルが既にX文字列をY文字に拡張していないかどうかを確認するために）スーパー防御SQLスクリプトを書くのは非常に面倒です。本当にあってはならないものを上書きするかもしれません。