使用 TeamCity 设置构建流程
我开始在我的团队中实施 CI，我选择了 TeamCity，因为它对于小型团队来说是免费的，而且它现在看起来也很流行，并且有很多不错的选择。
我尚未确定该服务器的“典型”或最佳用例是什么。
在我看来，绝大多数构建任务都可以使用其他工具更好地执行（让它在像 MSBuild/NANT 这样的构建脚本中），而 TC 仅用于发出单元测试/构建触发器。
我发现很难建立完整的构建过程（复制文件/调用更复杂和基于逻辑的代码等）。
将 TC 设置到构建过程中的最佳方案是什么？
我们的产品是一个基于 C# 的软件，带有各种“插件”。
我们正在构建 3 个大型 .sln 文件，当前使用 MSBuild 运行程序（只需指定 .sln 文件作为该运行程序的参数）。
这仅负责构建实际的二进制文件，但对于需要将各种项目的输出组合在一起的事情来说还不够，例如创建安装程序。
I am starting to implement CI in my team, and i picked up TeamCity, since it is free for small time teams, and it also seems pretty popular nowadays and features many good options.
I have yet to determine what is the "typical" or best use case for this server.
It seems to me that the vast majority of build tasks are better performed using some other tool (let it be in some build script like MSBuild/NANT) and TC is used only for issuing unit tests/build trigger.
I find it hard to set up a full build process (copying files around/invoking more complex and logic based code, etc).
What is a good scenario for setting up TC into the build process?
Our product is a C# based software with various "plugins".
We're building 3 large .sln files, currently using the MSBuild runner (simply specifying the .sln file as argument to this runner).
This only takes care of building the actual binaries, but is not enough for things that need to combine various projects' outputs together, for example for creating an installer.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我能给出的最好答案是描述我们的团队城市流程。我无法告诉您什么最适合您。我也无法告诉您什么是典型的，因为仅在我的公司中，我们就有大约 8 种使用 teamcity 的方法。
在我们的 .NET 项目中（自从您提到 MSBuild/NAnt 以来，这似乎是您关注的焦点），我们使用多个构建步骤进行构建。一个使用 teamcity 的解决方案运行程序进行编译，下一个使用其 nunit 测试运行程序，最后一个使用 msbuild 来复制文件。
我们有另一个 .NET 构建，它遵循类似的模式，但添加了一些调用用 python 编写的自定义工具的步骤。
我们有一些仅执行 NAnt 运行程序的 java 构建。
做最适合你和你当前环境的事情。忍受一段时间，然后看看你想改变什么。
如果您已经有一个好的 msbuild 或 nant 脚本，只需将 teamcity 指向该脚本并使用它来触发即可。
我喜欢使用 teamcity 的解决方案运行程序，因为它确实有效。与他们的测试运行者相同。但 MSBuild/NAnt 确实非常适合文件模式工作。
希望有帮助。
The best answer I can give is to describe our team city process. I can't tell you what will work best for you. I also can't tell you what is typical because in my firm alone we have about 8 ways of using teamcity.
On our .NET projects (that seems to be your focus since you mention MSBuild/NAnt) we have builds with multiple build steps. One uses teamcity's solution runner to compile, the next uses its nunit test runner and the last uses msbuild to copy files around.
We have another .NET build that follows a similar pattern, but adds a few steps calling custom tools written in python.
We have a few java builds that only execute the NAnt runner.
Do what works best for you and your current environment. Live with that for a while and then see what you want to change.
If you already have a good msbuild or nant script just point teamcity on that and use it for triggering.
I like using teamcity's solution runner because it just works. Same with their test runner. But MSBuild/NAnt is really good for file pattern work.
Hope that helps.
我们使用 TeamCity 的方式如下：
1. 运行持续集成构建（有人提交代码后立即触发）
2. 每晚构建
3. 每晚部署（使用批处理/shell 脚本）
4. 健全性测试（在夜间部署时触发）
We use TeamCity as follows:
1. Run Continuous Integration builds (fired as soon as someone commits code)
2. Nightly builds
3. Nightly deployments (using batch/shell scripts)
4. Sanity tests (fired on the nightly deployments)
从技术上讲，您可以通过脚本或工具完成 TeamCity 所做的一切。 TeamCity 的优点在于它提供开箱即用的简单性来组织您的任务。 TeamCity 的核心是与行业范围内的工具的命令行和开箱即用的集成。它们减轻了配置负担，因此通过指定一些变量或参数，您可以自动执行繁琐的脚本需要完成的关键任务。 UI 以直观的方式智能地接收命令行参数。我最喜欢的 TeamCity 用例是它的历史意义，这源于其 UI 的强大功能。想象一下，如果您必须弄清楚上次运行的脚本失败的时间或失败的原因？你必须保留历史日志、文物等，这些都需要时间来整理以回答简单的问题。现在假设您必须报告自动化任务（构建）的历史趋势，您将需要一个自定义实现来筛选您收集的所有数据，只是为了报告或回答简单的问题，例如“此构建是否需要更长的时间？我们的单元测试数量增加了吗？”等等。所有这些数据点都是开箱即用收集的，并通过 teamcity 为您报告。如果你看不出来，我认为它是一个漂亮的工具。
Technically, you can do everything TeamCity does through a script or tool. The beauty of TeamCity is the simplicity it provides out of the box to organize your tasks. At the heart of TeamCity is commandline and out of the box integrations with industry-wide tools. They ease the configuration burden so that by specifying a few variable or parameters, you can automate key tasks that a cumbersome script would have done. The UI smartly takes in commandline parameters in an intuitive way. My favorite use case for TeamCity is its historic significance which stems from the power of its UI. Imagine if you have to figure out the last time a script you run failed or why it failed? you'll have to keep historical logs, artifacts etc that will take time to sort through to answer simple questions. Now imagine you have to report on the historic trend of your automated tasks (builds), you'll need a custom implementation that sifts through all the data you collect just to report or answer simple questions like "is this build taking longer? are the number of our unit tests increasing ?" etc. All these data points are gathered out of the box and reported for you with teamcity. If you can't tell, I think it is a beautiful tool.