2010-02-25 60 views
3

我在開發/支持的經典ASP應用程序上使用SVN進行源代碼管理。我按照我公司的要求維護幾個版本的應用程序:Web應用程序的版本控制 - 如何處理修訂版本和上線時間表?

  • 發現/遊樂場版本 - 我在哪裏做所有的工作。我的工作拷貝
  • 開發/測試版本(這些網站/服務器無法訪問)
  • 真人版(沒有訪問到這些網站/服務器)

下面是當我遇到麻煩:

  1. 工作是在項目A完成並致力於
  2. 項目A晉升爲開發/測試使用導出從日誌
  3. 沒有與項目A的一個問題,這是失速ED在開發/測試
  4. 項目B走來,準備並提交
  5. 項目B現在建立在項目A,但也有項目A的部分不是黃金時間做好準備

短的只是「小心不要把任何東西搞砸,「有什麼我可以做的,以確保部分項目可以在開發過程中停頓而不阻礙一切?

在這個過程中的Web服務器的必要性似乎導致我的問題。我知道我可以在項目A進行開發/測試時將其分支,然後在活動時將它合併回主幹。同樣,我可以在分支之前恢復我的操場,並且在項目B沒有任何事情的情況下從項目A有意無意地進行實況轉播。但是,我不能在我的遊樂場上玩A項目。我必須爲每個分支產生一個新的遊樂場嗎?

我知道這可能對我的情況有太多的限制,但我希望其他人也經歷過類似於我的情況的東西。

謝謝!

編輯:

這是我目前的解決方案:維護修正 - 改變一個能夠立即投入生產 - 在WC得到製成,致力於樹幹。任何依賴項目的東西都會分支。沿測試路徑的工作副本可以切換爲指向該分支以測試項目。分支必須保持最新,我們可以使用提交掛鉤來保持通知。當一個分支準備好部署到生產環境中時,它將被合併回主幹並進行部署。

這是有道理的,會工作,對吧?

+0

生產中存在多少份「Live版本」?一?超過一個? – braveterry

+0

這聽起來像你可能需要一個操場網站每個分支。如果切割新分支太昂貴(無論是在VCS級別還是在設置操場地點方面),這本質上是一個論點,您(團體)應該考慮更改您的設置,使其變得更便宜 - 儘管我很欣賞這可能很難... – crazyscot

+0

@braveterry - 在負載平衡的服務器上生成2個項目的副本。 @crazyscot - 在我之前輸入它之前,我沒有真正想過每次分支時創建一個新站點。但它可能是有道理的。 謝謝! –

回答

1

我們用SVN的一個實例來控制我們的代碼庫,並使用另一個來控制每個測試階段和最終生產的Web服務器的環境和內容。擁有每種環境的歷史已經爲我們節省了很多次。保持你的日誌消息有意義,一定會回報。

我從發送到我們開發服務器的自動構建版本導出到系統測試文件的檢出版本上,然後對其進行修改。更新Web場中的服務器只是更新所有框上的HEAD版本的情況。使用系統測試中的導出更新分段,然後生產從分段導出中最終更新。有些部分是腳本化的,但手動監督很方便。可能最難的一點是確保配置文件對於每個環境都是正確的,但如果不改變它,則不會部署它。

您可能仍然想要掌握功能分支或發佈分支以及必要的strategies以重新組合源代碼。無論您的測試策略有多好,您都可能需要對生產中的某些東西進行bug修復。

有一點需要注意的是,1.5x SVN服務器沒有使用客戶端版本1.6x,因爲這與我們的合併進程一起玩havok,直到我們升級爲止; http://ferventcoder.com/archive/2009/06/10/subversion-1.6-tree-conflicts-and-the-incompatibility-of-subversion-1.5.aspx

編輯:

在我們的部署環境中的每個服務器上安裝了TortoiseSVN的客戶端,以便系統管理員有更新簽出庫的GUI。

我也讓他們一些腳本使用SVN命令行實用程序來更新服務器上的一些存儲庫與自動作業。這允許我們的內容團隊將文件提交到服務器資源文件夾的本地副本,然後每隔一小時更新一次。他們只能訪問我們用SVN服務器上的auth文件控制的特定文件夾集。

我們有兩臺獨立的機器,它們實際上已經安裝了每日備份的SVN服務器。一個用於源代碼的存儲庫,另一個用於在每個環境中部署的最終構建。這確實意味着我們在每個環境中都有一個完整的重複存儲庫,但存儲不是問題。

+0

所以暫存和生產沒有安裝SVN,對吧?我曾想過使用這種方法,但即使如此,我的公司也會採取一些行動。現在,我提交我的代碼,導出已更改的文件,然後將它們壓縮並交給系統管理員以安裝在每個環境中。感謝您的寶貴意見! –

+0

是的,看看我上面的修改。 –

+0

謝謝戴夫!查看我對我的問題的編輯...我已經考慮了更多,並有一個我想要反饋的潛在解決方案。 –

相關問題