他の人がこれにどのようにアプローチしたか興味があります。私たちのグループは、Joomla を使用した内部 Web サイトの実装を指示されました。サイトの保守を担当する担当者用の開発サーバーと、運用サーバーをセットアップしました。IIS と現在のバージョンの Joomla を使用しています。
この 2 つを Akeeba Backup Core と Kickstart で同期できますが、「オール オア ナッシング」の選択のようです。それは機能しますが、彼女がたとえばサイトのルック アンド フィールに関する作業を行っていて、コンテンツを同期したいだけの場合、それは実行可能ではないようです。
誰かが以前にこの目標に取り組んだに違いないと思いますが、Web 検索では、同じサーバー上で異なるサブディレクトリで dev/prod を実行している人が見つかるか、問題の「全か無か」を無視しているようです。実用的とは思えない「一度にすべて実行する」アプローチ。コンテンツは頻繁に変更されますが、ルック アンド フィールはそうではありません。
私たちはこれを数年前から行っています。dev サーバーと prod サーバーを使用します。dev でコンテンツを変更するときは、phpMyAdmin を使用してコンテンツ テーブルを dev db から prod db にコピーします。コンテンツ テーブル全体を一度にコピーする必要があるため、いくつかの点では、これは依然として全か無かのアプローチです。これは、コピーを行うときに、まだ開発中のページをいくつか持つことができないことを意味します。他の点では、モジュール、メニューなどの個々のテーブルをコピーできるため、これはまだ断片的なアプローチです。ただし、すべてのモジュールを一度に、すべてのメニューを一度にコピーするなどです。 dev のテーブルからページまたはアイテムを取得し、prod の対応するテーブルに配置しますが、少し面倒です。しかし、それは機能します。
デザイン要素 (画像、CSS、テンプレートの変更など) についても同じことを行いますが、一方のサーバーから他方のサーバーへのコピーは ftp によって手動で行われます。明らかに、これは、本番環境に移動する必要がある dev の pdf ファイルのようなものと同じ方法です。
要約すると、この方法は長い間、かなりうまく機能してきました。ただし、一度にテーブル全体をコピーしていることを認識しなければならないという制限があります。
これらすべての良い点は、開発中のページがある場合、1 つの未完成のページがサイト全体を保持する可能性があるため、コンテンツの人々が急いで作業を完了するために活用できることです!
このワークフローのジレンマに何度か遭遇しました。
ルック アンド フィールの変更について言及されていますが、それが単なるテンプレートの変更であれば、実際にはもっと簡単です。ライブ サーバーの Akeeba バックアップを取得し、ローカル サーバーでキックスタートし、テンプレート ファイルを操作してから、更新されたテンプレート ファイルをライブ サーバーにアップロードする方が簡単です。
とはいえ、既存のファイルを CSS や HTML で微調整する以上のことであれば、より複雑なプロセスになる可能性があります。
個人的には、この種のことに対する特効薬は見つかりませんでしたが、ある程度の事前の考慮と計画があれば、それほど悪くはありません。