簡體   English   中英

使用多分支和解決方案的TFS構建定義和發布管理最佳實踐

[英]TFS Build Definitions and release management best practice with mutliple branches and solutions

我當前正在使用Team Foundation Server 2015(更新2),並且想要使用新的構建定義和版本管理,並且想知道在使用多個分支時創建構建定義的最佳實踐是什么。

我們有多個分支機構,每個分支機構中也會有多個解決方案(在本例中,我將它們稱為WinApp.sln,WebApp.sln和MobileApp.sln)。

我們的項目分支類似於以下內容...

Project
    Dev
        Main    *** This is our development branch for new features
        Updates
            1.2 *** This branch is used for any bug fixes for version 1.2
    Main
    Releases
        1.1
        1.2     *** Current release branch that will be deployed to customers

最好在TFS 2015中使用新的構建定義為每個分支或每個分支中的每個應用程序創建一個新的構建定義。

例如,我創建以下構建定義:

AppName.Dev.WinApp
AppName.Dev.WebApp
AppName.Dev.MobileApp
AppName.Updates.1.2.WinApp
AppName.Updates.1.2.WebApp
AppName.Updates.1.2.MobileApp
AppName.Release.1.2.WinApp
AppName.Release.1.2.WebApp
AppName.Release.1.2.MobileApp

然后,通過具有如下所示的發布定義,該信息將流向發布管理:

AppName.Dev         
AppName.Updates.1.2
AppName.Release.1.2

每個發行版定義都會為3個解決方案版本中的每一個添加工件。

還是每個分支只有一個構建定義會更好?

知道其他人在類似情況下正在做的事情會很有趣。

在以前的基於xaml的構建中,我們有多個構建定義,因為每當發布新的構建模板時,我們都不希望舊版本的構建定義受到影響,因此我們維護了多個構建定義。 我們還維護了該版本的版本。

但是,有了新的vNext構建,一旦我們增強了任務並將其上傳到TFS,我們就無法使用以前版本的任務,所有構建定義都開始使用最新的任務,並且沒有辦法(而不是重命名任務),以便我們可以選擇較舊版本的任務。 因此,我認為維護多個構建定義是沒有用的,因為如果更新任務,則構建定義將被更新。

在某些情況下,我們需要維護特定發行版的版本,並且如果數量取決於所觸發的內部版本,在這種情況下,我們將擁有不同的內部版本定義,因為我們的補丁程序無法具有最新的版本號。

保持不同的構建定義的另一個原因是擺脫了記住以前在特定版本中使用了哪些任務的麻煩。

因此,總而言之,我將使用不同的構建定義,以避免版本混亂,並保持發布構建定義的完整性。

在發布時,我們將構建定義綁定到發布定義。 因此,再次要進行平滑的錯誤修復和更新,必須為每個構建定義提供不同的發行版定義。

暫無
暫無

聲明:本站的技術帖子網頁,遵循CC BY-SA 4.0協議,如果您需要轉載,請注明本站網址或者原文地址。任何問題請咨詢:yoyou2525@163.com.

 
粵ICP備18138465號  © 2020-2024 STACKOOM.COM