2012-12-06 101 views
7

我更新的現有的WordPress網站使顯著修改的主題和網站結構,以及進行更新,以插件這反過來存儲數據到MySQL數據庫。WordPress網站發佈管理策略

據我所知這裏有2(3?)可能的策略:

  1. 「轉儲並加載」從開發的MySQL數據庫的生活和替換爲最新版本的wp-content文件夾。
  2. 通過WP導入器導入更改,並用最新更新替換wp-content文件夾。
  3. 通過WP管理界面手動進行數據庫更改,並用最新的更新替換wp-content文件夾(這僅適用於較小的更改)。

雖然我在我自己的獨立環境中開發,但這是針對現有網站,它現在仍在運行,並將繼續接收公衆更新,例如評論和聯繫表單中的條目,因此我期望數據庫是與我發佈變更的時間不同。

鑑於此,上述選項提供了以下問題。

1轉儲和裝載

的「轉儲並加載」的策略似乎是做我的數據正在幕後更新的問題(這將是我的首選方法,因爲這很容易回滾)。

結果:需要同步數據庫發佈後才能獲得最新更新,過於複雜。

2.使用進口商

使用WP-Importer plugin頁和後ID將得到更新,搞砸了造型依賴於後的ID即可激活。這反過來會產生一個我希望避免的CSS惡夢,必須在版本之後通過CSS 更新數據庫創建的新頁面/帖子ID。

結果:太挑剔,不是很專業的方法導致漫長而複雜的發佈過程。

3.更新數據庫中手動

這個選項是非常適合小的變化,但是當用於更復雜的版本的步驟列表到PROD接口上遵循變長,難以遵循,因此很容易使錯誤。

結果:太容易搞砸了,只能是最後的手段。

是否存在用於存在網站的標準詞語發佈策略?

所以基本上,我的問題是:當更新一個現有的網站時,其他WordPress開發者會遵循什麼樣的發佈流程?有沒有下面列出的選項可以最大限度地減少麻煩並減少發佈期間的時間和複雜性?

我已經爲使用GIT的網站設置了源代碼控制,並且我習慣通過ANT或類似的發佈腳本來自動化事物,但這對於當前項目來說可能是過度的,但至少理解一個簡單的方法更新WordPress的網站,並儘量減少搞砸的機會。

謝謝!

+2

爲什麼我不喜歡wordpress的另一個原因 – cegfault

+1

我確信我已經在[WordPress StackExchange](http://wordpress.stackexchange.com/)上多次討論過這個問題。 – brasofilo

+0

想象一下,他們甚至已經爲WordPress這幾天換了一個堆棧.. –

回答

2

我不認爲這是WordPress的特殊情況,它是一個類似的情況,任何自定義網站。我個人更喜歡重放在dev上製作的SQL更改。棘手的部分是,你必須知道做了什麼SQL更改。例如,某個插件在安裝時可能會進行一些模式更改 - 您需要知道它們是什麼。您可以通過在安裝插件之前創建數據庫的導出爲SQL,然後再進行導出並對文件進行差異化。

既然你說你正在進行修改,那麼我可能會假設你知道你要做什麼SQL更改?只要確保對數據庫所做的所有更改都是以SQL腳本文件的形式進行的,而不僅僅是使用GUI進行編輯(您可以使用GUI來幫助編寫查詢,但保存實際的SQL)。完成所有更改後,您應該有一堆在開發過程中運行的SQL腳本 - 您可以按順序重新運行它們而不會遇到錯誤。

然後,當需要進入生產階段時,創建一個分階段生產版本(即採用相當流行的生產數據庫備份)。運行你的更新腳本並測試一切正常。如果是這樣,那麼你可以運行生產。

在對其執行任何更改之前,肯定會對生產進行備份!

+0

對於DIFF在DEV數據庫之前和之後的變化+1。好主意。 –

2

不用說,你有其他的選擇。如果您正在手動更改數據庫,請確保您正在有效地使用序列化數據。我建議使用Search and Replace DB。 WordPress對changing the site url entirely from the wp-config file也有一個很好的小竅門。

+0

對WP_HOME/WP_SITEURL變量+1,並使用Search + Replace DB腳本修復序列化數據。 –

1

我假設你有一切在測試環境中運行。然後我會:

  • 在您的生活環境中創建一個新的數據庫。
  • 預加載新站點的所有內容和配置。
  • 在您的測試環境中,將config.php配置爲指向新的數據庫。
  • 將所有文件上傳到實時服務器。最後上傳您的config.php。

這樣可以最大限度地減少停機時間。

+0

這似乎是您的數據在幕後更新的問題。 – Maarten

+0

好的建議謝謝,如果通過上面的選項3進行手動更新,將會最大限度地減少停機時間(手動數據庫更改) –