タグ付けされた質問 「staging」


4
WordPressサイトの開発、ステージ、本番の展開?
だから、WordPress Webサイトの開発/ステージ/プロダクションのイテレーションを(別々のサーバー上で)できるようにする必要があります、私は通常gitを使用しますが、メインのデータベースに依存しているため、これは明らかにWordPressサイトで動作しません構成...まあ、ほとんどすべて。 だから私の質問は、皆さんどうやってやるのですか?私は簡単なグーグルを持っていて、いくつかのプラグインがあることがわかりました、これが唯一の方法ですか?使いやすさ、速度、信頼性、UIなどの点で、最も優れているのはどれですか?

4
開発/ステージングと本番の間のデータベース同期
開発と本番の間のWordPressデータベースの同期に問題があり、他の人がそれをどのように解決しているか疑問に思っています。この質問については承知していますが、実際には、より厄介でより現実的なユースケースをカバーしていません。 WordPressのライブWebサイトがあるとします。すべてをダンプし、開発環境で複製しました。変更を始めました。1週間後、更新プログラムを展開する準備が整いました。それまでの間、本番サイトのデータベースは変更されました(新しい投稿、新しいコメントなど)。ロールアウト中に本番と開発の間で変更を同期する方法と、このプロセスを(少なくとも少なくとも)自動化することは可能ですか?

3
devとprod間のWordpressデータベースの同期
以前に、2つのWordpressインストール間でファイルとデータベースを同期する方法について質問がありました。 データベースレベルの場合、答えは通常、基本的に1つのデータベースをダンプし、別のサーバーに挿入することです。これに伴う問題は、prodサーバーで行われた可能性のある変更が失われることです。たとえば、使用メトリック、コメントなど... これを念頭に置いて、Wordpress ORMを拡張して、デルタを生成し、それらをprodサイトに挿入できるようになるのではないかと考え始めました。 誰もがこれを試したり、調べたり、アイデアやコメントを持っていますか?

2
ステージングサイトで、DB内の更新の同期をどのように管理しますか?
開発者が更新をライブサーバーにリリースする前にステージングサイトを通じてテストする必要があることは広く受け入れられていますが、開発更新でWordpress DBの変更が必要になると、ライブサイトのユーザーもDBを更新するため、状況が複雑になります。 私が想像できる唯一の(混乱した)フローは次のとおりです。 ローカルサーバー(WAMP、XAMPなど)でテストする 展開の準備ができたら、ライブサイトをメンテナンスモードにします。 ライブサイトのバックアップ(Duplicator、sqldumpなど) ロックされたライブサイトのクローンをステージングサイトに作成する ローカル環境からステージングサイトに変更をアップロードする ステージングサイトをテストする ステージングサイトを公開します。 メンテナンスモードを削除する 上記のフローの欠点: 開発者がステージングサイトで更新を慎重にテストしている間、ダウンタイムはユーザーにとって予想よりも長くなる可能性があります。 変更の手動管理が必要な場合があります。たとえば、siteorigin pagebuilderレイアウトはデータベースに保存されるため、レイアウトを変更したら、ステージングサイトに手動でインポートする必要があります。この場合、ステージングサイトにページをドロップしてインポートするだけで十分です。機能している場合は、ライブサイトにインポートします。 これを達成するためのより良い、より自動化された方法はあるのでしょうか。 どう思いますか? 編集、要求に応じて、過去にいくつかの解決策が提案されましたが、決定的な解決策を提供するものはありません: 2010年9月-開発/ステージングと本番の間のデータベース同期 2011年12月-wp_options テーブルを変更する更新済みまたは新しいプラグインのデプロイ 2014年9月- ローカルの変更を新しい投稿/ページを上書きせずにライブサーバーにアップロードする方法 2015年1月-WordPress サイトのブログをプロダクションおよびステージングで維持する方法
11 database  staging  sync 

3
WordPressマルチサイトインスタンスを2番目の場所にコピーした後のDB接続エラー
これが私の設定です。http://example.comで実行されているマルチサイトインスタンスがあり、開発とステージングを実行したいと考えています。WPの既存のマルチサイトインスタンスをlocalhostに移動することは悪夢なので、代わりにステージング場所でdevを実行します。 ホスティングアカウントの/ public_html / staging /ディレクトリを指すようにhttp://staging.example.comを設定し、すべてのWPファイルをルートから/ staging /ディレクトリにコピーしました。データベースファイルもコピーし(SQLダンプ、テーブルを新しいデータベースにインポートし)、新しいデータベースを指すようにwp-config.phpファイルを変更しました。 SQLを実行してデータベースレコードを変更した後、wp-config.phpファイルの次の1行も変更します。 /** Turning on WordPress MU, new in 3.0 */ define( 'MULTISITE', true ); define( 'SUBDOMAIN_INSTALL', false ); $base = '/'; define( 'DOMAIN_CURRENT_SITE', 'example.com' ); // <- I change this line define( 'PATH_CURRENT_SITE', '/' ); define( 'SITE_ID_CURRENT_SITE', 1 ); define( 'BLOG_ID_CURRENT_SITE', 1 …
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.