TFS：这可能吗？
我们有 3 个环境：开发、测试和登台。
我想签入和签出 TFS。当我们进行更改时，我想将代码提升到开发 Web 服务器。接下来，我想将更改推广到测试，然后推广到登台。使用 Team Foundation Server 可以做到这一点吗？
We have 3 environments: dev, test, and staging.
I want to check in and out of TFS. When we make changes, I want to promote the code to the dev web server. Next I want to promote the changes to test, then to staging. Would it be possible to do this with Team Foundation Server?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
人们到底为什么建议分支？您可以针对不同的功能进行分支，或者针对发布快照进行静态分支。
当然，这些环境之间的差异在于配置项/文件以及其中的设置。您所需要做的就是让您的部署和发布管理流程井然有序。
创建适当的 MSBuild 任务并使用 TFSBuild（持续集成）调用这些任务，以负责为您正在构建的环境/配置输出正确的配置文件。您可以轻松添加另一个 MSBuild 目标，用于处理相应目标环境的适当部署。
Why on earth are people suggesting branching? You branch for different features or static branches for release snapshots.
Surely the differences between these environments are configuration items/files and settings within these. All you need to do is get your deployment and release management process in order.
Create appropriate MSBuild tasks and use TFSBuild (Continuous Integration) to call these to take care of outputting the correct config files for the Environment/Configuration you are building. You can trivially add another MSBuild target that deals with the appropriate deployment to the respective target environments.
您可以手动签出每个分支的代码，随后对每个分支进行更改，然后签入。 非常小心。
更好是让这 3 个环境成为彼此的分支。 （通常从 dev 开始，然后依次分支到其他 2 个）。然后，您可以使用合并功能将（例如）您的开发变更集直接合并到测试等。此时，您的测试模块（需要更改以匹配开发）已被签出，的变化。然后只需提交更改即可。然后重复分级和冲洗。这是针对这种常见场景的建议方法。
两个重要注意事项：
建造是一个单独的动作。您需要为每种情况设置一个单独的构建，当然，一旦您设置了第一个，其他两个将变得微不足道。合并到staging后，您将运行staging构建。 （从团队资源管理器或“构建”菜单中）。 TFS 有点重，但一旦设置好，它确实可以很好地处理这种情况，便于分布式团队快速合并和构建（通过自动构建测试等）。
You can manually checkout the code from each branch, make your changes subsequently to each branch, and checkin. Very carefully.
Much better is to have these 3 environments be branches of each other. (Typically you start with dev, and branch to the other 2 in turn). Then you can use the Merge functionality to merge (for example) your dev changesets directly to test, etc. At this point your Test modules (that need to be changed to match dev) are checked out, with the changes. Then simply commit the changes. Then repeat for staging and rinse. This is the suggested methodology for this common scenerio.
Two important notes:
Building is a separate action. You need to set up a separate build for each situation, though of course once you set up the first one the other two will be trivial. After your merge to staging, you'll then run the staging build. (From Team Explorer or in the Build menu). TFS is a bit heavy but once it is set up it does handle this situation very well, easy for a distributed team to merge and build quickly (with automated build tests, etc.).
是的，这是可能的，但您必须手动将它们从一个分支签入到另一个分支。
Yes, this is possible, but you must manually check them in from one branch to another.