2014-07-10 49 views
1

我知道在多站點Sitecore實例中有關站點隔離方面的問題,特別是在提到Tim's multi-site solution時,但我在嘗試充分實現Tim的代碼。多站點Sitecore實例中的站點隔離特別適用於Sitecore

我們目前正與裏面有近十個網站在這個時候Sitecore的情況下工作。我們有一個單獨的Visual Studio解決方案,以這種或那種方式將所有站點提供給單個代碼庫,以便所有DLL都是共享的,並且任何其他文件都可以。我們已經或多或少地開始處理這個問題,將所有的網站分解成他們自己的項目,每個項目結構都反映了單一的最終結構。這隻允許在修改.csproj文件等項目時減少「流失」,從而減少與其他並行工作的開發人員的衝突。雖然這絕對是一件好事,但它比我們真正的追求更方便。

對於一個多一點的背景下,我們有一個「流」五種總Sitecore的情況下,這是當地開發商的情況下,發展的情況下,分期實例,然後兩個生產實例。我們正在使用Git管理更改。

目前我們無法進行編譯的更改,如對任何代碼隱藏進行更改,因爲它適用於一個站點中的一個項目(這不會影響其他站點的功能),並部署已編譯的更改沒有其他網站必須依賴該DLL。這成爲一個問題的主要方式是,我們無法保證所有網站在任何代碼被推出時仍能運行;對單個網站的任何更改都可能會一次打破所有網站。有些情況下,我將代碼更改錯誤地部署到了破壞所有站點的開發中,因此這是一個完全實現的問題。我們也不希望在每次代碼更改時都測試每個站點,在不久的將來,我們可以在Sitecore中擁有超過30個站點。

也許蒂姆的多站點解決方案做到這一點,但有什麼辦法,真正隔離場所,使他們不都依靠同一個DLL文件?那麼我們可以爲每個網站分別使用Visual Studio解決方案嗎(我覺得這很理想)?我已經看到其他答案提到蒂姆的解決方案是「隔離」,但這對我來說太模糊了。 Tim的解決方案在多大程度上「隔離」網站?有更好的解決方案嗎?

回答

0

單個Sitecore的應用程序實例本質上是一個或多個前端網站的虛擬主機環境。每個站點都由可以共享的佈局和UI組件組成,但他們不需要。也就是說,您可以通過單獨的項目或解決方案爲每個站點複製組件,這將解決該問題。但是它會在所有站點上打開另一個重複代碼的問題。修復一個問題,你需要多次。另外,當您部署DLL時,它將回收應用程序池,因此所有站點都將重新啓動,因爲它是相同的應用程序實例。我能給出的最好指導是組織起來,並有一些編碼治理。也許所有可能會破壞多個站點的站點所使用的一組公用事業應該被非常小心地改變。特定場地的組件更多地位於邊緣,影響較小。此外,不要將UI組件與常見實用程序中的繼承層和代碼層連接起來。雖然它可能在邏輯上有意義,但它會產生很多可能導致問題的耦合。就我的2美分而言,基於同樣挑戰的經驗。

在我們的情況下,我們的所有網站共享的核心工具庫,共享的UI組件,然後單獨的特定網站的web項目,只是這些網站組件的核心網項目。我們也儘可能地避免全局配置更改,並且「修補」諸如事件和管道等功能。請儘量讓您的代碼適用於特定的網站。

0

如果需要真正隔離 Sitecore的網站和部署中,可以選擇其中每個站點都有它自己的解決方案,IIS網站(和應用程序池),部署管線和所有共享的功能/配置通過的NuGet完成的模型包。在這個模型中,您有一臺CM服務器,所有站點都可以共享網站。

此外,你還可以在每個站點自定義事件提供程序,只有讓緩存沒有對每一個發佈的所有網站清除提出了有關問題的項目特定網站的活動隔離出版。

這種隔離方式目前正在生產中,每臺服務器有70多個站點,大約80個開發人員分佈在大約10個團隊中。

+2

這是有趣的,我同意,但這裏的重要的提醒是,因爲許可每個實例是用來 –

+0

許可證是的,這是與當前Sitecore的許可模式不幸言中。但對於擁有合適許可的客戶而言,這是一個有效的選擇 – pbering

相關問題