2012-08-01 83 views
9

製作Magento更新(維護不當的Magento安裝)的最佳做法是什麼?進行Magento更新的最佳做法?

我想的東西像下面這樣:

  • 看一看在應用程序/代碼/本地全重寫模塊 - 其中的文件與舊版本比較和轉發端口到新的Magento版本
  • 比較模板
  • 比較佈局XML文件(如果它們被直接複製到自定義主題文件夾,並使用了僅含真正的更新沒有單一layout.xml)
  • 比較重寫類的方法的方法原始類

主要問題是:當在舊的,維護不良的Magento安裝中區分文件時,您永遠不知道,原始文件被複制到哪個版本。有時我試圖通過查看Magento在文件評論中的版權來識別舊版本。

爲了避免更新過程中的麻煩,我們平時做到以下幾點:

  • 避免重寫,使用事件,而不是
  • 如果重寫是必要的,儘量不要複製的代碼,但調用parent ::()方法,以保持只有在覆蓋類
  • 如果複製的代碼需要必要的功能,使用標記註釋,例如[Mycompany BEGIN] ... [Mycompany END]
  • 不要複製整個佈局文件,但使用單個layout.xml,做只更新。

但是如何進行更新,如果這些防範措施沒有采取?

+0

這種類型的問題並不真正屬於Stack Overflow,因爲它不是編程問題。你應該看看http://area51.stackexchange.com/proposals/25439/magento,看到有關獲取適當的地方把這些樣的問題 – Sturm 2012-08-02 18:23:02

+0

@paperids:版本比較四周,代碼移植到一個新的版本也realated編程。但是感謝指向stackexchange提議的指針。 – Alex 2012-08-03 20:43:09

回答

0

我會做的第一件事是將網站複製到開發環境。現在做一個備份,以便您可以隨時恢復到您需要的狀態。同樣在這一點上,我會把代碼鎖定的現場。除非絕對必要(並且如果有變化,您將不得不在新的開發環境中複製它們),否則不會再對代碼進行任何更改

既然您已經有可供您使用的網站的安全副本,現在樂趣開始。

我會做的第一件事是拉下你正在運行的Magento股票版本的副本。在股票版本和你目前擁有的版本之間做一個差異/ app/code/core。這會告訴你你有什麼不同。我會盡量保持你現有的所有功能,同時讓核心恢復正常。

希望在這一點上你有一個非常乾淨的Magento安裝。你可以考慮把它推回給現場服務器,但我有一種感覺,你可能不得不做很多瞎猜才能把它變成現實,所以它可能不是一個可行的選擇。

現在我將對開發站點進行單獨備份,以便您可以根據需要回到這一點。

現在,我會嘗試在開發網站上進行升級。希望這一切都可以實現,而且升級沒有問題。如果你不這樣做,那麼你需要修正並從那裏繼續。

在這一點上,你應該有一個穩定的升級代碼庫。重新備份(爲了安全起見),推新代碼,並希望一切正常。

+0

謝謝。但是,如果許多類被重寫,佈局文件被複制等,那麼在app/code/core中沒有任何補丁的「乾淨的」Magento仍然會導致問題。所以稍後在大型Magento安裝中會有很多調試。 – Alex 2012-08-01 12:24:57

1

我首先注意到你的問題的內容表明對(我至少認爲是)最佳實踐有清楚的理解。

關於潛在的多個版本的起源:軟件升級的目標是讓新的類和方法到位。這意味着(正如您所提到的)移植任何自定義,無論它們是如何實現的。

在努力的差異之外,不幸的是您的狀況的最佳技術將是迴歸測試 - 檢查生成的輸出爲多個視圖。

這很可能是,你可能需要踢的情況下,即開始用乾淨的安裝,並積極引進自定義功能&主題化這仍然是必要。這似乎不是最有效的方法,但這裏有我相信超過明顯的開銷好處:

  1. 你會在所有的自定義行爲的控制,沒有驚喜
  2. 您將得到保證的單一起源
  3. 健康的代碼庫在某些時候給客戶成爲代碼的所有者和白名單/積極性的做法重返定製似乎是確保您的所有權是你所期望的最佳途徑。
12

正如其他人已經注意到,這裏的關鍵是要使它與乾淨的安裝相媲美,所以這裏是我在版本控制的幫助下做的事情。

  1. 讓自己現在你正在使用的Magento的乾淨版本,不要忘記使它可比較。或者使用的Magento的現有的git鏡(詳見http://blog.speedupmate.com/post/4063307705/magento-git-mirror

  2. 設立依據1.這裏的主回購,並有它在手問在評論

    :你的最終目標是有一個乾淨的核心所有git中的文件都存在於magento安裝文件中。這是必要的,所以你可以比較一切與乾淨的安裝。管理核心變更,核心文件樹(現有的,不存在的,添加的文件)。您可以使用.gitignore處理異常(不包括介質,緩存,所有與服務器相關的作用域local.xml .htaccess)。我發現將Magento核心文件移出到不同的(非公開的)目錄是很容易的(這裏解釋爲http://blog.speedupmate.com/post/9992573819/poor-mans-multisite-setup-for-magento),這會給我一個代碼狀態,其中.htaccess在升級時永遠不會發生衝突。我也從不將媒體包含在版本控制,緩存和magento生成的所有臨時文件中。這將保證您清除升級路徑,因爲您可以禁用所有升級時間。稍後比較代碼將爲您提供需要概覽的範圍,並且您可以估計需要多長時間來比較更改的部分並升級。

  3. 與您現有的網站和混帳配置現在

    到位(使其可比性)做你的代碼庫git init並添加一切與git那裏,這會在你的混帳配置,使每個文件可比性(同換行符空格等),然後修復文件權限是相同的。之後,您可以從您的網站中刪除.git文件夾,因爲您只使用git使文件在那裏可比。

    在評論中提問:這裏的要點是要讓git爲你工作,就像將所有行結束符轉換爲unix樣式並忽略空白區域一樣,理論上你可以忽略權限,但這樣做沒有用(格式化在這裏「代表命令

    git config core.autocrlf input \ git config core.eol lf \ git config apply.whitespace nowarn

    現在,如果你這樣做git init 和添加這些CONFIGS並添加一切承諾階段git會取代你的所有窗口行結束和所有的垃圾,以統一和可比期間的git然後之間的換行符請注意,zend編碼標準提供了unix樣式的行結尾,不過你會a也可以查看Zend庫不遵循它自己的標準的文件。這裏的關鍵是你需要你的文件是可比較的,以最大限度地減少你必須做的差異負載。 git格式化所有壞的安裝文件後,您將刪除.git文件夾。 Git僅用於在此步驟中自動執行「製作可比較的流程」,而不會執行其他任何操作。

  4. 從您的主回購庫中檢出您的測試存儲庫,並檢出包含當前版本的分支並命名「testsomething」或任何你需要的東西

  5. 從該結帳文件夾中刪除一切,只留下.git到位,所以它是空的,但版本控制仍然存在那裏。它會處於狀態,像所有內容都被刪除,這在這裏很重要,因爲你會知道你可能在你的壞站點上刪除了哪些文件。

    在評論中提問:我通常添加空白忽略git配置(本地或全局範圍可用),讓git爲我處理。當我們在團隊中工作時,我們總是同意基於Zend的標準:在3處提及4個標籤,unix樣式行結尾和git配置變量空間,如果涉及到構建腳本,我們使用提交鉤子進行代碼格式化和驗證。

  6. 中的所有文件到您的空目錄移動(請注意,您從現有的網站中刪除。git的目錄使其可比性之後)從˚Fcked了Magento的安裝(他們現在可比)和運行git status > changes.txt 。現在,該文件列出了您在「f聯機安裝」中所擁有的每個不同之處,您擁有的任何新文件,任何已刪除,已重命名等文件,以及您當前使用的乾淨Magento代碼。

    說明基於評論:我通常做git status --porcelain

  7. 已經制定了的.gitignore文件來幫助你放棄local.xml中VAR/*或每一個文件/目錄,你不需要版本控制和也.DS_Store,.Thumbs.db和你的ide從git創建項目文件。您不需要版本控制中每臺服務器上不同的所有介質和緩存文件和文件。

從那裏,你應該仔細概述該名單並根據該列表中你應該:

  • 每移動核心改變應用程序/代碼/ local /,並且簽了改變的文件到它的原始狀態(保持複製一個,並丟棄在覈心與git checkout filename變化)
  • 每移動改變核心模板和佈局文件發送給自己的主題文件夾和檢查用更改後的文件到它的原始狀態
  • 恢復或遷移的.htaccess變化或慈德,如果你需要保存或放棄

現在,你仍然是在惡劣的形狀,但你現在是:

  • 基於清潔核心
  • 基於版本的主樹在一個單獨的分支

現在,您可以受版本控制,可比較和基於您的主分支的獨立分支,該主分支中具有Mergeable版本的Magento。因此,讓我們嘗試升級,這是做到這一點100%成功的關鍵點。

  1. 第一步將禁用所有現在已分離到app/code/local/Mage /並分離主題的「垃圾」。如果你的核心是明確的,主題可以被禁用,你就沒有自定義代碼干擾升級過程。所以,儘管禁用:

    • 所有通過移動出來的應用程序的本地擴展和定製社區擴展的/ etc /模塊/到臨時文件夾讓它成爲應用程序的/ etc /無效/
    • 禁止自定義主題,並開啓基地/默認/
    • 這是你在處於可比較狀態的好處。你知道什麼是不同的,你可以禁用和診斷依據是
  2. 事已至此,如果你有在你的回購標記主樹中的所有主要版本或單獨支然後讓版本更高的僅僅是一個命令離開:再次混帳合併「的Magento,vhateverthenextversionis」

    • 這樣做後,「混帳地位> changes.txt」會給你的版本上運行瀏覽器的網站將進行升級之間
    • 所有修改過的文件的列表並且由於您處於默認主題並且沒有激活自定義,它將執行像一個魅力
    • 按版本重複升級版本,並通過標記在您的測試分支保存您的代碼狀態或基於現有的測試分支爲每個版本創建一個新的分支,這樣你已保存每個magento版本的乾淨狀態升級在
    • 之間在這裏再次額外的好處是,如果你使用版本控制做到這一點,你也將擺脫新版本丟棄的文件,你可以刪除它們很容易
  3. 如果你已經重述, 2。到所需的Magento版本最新那麼現在是時候吃了「S *它」你繼承和做以下:

    • 分析你所有擴展,看看他們是否可以升級,如果你能升級並打開看看他們是否有默認主題
    • 在app /代碼/本地/法師工作DIFF每個內核重寫針對它的新形式的原始版本來自應用程序/代碼/核心/法師。您可以使用像winmerge.org或變化差異工具(你喜歡的任何操作系統和工具)一個由一個或版本比較整個文件夾
    • 同去與你的模板和覆蓋模板或佈局。比較原始和合並更改新的基礎模板,並從舊DOM擺脫
    • 接通主題的變化和擴展逐一調試
  4. 如果你到這一點,那麼你已經做了shitload的工作,取決於如何搞砸安裝是可能需要幾天。但是,嘿,現在你有一個乾淨的magento核心,它受版本控制,被合併和概括的分開覆蓋,以及可以被禁用的單獨主題中的所有東西。

  5. 有趣的部分是,如果下一次升級magento可用,您可以吹口哨並將它添加爲與主樹相比,併合並更改,知道發生了什麼變化,並且清楚了什麼要進行概述和測試。

+0

一個好的和詳細的答案。我們做類似的事情。 請您詳細說明3.在第一個列表中?說實話,我不明白做'git init'有什麼用處,然後再次刪除.git文件夾而不更改存儲庫中的任何內容。 與6)在這種情況下,你可能還需要像做'git的差異-p --diff過濾= M -b -w> modifications.txt'部分或全部文件。您可以查看哪些文件在修改後的文件中發生了更改,忽略了您在此時可以忽略的空格。 – 2012-08-02 04:11:33

+0

關於第二個列表中的2.):你如何處理合並重新引入的不必要的文件? (不需要的模板主題,皮膚等)。對於媒體/我們用符號鏈接替換的目錄也是如此,以便在使用相同媒體文件夾時輕鬆地在我們的商店代碼版​​本之間切換。我們必須注意媒體/保持符號鏈接,並且不會被目錄取代。 – 2012-08-02 04:19:25

+0

編輯我的答案2,3,6。因爲我需要的「狀態」我不管理附帶安裝包我從來不刪除或忽略它們不需要模板主題相媲美,他們不跟我的所作所爲無論如何幹擾。我的目標是永遠不要更改安裝包隨附的任何文件,並將所有編輯作爲擴展名,單獨的區域設置文件,單獨的主題/皮膚文件。我忽略了媒體,tmp和Magento從版本控制中即時生成的所有文件。 Git的他這裏管理一般的變化對我來說,保持它分開僅僅是關鍵,「可比狀態」 – 2012-08-02 07:12:24