SVN網頁開發週期問題

Question

我目前工作的組織使用SVN開發PHP應用程序。我們的開發週期開始很簡單，做一個提交使用post-commit鉤子來更新web根目錄，以便立即查看更改。比起我們遇到的一個問題，開發特性阻礙了錯誤修復，並阻止了固定文件被​​移動到生產環境，並且有時會導致prod服務器出現問題。

所以我介紹了一個「釋放分支」架構，這意味着所有的全版本都複製到自己的分公司，所以在這個分支與「長期」的發展發生生產所需的所有變化發生於軀幹。第一次啓動的想法是隻做修復並讓開發人員負責將自己的更新移回到主幹，但是在開發人員盲目合併導致數據丟失的更改以及持續開發「即時發佈項目」之後發佈分支這種方法被放棄了。

知道我面臨的是一個不同步的分支（因爲有些人沒有「獲得」幹線/分支的概念，並且正在幹線上開發），其中的變化合併到來自私人分支的幹線中，合併來自當前版本分支的過去一個月的所有更改時可能會丟失更多代碼。

我不得不重新開始和執行Web開發的適當開發/發行週期的機會。 SVN似乎是面向「發佈」開發（二進制應用程序），在這種情況下，我們可以整整一年不移動完整的軟件包到生產環境。

有了這樣的背景，這裏是我的問題：什麼 Web開發SVN週期和/或模式你會推薦這種情況呢？ 這是否需要一個完整的方法學改革，或者我只是缺少一些簡單的東西？

感謝您的任何想法！

Answer 1

這是我們典型的開發週期;我們是「虛假敏捷」;並運行2周的發佈週期。

所有項目都從樹幹的分支開始。沒有例外。

一旦項目完成並清除代碼審查，開發人員將被指示將該分支合併到主幹中。那樣;沒有經過徹底審查的代碼無法進入主幹。我們使用CruiseControl進行持續集成，因此在提交到主幹後，如果有任何測試失敗，則開發人員負責修復它們。這些修復程序放在主幹上。

一個星期前的下一個版本;我們創建一個發佈「標籤」（本質上是另一個分支）並將其發送給QA。如果你現在還沒有將你的代碼重新合併到主幹中，那麼下一版本就不會出現這個問題。 （重要提示：這個版本的「標籤」永遠不會合並回主幹。）由於QA發現錯誤，他們被分配回開發者。當開發人員修復它們時;他們的更改必須同時發佈到發佈標籤和中繼。

當發佈日到來時;我們在該標籤上發佈所有內容。在發佈修補程序的情況下;我們遵循與我們進入質量保證週期相同的準則，這樣，如果有人在釋放標籤被切斷後將新項目合併到主幹中，它不會在緊急修復中被無意中釋放。

泡沫，漂洗，重複...

這可能不是回答你的問題本身;但希望這可以作爲您如何設置開發流程的良好外部觀點。這不是我們原來的過程，而是我們在過去一兩年提出的，而且根據我的經驗，這是前所未有的突破。

如果您想對此做任何澄清，只是留下評論，我會根據需要進行更新。

Answer 2

這總是很困難的，無論您使用的系統。我懷疑有比以前使用的解決方案更好的解決方案。也許花更多的時間教育你的同事這個​​概念？

Answer 3

我備份巴特在此;問題在於培訓。在項目過於複雜而無法管理之前，您需要讓您的同事正確使用SVN。你的分支計劃聽起來對你的描述沒有問題，但確實有一個人不遵循這個計劃會讓其他人分手。

再次，現在就開始做吧，然後再讓您的項目變得更加複雜。

Answer 4

我不知道你是否已經在使用這些，但我強烈建議開發分支機構。每個新功能/錯誤都有自己的分支，它從主幹（或分支）複製而出，最終被合併回去。該功能的所有開發和簽入都發生在devel分支上。一旦功能/ bug修復完成後，trunk被合併到開發分支FIRST中，然後在執行了基本測試和驗證（標準測試臺？）之後，開發分支可以合併到主幹中，並且知道所有東西都應該是在那裏。

關鍵是將樹幹合併到devel分支中，以拾取任何新的樹幹更改，然後在返回合併到樹幹之前測試devel分支。如果每個變化都有自己的分支，那麼開發人員就會很快地擺脫事物的擺動。

和其他人已經提到的那樣，教職員工的教育。對於工作人員的教育沒有例外情況，每個變更都有自己的分支也不例外。 SVN中的副本既便宜又容易，所以沒有真正的例外借口。

Answer 5

業務的第一步將是教育您的員工瞭解SVN的工作方式及其背後的方法。無論你制定計劃有多優雅，如果他們不能遵循，他們也不會。

我自己在「特色」分支中做所有事情。我的佈局是這樣的：

branches/ 
    [feature branches] 
    stable/ 
tags/ 
    [all of our releases] 
trunk/ 

凡是倒是多了幾個文件，或重大的工作，在一個特性分支得到執行。小錯誤修復或快速工作直接在主幹中完成。在整個開發過程中，分行都與行李箱保持同步（行李箱每隔幾天合併到分行）。

當發佈時間到來時，我們會將所有要發佈的功能集成到主幹中。一個功能分支被合併，檢查，如果好，則移入穩定分支。清洗，沖洗，重複所有功能分支。

一旦穩定完成，它將被標記爲發佈版本，我們的構建系統現在可以基於新標記構建生產。

如果我們需要進行直接投入生產的緊急修復，標籤將被檢出，更正並生成補丁。該補丁應用於樹幹，然後饋送到Stable和任何新的功能分支。