一個Sitecore站點的Git源代碼控制策略

Question

首先，我很抱歉這個問題的規模很大，因爲我確信我提出的是一個實施方面的「重大事項」，可能是三到四個單獨的問題本身。我不會問我是不是非常需要幫助。

我已經接受了修改公司關於在線工作的風險管理程序的巨大任務。因爲我們沒有備份，也沒有保護我們的數據，所以我決定像任何參與專業編程的人都應該做的那樣，我們將通過源代碼控制來保護我們的工作。我目前使用Git在本地進行此操作，但其他人不使用源代碼控制，最終我們失去了源代碼控制提供的許多好處。我寧願我們有一個系統，每個人都使用Git，並強制規定如果它不在源代碼控制中，它不會停留。顯然，我們需要一個備份計劃，但作爲一名開發人員，我認爲首先要做的是在對備份解決方案進行排序之前，先對事物的編碼方面進行分類 - 顯然，任何有關這方面的建議都非常值得歡迎。

我們運行一個帶有SQL Server 2005後端的ASP.NET網站，運行Sitecore作爲我們選擇的CMS。在一個理想的世界中，我希望在源代碼控制下包含該數據庫的所有不斷變化的部分。

目前，我知道這不是最好的想法，我爲Sitecore中構建的所有子佈局運行一個解決方案。這是在源代碼控制之下，並感謝Git我已經能夠添加分支機構，推送新功能和輕鬆修復錯誤（使用Git-flow作爲我的工作流程解決方案）。儘管如此，我對Git還是比較陌生，所以我沒有在提交之外管理任何過於複雜的內容，忽略某些文件等。

最重要的是，我還想使用源代碼控制來獲取數據庫內容來源控制。據我瞭解，您可以將Sitecore內容項目作爲文件系統中的一棵巨大樹（如果我沒有記錯，保存爲.item文件？）。如果這是理想的解決方案，我也想將這些添加到源代碼控制，儘管我不知道它們將保存在文件系統中的確切位置。我的文件系統現在的問題是這樣的：

- Data  (Logs, indexes, etc - is this needed to be in source control?) 
- Source (Helper files, although occasionally modified) 
- Website (Containing all the files I edit, and other essential Sitecore stuff) 

如前所述我目前的倉庫只是我的系統上，它由一個單一的解決方案文件夾的帶着一幫的.ascx的，.ascx.cs，的.ascx .cs.designer和奇數.aspx文件或兩個。這樣可以讓我的生活更輕鬆上傳，就像使用

我想輸入的內容是一個管理所有開發人員的理想方法。儘管使用了DVCS，但我更願意將實時服務器視爲主要存儲庫，並讓所有其他開發人員將其推送並從中拉出，然後互相拉取。我們將使用git-flow workflow solution，因爲它符合我們良好的發展方式。顯而易見，我擔心的是在沒有備份的情況下，在不破壞目前服務器上非常昂貴的高流量網站的情況下正確設置。

有關服務器上有多少數據粘貼到存儲庫中的提示和建議，關於如何處理Sitecore中的序列化數據的指導，以及如何使用源代碼管理本身作爲備份到單獨存儲的方式存儲庫將受到歡迎。這是我第一次爲一個現場網站建立一個源代碼控制系統/工作流程，所以任何關於什麼對我來說是最好的事情的指導和建議都是值得讚賞的。

---

編輯：我打算把這個獎金，試圖獲得更多的指導人們如何處理Sitecore與Git。爲了說明我自己，我不是在尋找一種方法來備份我的工作，而是一種方式，以便一些開發人員可以使用它並確保網站上的代碼與中央存儲庫保持一致。例如，我之前已經提到過，我將使用git-flow來管理我的工作流程。原始回購將存在於一個共享服務器上（這可能會成爲一個測試環境），所有開發人員都會克隆這些工作的克隆並推向。從這裏，我希望能夠將共享驅動器上的原始回購更改推送到實時服務器，並在發現錯誤時再次將其更改回來。我還想在我的回購中包含序列化的內容項目。修訂後的問題

Answer 1

修訂的答案：

好吧，讓我對我最初的想法展開現在當我們從您的更多背景信息。既然你說你只有一次Sitecore的許可證，並且不能有一個單獨的測試服務器等，我們總是可以稍微修改一下，仍然可以達到同樣的效果。

如果您在運行實時Sitecore的同一臺服務器上有多個存儲庫，該怎麼辦？如果可以讓Sitecore在同一文件系統上使用不同的根/存儲庫，例如您將網址更改爲http://yoursite.com/blahblah/test以在測試模式下運行Sitecore。這取決於你有什麼樣的許可證，當然，如果它被綁定到特定的機器上。無論如何，在將這些東西合併到主服務器並讓它正常運行之前，您可以在另一個分支上測試您的站點（例如，測試存儲庫中的開發分支）。

因此，您可以在服務器上擁有一個裸倉庫，每個人都可以在這個倉庫中進行推送。你可以在同一臺服務器上有兩個額外的非裸存儲庫，一個是主分支簽出，另一個是開發分支簽出。通過ssh登錄，如果你想在你的Sitecore網站的測試版本上測試新的功能，你可以很容易地在測試庫中運行「git pull」。當您對變更感到滿意時，請合併成主人並推送給您裸露回購的主人，並以相同的方式更新現場回購。

我認爲你需要嘗試找到一種方法來讓你的網站有兩個版本，這樣你就可以在他們上線之前測試這些變化。

---

原帖：

我強烈建議你有活的服務器，什麼之間的分離你目前的工作，即另一個倉庫，你把你的工作太（和拉），它的工作原理作爲一個集成存儲庫。這樣，您可以在將代碼推送到實時服務器之前集成代碼並在本地對其進行測試（本地到您的組織），因此沒有人不小心將代碼/數據庫/無論直接推送到實時服務器。

我還建議您爲中央存儲庫備份數據，換句話說，git應該用作版本控制系統，而不是備份系統。即使git可能會失敗並導致存儲庫損壞，如果您沒有任何備份，那麼您將被吸引。

此外，如果可能的話，嘗試將實際網站內容與邏輯上的數據分離，即嘗試保持良好的模型/視圖概念。這樣，您可以使用獨立於代碼的測試數據庫輕鬆設置測試環境，並且不需要提交數據庫。除非你真的想要提交他們當然:)

Answer 2

查看HedgeHog的團隊發展Soultions（3.0是最新版本）。它滿足了許多與Visual Studio，Sitecore Rocks，Team City（或其他構建服務器）。請訪問http://hhogdev.com/瞭解更多詳情。

Answer 3

當我退後一步，試圖看看你在做什麼時，它正在管理失去業務連續性的風險。例如如果您的網站出現故障，您最好希望能夠使用備份完全自動恢復網站。

數據存儲並不昂貴。真的，事實並非如此。即使你有一個龐大的數據集。因此，要求所有開發人員使用git是一個好主意。許多組織建立一個單一的git服務器，並且你只需推/拉該服務器。如果您的解決方案具有良好和完整的測試，您將很快知道代碼合併是否已破壞軟件。如果沒有，你可能應該使用一箇中央git服務器讓開發人員推/拉，然後使用「git fetch」來合併&測試變更的中央服務器的單獨版本集成服務器。

您列出瞭解決方案的各種組件，如備份代碼，數據，數據庫，CMS條目等。但是，您應該詢問的總體問題是，您是否收集了足夠的內容才能夠從備份中完全激活您的站點。如果你做不到這一點，你做得不夠。如果你能做到這一點，你做得足夠了。

在許可問題上，您需要更好的許可證。詢問Sitecore的所有者獲得測試服務器的許可證，並告訴他們它是用於測試服務器的。一個好的供應商會意識到，如果他們以這種方式幫助你，你更有可能續訂你的訂閱。或者，向您的財務人員詢問另一個Sitecore許可證。如果您的基於Sitecore的CMS網站對您的公司來說是一個很好的實用工具，那麼另一個許可證不會改變這個好處。

Answer 4

我花了一個小時瞭解我可以做些什麼關於Sitecore（今天之前從來沒有聽說過它，很酷的工具），我想我明白你在做什麼。下面是我該怎麼做：

1. 在Linux上設置一個幸運的裸回購（物理或虛擬，應該不重要）。
2. 在生產環境中初始化一個git倉庫，在所有源代碼，配置文件和數據都可以添加到倉庫的基礎文件夾中。 （請記住設置一個user.name和user.email，它將標識系統管理員負責生產更新。）
3. 爲每個模式創建一個SQL Server轉儲文件，並將所有轉儲放在本地內特殊標記的文件夾中生產回購。
4. 階段所有文件（git add --all）並提交一個「初始提交，版本X.Y.Z」註釋，其中版本號是您認爲當前部署的任何內容。
5. 推向幸運的回購。
6. 克隆所有開發環境中的祝福回購。 （請記住設置user.name和user.email，以便在提交中進行正確識別。）
7. 開始使用git-flow。

注意步驟3創建SQL Server轉儲並將其添加到回購。這將允許您回滾對數據庫的任何未來更改。請記住，每次進行更改時都需要生成新的轉儲，但僅適用於實際更改的模式。序列化您需要序列化的內容，並提交新的序列化以及模式更改。這樣，git revert {commit_hash}就是您需要恢復這些特定更改（當然，不要忘記還原數據庫）。

我希望這可以幫助，直接或間接。

P.S：我不知道你的數據庫結構;如果配置與用戶數據存儲在相同的模式中，它肯定會使事情複雜化，因爲您不能在不丟失新的（並且可能是重要的）用戶數據的情況下恢復先前的轉儲。我習慣於Ruby on Rails，其中模式修訂編碼爲升級和降級;我希望你的框架提供了類似的功能。