推動MOSS '07網站從開發到生產

Question

因此，也許我有點老派，但是當我們在過去創建網站時，我們會在開發服務器上開發網站，然後發佈或推廣網頁和文件到生產服務器。這似乎是一種很好的方式，因此用戶不會看到亂七八糟的網頁或（上帝禁止）服務器崩潰，因爲我們中的一個人搞砸了。

但是，當他們創建SharePoint時，似乎微軟並沒有考慮到這個想法......至少，我無法找到一種方法在基礎架構中對其進行定義。

有誰知道是否有SharePoint開發的管理策略？我在線閱讀過，我們可以對開發環境進行備份並恢復到生產服務器。這可能是第一次，但生產服務器的任何更新都無法做到這一點，而不會冒生產服務器上的數據丟失的風險。我已經看到了一些工具，用於將列表內容，頁面和文檔從一臺服務器遷移到另一臺服務器 - 雖然，我承認，我還沒有調查過它們。

但是，我的另一個問題是自定義內容類型。似乎一旦列表正在使用內容類型，就不能在不從列表中刪除項目，解除內容類型關聯以及重新分配內容類型的情況下對其進行更新。不應該有某種方法來升級內容類型嗎？

無論如何，如果您對這些目前的困境有任何建議，我很樂意聽取您的意見。

由於提前，

丹

---

謝謝你的快速回復。

我們已經爲我們的網站創建了幾項功能，針對基礎（內容類型，列等）的解決方案包捆綁功能以及與品牌（頁面佈局，主頁面等）功能相關的另一個解決方案）

但是看起來這是一次性的......基本上，它讓我們的服務器設置好了，對吧？一旦人們開始使用生產環境，我們將擁有內容數據庫中的所有文檔，頁面和列表項，並且無法更新內容類型，列等內容。

在安裝和激活新功能之前，必須停用和卸載的功能，對不對？我已經在功能定義上看到了一個Version屬性，但就我所知，這並沒有做任何事情。解決方案似乎可以通過增加版本號來升級，但似乎並未修改內容類型和列等內容，特別是在正在使用的情況下。另外，我不確定解決方案的升級有多廣泛。

這裏有些珍貴的文檔。看起來我正在閱讀的所有內容都是如何最初設置SharePoint服務器......而不是長期管理它。

你有什麼意見或建議嗎？

---

謝謝大家的建議。

但是我們一直在這個網站上工作了一年多。我非常有信心，我們已經根據大多數人的建議進行了設置。我們已經有幾個功能來安裝內容類型，列，主頁面，頁面佈局和工作流程等內容。這些功能大部分都包含在解決方案包中。我們將所有開發環境都設置爲VPC服務器。

所以，我已經初步部署了很多設置。我真正希望瞭解的是我可以如何升級內容類型和專欄等東西。一旦它們被使用，是否可以更改內容類型？因爲根據我最初的測試，似乎沒有這種可能。我不擔心這些程序集，因爲它看起來好像換成了很好，但我更新內容類型的唯一方法是刪除引用它們的所有項目（即我的頁面庫中的所有頁面），刪除內容類型，然後重新添加它。

是否有人知道是否有方法在初始部署之後更新內容類型？ ...當用戶已經根據我們已經部署的內容類型創建了項目時？

（我的問題的另一部分是實際移動從開發服務器到生產存在的頁面，但我生活中可以沒有這一點。我主要擔心的是內容類型。）

Answer 1

去是發展的最佳途徑具有功能。一旦這些功能完成，您可以使用解決方案包（稱爲WSP）部署它們。

剩下的唯一要做的就是重新激活這些功能。這樣，您可以逐步推出新功能，而無需在生產中完成所有任務。

WSPBuilder是幫助您構建WSP的應用程序。

爲了實現所有這一切...祝你好運。涉及很多工作。

更新： 部署內容類型和列很棘手。網站創建完成後，您無法通過功能更新它們。您需要檢查代碼並遞歸遍歷所有網站並修改與該名稱匹配的特定內容類型。

我們已經嘗試過，通常不能使用這些功能來做到這一點。這需要通過我稱之爲「用代碼部署」的東西。

Answer 2

我建議考慮看看克里斯O'Briens的最新訊息，和他的偉大的內容部署嚮導：it's not all about Features!

Answer 3

馬克西姆是正確的，應通過被包裹在解決方案的功能進行部署，大多數項目（WSP文件）。你的策略應該是確保你的解決方案和程序集被分解成相關的功能。這也是有益的，因爲這些功能可以在網站和網站等特定級別上隔離。更新任何內容更新時，應使用功能激活碼，停用碼和功能裝訂。內容部署也是有意義的。

一旦要記住的是，如果更新僅在代碼中，那麼可以更新程序集而無需重新激活功能或解決方案收回並重新部署。所有需要的是應用程序池被重置。

微軟在開發環境上有幾篇文章，你可以Google推薦環境的其他人。我們在虛擬機上進行開發，並將大部分項目部署到虛擬集成服務器。一旦我們抽菸測試，我們就會將解決方案部署到QA等等。我的功能和解決方案的好處很容易收回。一旦它投入生產，它應該經過徹底的測試。

在SharePoint中開發有它的問題，不言而喻，但到目前爲止我發現好處超出了問題。

Team-Based Development in Microsoft Office SharePoint Server 2007

Answer 4

你真的需要使用的功能，因爲這樣每個內容類型都會有一組GUID，並使用相同的名稱被存儲在數據庫中定義的內容類型。當在網站上運行CAML查詢時，這變得很重要，並且如果內容類型被創建的話，還會有其他一些小問題。

我喜歡STSDev的推出使用自定義內容類型的解決方案。

有編輯服務器上的網頁兩種方式。您可以將頁面庫定義爲主版本和次版本。這允許編輯編輯頁面和定義的發佈者來發布它們。這在內部網站上很好，但不建議在面向公衆的網站上使用。

對於面向公衆的網站，你將需要使用Content Deployment

我不能強調不夠，以前有產能釋放走在前面，你要確保你有對內容類型的功能。

如這裏所提到的，Chris O'Brian有一個帖子說，你不應該使用的功能，除非必要。他的一個原因是它減緩了發展。

我不同意這一點。開發是如果您不熟悉功能會變慢，但一旦達到知識水平，這不是主要因素。

不要聽他關於備份和恢復移動內容的方法。 如果你這樣做了，那麼在開發過程中可能創建的所有內容類型，字段和網頁（對於我來說總是相當多的）都會變成你的製作網站。

相反有一個乾淨的網站，在這裏一切都是一致的，你將最終小蟲子和站點不同的行爲給別人只是因爲舊的發展克魯夫特的一些區域。

Answer 5

我們開發了將更新內容類型和領域的網站集的定製解決方案。在封面下方，通過代碼，SharePoint允許我們修改字段以及字段和網站/列表內容類型中的值。

對於將實際內容從QA移動到Prod，我們使用Echo