多くの CMS の特徴は、設定が部分的にデータベースに保存され、これが開発と設定とコンテンツ編集の境界線をあいまいにすることです。これは主に CMS の柔軟性の影響であり、決定はサイトに委ねられているため、望ましいことです。
しかし、あなたのサイトでそのような区別を作らない場合、それはすべてのコンテンツ編集者が CMS のすべての詳細に精通している必要があることを意味します。彼らは構成を変更することができ、Plone のような一部の CMS でさえも開発を行うことができるからです。ウェブ。
したがって、各人が変更する必要があるものだけを変更する権利を持っていることを確認する必要があります。これには、Plone のような非常に柔軟で詳細な許可システムが必要です。
この分野で問題がある典型的なサイトの例は、管理者でもある 1 人か 2 人のコンテンツ編集者から始めて、完全な権限を持つアカウントを使用する場合です。通常、彼らは管理者アカウントを使用してコンテンツの編集を行います。より多くのコンテンツ編集者が到着すると、小さな変更を行うための管理者パスワードが与えられ、その後、より多くの編集責任を負うようになりますが、引き続き管理者アカウントを使用します. その結果、サイトを編集するすべての人がすべてを行うことができ、後で誰が変更を加えたかを確認することさえできなくなります.
適切に管理されたサイトでは、コンテンツ編集者は、サイトが機能するために必要なものを編集または変更することはできません。製品カテゴリを含むサイトがあり、各カテゴリにも概要ドキュメントが必要であるとします。その場合、編集者は概要ドキュメントを削除する権限を持たないでください。削除すると、すべての小さなカテゴリ リンクが壊れてしまうからです。編集/管理の役割 (多数ある場合があります) を特定し、各役割が必要な権限を正確に持っていることを確認してから、役割をアカウントに割り当てる必要があります。
権限を与えるのが難しく、編集者の権限が少なすぎる、または多すぎる傾向にある場合は、サイト開発からコンテンツを適切に分離できていないことを示しており、再構築を検討する必要があるかもしれません。コードおよび/またはコンテンツの一部。これはもちろん、詳細なパーミッション システムのない単純な CMS でより速く発生します。これは、システムが成長しきっていないことを示している可能性があります (これは、Plone IMO の主なセールス ポイントにつながります: CMS として成長する可能性はほとんどありません。使い始めるのは簡単ですが)。
コンテンツを含め、完成した Web サイトの継続的な統合テストが必要なようです。これは良い考えでもあり、悪い考えでもあります。最初に悪い:
コンテンツの継続的な統合テストを行うことは現実的ではなく、少し見当違いだと思います。また、編集者がライブサイトでテスト済みのコンテンツを編集できるようにする場合、編集者はいつでも自由にコンテンツを変更できるため、明らかに不可能です。上記を参照してください。
しかし、完成したサイトをテストすることは、必ずしも悪い考えではありません。ただし、継続的統合テストの一部としては使用しません。これは、通常、これらのテストがコードの変更によってトリガーされるためです。
私の提案は、セットアップを開発と編集に分割することです。開発環境は、ローカル開発サーバーと継続的インテグレーション セットアップの通常の環境に加えて、編集者が新機能をテストできるテスト サーバーです。
テスト サーバーは、テスト サーバーに展開するたびにコンテンツのコピーを取得します。これは通常、開発の反復ごとに数回行われます。継続的インテグレーション テストには、通常のコンテンツ エディターで編集可能なコンテンツに依存するテストを含める必要はありませんが、これらのテストでは、テスト スイートの一部として実行ごとにテスト コンテンツをゼロから作成する必要があります。
次に、コンテンツの編集が行われるサーバーであるステージング サーバーも必要です。ソフトウェアの更新は、開発の反復ごとに 1 回、または編集者がテスト サーバーの機能を承認したときに受け取ります。このサーバーでは、コンテンツの編集が行われ、このサイト用に別のテスト スイートがあり、壊れたリンクのレポートの実行など、コンテンツの整合性をテストします。編集長がコンテンツの変更に満足したら、コンテンツはテストに合格すると、コンテンツが本番サーバーにデプロイされ、公開されます。テストは、オンデマンドと定期的 (1 日 1 回など) の両方で実行できます。
もちろん、このタイプのセットアップは、おそらく 10 人以上の多くのコンテンツ編集者がいる大規模なサイトでのみ意味があります。しかし、そのような場合、それは間違いなく理にかなっています。小規模なケースでは、ステージング サーバーを取り除き、機能を運用サーバーに直接展開し、コンテンツ テストを 1 晩に 1 回実行して、かなり迅速にエラーをトラップすることができます。