33

私は楽しみのために Web 開発技術に足を踏み入れてきました (いや、もっと出るべきです)。プロダクション ステージング (つまり、開発、テスト、パフォーマンス、およびプロダクション環境) に対する明確なサポートがないことに少しショックを受けています。実際、サポートという言葉はありません。コンテンツ管理システムは、クリーンなステージングを可能にする努力に積極的に反対しているようです.

現在、私は Drupal を使用しています。コミュニティがこの問題を解決する方法を見つけるのに非常に苦労しました。私が見た投稿のほとんどは、開発で行った手順を本番システムで再現することを推奨しています (これを読んだことで、実際に私の人生が少し短くなりました)。開発者が増分機能を追加できるように、本番データを開発者にプッシュするという話も耳にします。これではいけません。クライアントがデータを開発環境に戻すことを望まない場合はどうすればよいでしょうか?

最後に私の質問：

CMS の実際の本番ステージングの問題をどのように管理していますか?

私は、生産を推し進めることは、人々を月に送るようなものだと感じている背景から来ているので、少しリラックスする必要があるかもしれません. ただし、ソース管理、本番環境のロールバックの許可、およびテストに関する回答にはまだ興味があります。

4

3 に答える 3

10

DB展開戦略に関する質問に回答しました。

コードの展開についても質問があります。

私が働いている場所では、かなり大規模なDrupalデプロイメントに取り組んでいます。おおまかに以下の設定があります。

すべての開発者はローカルサンドボックス（Drupal + DB）を持っています。他のすべての開発者（私たちの約15人）の間で共有されるブランチへのコミットコード。これには、更新機能によって実行される構成変更が含まれます。

開発者がsvnupを実行すると、update.phpも実行して、構成の変更をローカルで実行します。

simpletestを実行し、ユーザーテストに使用できるスプリントテストシステムがあります。

スプリント（スクラムを使用）の最後に、ブランチをトランクにマージし、これに対してテストを実行します。

次に、これをリリースとしてタグ付けし、ライブにデプロイし（Capistranoを使用）、最後にライブでupdate.phpを実行して、構成の変更をライブに適用します。

緊急修正はトランクから展開され、ドットリリース7.1などとして機能します。

詳細が必要な場合は、コメントを残してください。

于 2009-10-08T10:41:12.830 に答える
7

Drupal の学習曲線を乗り越えるために数週間を費やした後、複雑なサイトを構築している場合、「DB に保存される構成が多すぎる」という問題は非常に当惑します。

Development Seedがこの問題を回避するために行っている作業を見てください。彼らはContext、Features、およびSpacesモジュールの開発をリードしており、これらは連携して構成データをモジュール (DB の外部) に格納し、コードでバージョン管理できるようにします。

于 2009-10-09T11:01:19.890 に答える
2

現在、私は Drupal を使用しています。コミュニティがこの問題を解決する方法を見つけるのに非常に苦労しました。

これは Drupal の弱点の 1 つです。それは本当にこの問題を適切に扱っていません。Drupal の構成の大部分はデータベースに存在するため、特に整理が困難です。

于 2009-10-08T06:36:09.513 に答える