使用持續整合/版本控制進行軟體開發
任何軟體專案的最初階段都是規劃階段。在這個階段，參與專案的人員會開會並討論一些非常高階的需求。可能有一些簡報和文件被建立。專案管理計劃尚未制定，但應該考慮。正如我之前所說，我們在這個階段開始建立我們的工作說明（我們 SOP 的應用）。
專案的“設計歷史檔案”（DHF）必須包含所有進入專案的歷史“內容”，因此即使在如此早的階段，也必須決定版本控制系統並建立儲存庫。當然，可能還沒有涉及到跟蹤，但這些早期的“內容”仍然應該儲存在 DHF 中。因為軟體專案的最初階段會產生要包含在 DHF 中的輸出，所以有必要儘早確定版本控制工具並建立版本控制儲存庫（為了本文的目的，我假設對版本控制/修訂控制系統有基本瞭解）。
跟蹤至關重要，而 Subversion 憑藉其變更集非常適合與專案中使用的其他工具整合。當與您的問題跟蹤軟體一起使用時，每個問題都可以直接連結到儲存庫中與解決該問題相關的專案。只需單擊滑鼠，我們就可以看到與單個問題相關的專案檔案修改列表。
我建議對進入專案的“所有內容”使用單個版本控制系統和儲存庫（當然，使用每個專案一個儲存庫的方法也有很多好處）。這意味著專案管理計劃、文件、簡報、程式碼、測試資料和結果都應該進入同一個儲存庫，並且儲存庫本身的佈局應該是每個專案都有自己的主幹、標籤和分支。如果文件儲存在單獨的儲存庫中（或完全不同的版本控制系統中），而軟體程式碼儲存在另一個儲存庫中，我們會失去很多本來可以擁有的專案可追溯性。
（注意：當將二進位制檔案放在版本控制系統中時，與文字檔案原始碼相比，沒有合併路徑。這意味著團隊成員在編輯文件時，最好[需要引用]在編輯時對檔案進行嚴格鎖定。這可以在 Subversion 中完成。[1] 嚴格的檔案鎖定可以讓其他人知道另一個使用者正在編輯某個檔案。）
雖然這種方法的一個明顯的優勢是專案中的“所有內容”都與同一個儲存庫相關聯，但有些人可能認為這種設定有問題。我建議這種設定僅僅是因為我特別考慮的是 FDA 監管的軟體產品，在這種產品中，將專案的各個元素關聯在一個可追溯的儲存庫中是有益的。在這種設定中，文件將與專案原始碼一起版本化（並標記），這可能取決於專案的需要，也可能不值得這樣做。
Subversion 比其許多前輩更優越，因為它（除其他外）引入了“變更集”。變更集提供了整個專案儲存庫的某個時間點的快照。當文件、簡報或原始碼發生更改並提交到儲存庫時，會建立一個新的變更集編號。現在，在將來的任何時候，我們都可以簽出儲存庫樹中截至該變更集的所有專案。當被問及產品的某個內容是在哪個版本中更改時，我們可以提取該更改時與專案相關的所有內容。我們不再需要標記或標記我們的儲存庫來重新訪問某個特定時間點（儘管 Subversion 仍然允許標記）。對儲存庫的每一次提交實際上都會產生一個“標記”。
但這並不意味著標記不再有用。相反，它仍然非常有用。所有軟體版本（包括內部版本）都應該被標記（而且我們的工作說明應該告訴我們何時以及如何執行標記）。
Subversion 的另一個優勢是，與它的一些前輩不同，它允許控制和記錄目錄以及檔案的歷史記錄（包括檔案和目錄名稱更改）。Subversion 最常用的前輩 CVS 不會維護檔案或目錄重新命名的版本歷史記錄。Subversion 可以處理任何版本控制物件的重新命名。