使用多分支和解决方案的TFS构建定义和发布管理最佳实践

Question

我当前正在使用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个解决方案版本中的每一个添加工件。

还是每个分支只有一个构建定义会更好？

知道其他人在类似情况下正在做的事情会很有趣。

Answer 1

在以前的基于xaml的构建中，我们有多个构建定义，因为每当发布新的构建模板时，我们都不希望旧版本的构建定义受到影响，因此我们维护了多个构建定义。 我们还维护了该版本的版本。

但是，有了新的vNext构建，一旦我们增强了任务并将其上传到TFS，我们就无法使用以前版本的任务，所有构建定义都开始使用最新的任务，并且没有办法（而不是重命名任务），以便我们可以选择较旧版本的任务。 因此，我认为维护多个构建定义是没有用的，因为如果更新任务，则构建定义将被更新。

在某些情况下，我们需要维护特定发行版的版本，并且如果数量取决于所触发的内部版本，在这种情况下，我们将拥有不同的内部版本定义，因为我们的补丁程序无法具有最新的版本号。

保持不同的构建定义的另一个原因是摆脱了记住以前在特定版本中使用了哪些任务的麻烦。

因此，总而言之，我将使用不同的构建定义，以避免版本混乱，并保持发布构建定义的完整性。

在发布时，我们将构建定义绑定到发布定义。 因此，再次要进行平滑的错误修复和更新，必须为每个构建定义提供不同的发行版定义。