查询 Team Foundation 服务器中的测试文件、分支和文件夹结构

发布于 2024-12-07 11:03:45 字数 301 浏览 1 评论 0原文

最近我正在着手一个新项目。这一次让我尝试让我的 tfs 结构更加坚固，对我最近的版本进行一些改进。所以这是

分支发布

主干

bin
docs
src
  sln.file
   project1
   project2

tests
  sln.file
   project1.test
   project2.test

，因为测试项目不会分支，这是有道理的。但是我在考虑将测试项目保留在同一个 sln 中是否更好。尽管这是我的偏好，但我如何才能在工作开发解决方案中引用它们。

原文

recently i was embarking on new project. it is giving me this time try to make my tfs structure more solid put some betterment on my recent version. so here it s

branch
release

trunk

bin
docs
src
  sln.file
   project1
   project2

tests
  sln.file
   project1.test
   project2.test

since test projects will not be branched this make sense. however I was contemplating is it better to keep test projects within same sln. though it s my preference how can than I refer to them withing working dev solution.

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

天荒地未老 2024-12-14 11:03:45

http://tfsbranchingguideiii.codeplex.com/
另外，我不知道你所说的“测试项目”是什么，但是如果它们在你的主代码更改时发生更改，那么它们应该与你的主代码一起分支。

下面简单介绍一下我最近如何搭建一个小应用程序。我还没有移动更大的应用程序，所以还没有处理诸如公共代码库之类的事情。

$/TeamProject
    /Development (folder)
        /Development (branch)
            /Lib
            /Src
               etc.
    /Main (branch)
        /Lib [third party binaries and other artifacts]
        /Src
            /Solution1
                Solution1.sln
                WebApplication
                    WebApplication.csproj
                    etc.
                WcfServices
                    WcfServices.csproj
                    etc.
                DAL
                    DAL.csproj
                UnitTests
                    UnitTests.csproj
            /Solution2 (same pattern as Solution1)
    /Release (folder)
        /Release (branch)
            /Lib
            /Src
               etc.

我为开发分支设置了 CI 构建，构建“Dev”配置。我们将其部署到我们的集成环境中。
我为我们的主分支设置了夜间构建，构建“测试”配置。当 QA 想要测试新版本时，他们会将最新版本部署到 QA 环境中。
我为发布分支设置了手动构建，构建“Prod”配置。当我们准备好迁移到生产环境时，QA 首先在他们的环境中测试部署过程（一旦我们获得环境，将成为临时环境），然后运营人员将其部署到生产环境。

http://tfsbranchingguideiii.codeplex.com/
Also, I don't know what you call the "test projects", but if they change when your main code changes, then they should be branched with your main code.

Here's a brief description of how I set up a small application recently. I have not yet moved larger larger applications, so haven't yet dealt with things like libraries of common code.

$/TeamProject
    /Development (folder)
        /Development (branch)
            /Lib
            /Src
               etc.
    /Main (branch)
        /Lib [third party binaries and other artifacts]
        /Src
            /Solution1
                Solution1.sln
                WebApplication
                    WebApplication.csproj
                    etc.
                WcfServices
                    WcfServices.csproj
                    etc.
                DAL
                    DAL.csproj
                UnitTests
                    UnitTests.csproj
            /Solution2 (same pattern as Solution1)
    /Release (folder)
        /Release (branch)
            /Lib
            /Src
               etc.

I have a CI build set up for the Development branch, building the "Dev" configuration. We deploy it to our Integration environment.
I have the nightly build set up for our Main branch, building the "Test" configuration. When QA wants to test a new build, they deploy the latest of these to the QA environment.
I have a manual build set up for the Release branch, building the "Prod" configuration. When we're ready to migrate to production, QA first tests the deployment process in their environment (will be a staging environment once we get one), and then Operations deploys this to the Production environment.

回复收藏 0 原文

~没有更多了~