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，我们就无法使用以前版本的任务。所有构建定义都使用最新任务开始，并且没有办法（除了重命名任务）我们可以通过它选择旧版本的任务。因此，我认为维护多个构建定义没有用，因为如果更新任务，构建定义将会更新。

有一种情况我们需要维护特定版本的版本，如果数量取决于触发的版本，那么我们将有不同的构建定义，因为我们的补丁不能具有最新的版本号

维护不同构建定义的另一个原因是为了避免忘记以前在特定版本中使用了哪些任务。

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

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

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

1 个答案: