我知道在多站點Sitecore實例中有關站點隔離方面的問題,特別是在提到Tim's multi-site solution時,但我在嘗試充分實現Tim的代碼。多站點Sitecore實例中的站點隔離特別適用於Sitecore
我們目前正與裏面有近十個網站在這個時候Sitecore的情況下工作。我們有一個單獨的Visual Studio解決方案,以這種或那種方式將所有站點提供給單個代碼庫,以便所有DLL都是共享的,並且任何其他文件都可以。我們已經或多或少地開始處理這個問題,將所有的網站分解成他們自己的項目,每個項目結構都反映了單一的最終結構。這隻允許在修改.csproj文件等項目時減少「流失」,從而減少與其他並行工作的開發人員的衝突。雖然這絕對是一件好事,但它比我們真正的追求更方便。
對於一個多一點的背景下,我們有一個「流」五種總Sitecore的情況下,這是當地開發商的情況下,發展的情況下,分期實例,然後兩個生產實例。我們正在使用Git管理更改。
目前我們無法進行編譯的更改,如對任何代碼隱藏進行更改,因爲它適用於一個站點中的一個項目(這不會影響其他站點的功能),並部署已編譯的更改沒有其他網站必須依賴該DLL。這成爲一個問題的主要方式是,我們無法保證所有網站在任何代碼被推出時仍能運行;對單個網站的任何更改都可能會一次打破所有網站。有些情況下,我將代碼更改錯誤地部署到了破壞所有站點的開發中,因此這是一個完全實現的問題。我們也不希望在每次代碼更改時都測試每個站點,在不久的將來,我們可以在Sitecore中擁有超過30個站點。
也許蒂姆的多站點解決方案做到這一點,但有什麼辦法,真正隔離場所,使他們不都依靠同一個DLL文件?那麼我們可以爲每個網站分別使用Visual Studio解決方案嗎(我覺得這很理想)?我已經看到其他答案提到蒂姆的解決方案是「隔離」,但這對我來說太模糊了。 Tim的解決方案在多大程度上「隔離」網站?有更好的解決方案嗎?
這是有趣的,我同意,但這裏的重要的提醒是,因爲許可每個實例是用來 –
許可證是的,這是與當前Sitecore的許可模式不幸言中。但對於擁有合適許可的客戶而言,這是一個有效的選擇 – pbering