使用版本控制工作流程的Web開發

Question

Brief：
我在一個2人團隊中工作（我們可能會在未來擴展）。
我們有一個web-dev服務器，我們有一個生產服務器。
目前，當我們開始開發時，我們在localhost上啓動它們，然後將它們部署到web-dev（我們可以通過安裝的驅動器訪問它），並將這個「共享」驅動器的更改提交給SVN。在web-dev上進行最終測試，從頂端獲得批准，然後通過FTP到我們的生產服務器。
（我可以聽到私刑來了......）
是的，我知道這是從一個位置共享文件並從那裏提交它都是錯誤的，但是當我得到時，這並不是一個壞主意知道SVN。現在我想改變它。

所以，我知道版本控制的基礎知識，它現在的工作方式現在是錯誤的大時間。我已經通過維基百科和一些svn頁面，但我找不到一個完美的解決方案應該如何實際工作。

難道你們有些經驗豐富的人會建議這應該如何工作嗎？

事情我已經找到了：

• 我們應該在本地副本上工作，我們的機器
• 那麼我們更改提交SVN。

事情，我想知道：

• 我們怎樣才能SVN後，web開發更新承諾？
• 如何將補丁部署到生產服務器？ FTP文件？這是你做的嗎？或其他一些聰明的解決方案？
• 其他任何我應該瞭解的web-dev工作流程。

Answer 1

Subversion有post commit hooks它允許您對提交執行操作。

你也可以看看像CruiseControl.net或Team City這樣的持續集成解決方案。

我們的過程是單個開發人員在本地配置上工作。我們承諾Subversion，CruiseControl.net會在我們每次提交時檢查並構建系統。

有一個更新安裝程序的計劃構建，每週運行一次，並更新QA用於驗證修補程序的服務器上的安裝。一旦修復程序得到驗證，某人（手動）將應用於生產站點上的QA服務器的更新應用到該服務器上。

Answer 2

我已經成功地使用如下

• 而是顛覆，使用分佈式版本控制系統，如水銀或Git的
• 所有的開發模型有他們承諾在當地的本地存儲庫部署期間
• 還有一個額外的測試存儲庫，所有開發人員在完成之後將其更改推送到該存儲庫。這是由QA檢查並測試
• 如果所有的測試庫是很好，這是標記，然後推到生產庫

Answer 3

我建議在看後提交掛鉤，像nickd建議。你甚至可以拒絕一個提交，如果它沒有建立（比如說你從一些'源'文件生成HTML文件，並且如果這個生成失敗，你可以指望這個人在提交之前修復它）。

• 我們如何在SVN提交後讓web-dev更新？
• 如何將補丁部署到生產服務器？

，既可以自動通過掛鉤，也可以考慮在生產機器手動「SVN更新」，它給你的時候，如此反覆考慮使用哪個版本和控制。

SVN book是很好的閱讀。人們只能閱讀相關章節，稍後再回來閱讀更多內容。您是否使用了幹線和標籤 - 它們是用於svn使用和釋放控制的麪包和黃油。

Answer 4

這就是我已經做了幾年了。

開發服務器 - 位於內部，包含LAMP堆棧，存儲庫和一個工作副本。它具有與生產服務器相同的軟件版本。

生產服務器 - 具有工作副本repo的分段環境，還具有非svn版本的項目（即活動站點）的生產環境。

開發人員 - 在本地計算機上存儲LAMP堆棧和存儲庫的工作副本。

典型流程：

開發人員更新項目的工作副本。在本地副本上工作，當完成當前更改並且無缺陷時，他們將複製回存儲庫。

Post-commit掛鉤更新Dev Server的工作副本。您可能想要手動執行此操作，特別是如果您的團隊開始增長。

如果在Dev Server上進行更改，則手動更新暫存環境上的工作副本。

如果更改在暫存環境中運行，那麼我們使用RSYNC將暫存環境的工作副本中的任何更改推送到生產環境。

很顯然，這是一個非常普遍的解釋，因爲你需要將諸如單元測試之類的東西集成到流程中，但我希望這有助於。

Answer 5

我們這樣做的方式非常簡單，作爲一個小團隊，您可能會涉及。

• 開發在本地主機上完成，並提交到中繼線的一個分支。
• 對於QA，該分支合併到主幹，和開發環境（這是軀幹的複印件）只是做一個svn up
• 如果一切QA好，我在現場環境做一個svn up（這是也是一個主幹的副本），我完成了。

我還沒有做到這一點，但是這個過程可以通過添加一個post-commit鉤子來自動更新開發環境來簡化（正如其他人所建議的那樣）。