从 TeamCity 的单个解决方案发布多个项目
我有一个 VS2008 解决方案，其中有多个项目。我需要发布其中五个项目，并且这五个项目中的两个需要发布两次，并使用两个不同的配置设置（我需要做的就是对一些 web.config 属性的 configSource 进行简单更改）。
然后，我想获取生成的 7 个输出，将 4 个放入一个 zip 文件中，将另外 3 个放入另一个 zip 文件中，并将它们推送到客户端 FTP，准备部署。
我是否试图在一个构建配置中做太多事情，或者这是否合理？
I have a VS2008 solution with multiple projects in it. I need to publish five of these projects and two of those five needs to be published twice, with two different configuration settings (a simple change to the configSource of a few web.config attributes is all I need to do).
I would like to then take the resulting 7 outputs and put 4 into one zip file and the other 3 into another and push them to a clients FTP ready for deployment.
Am I trying to do too much in one build configuration or is this reasonably possible?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我认为这可以通过两种配置来完成。我使用解决方案运行程序来构建解决方案中的所有项目，然后在工件路径部分中，每行都会有类似以下内容：
然后使用复制功能复制配置。我很确定您不能将 2 个跑步者与一个构建配置关联起来。
I think that can be done in 2 configurations. I use the solution runner that builds all projects in the solution, then in the artifacts path section, each line would have something like:
Then use the copy function to copy a configuration. I'm pretty sure you can't associate 2 runners with one build configuration.
根据您使用的 TeamCity 版本，您可以在多个配置（TC v5 或更低版本）中执行所有这些步骤，也可以在一个配置（TC v6 或更高版本）中执行多个步骤。我通常倾向于将构建步骤与部署步骤分开。因此，我将使用单个配置来编译、测试项目等，并将所有内容发布为工件。然后有不同的配置（例如针对不同的部署环境）进行部署，每个配置可能共享相似的步骤和脚本。
好处是您可以更好地控制队列优先级、代理负载等。但代价是端到端构建过程可能需要更长的时间并且有更多的移动部件。
Depending on which version of TeamCity you are using, you can either do all of these steps in multiple configurations (TC v5 or earlier) or multiple steps within a configuration (TC v6 or later). I generally favor splitting the building steps from the deployment steps. So I would have a single configuration for compiling, testing, etc of the project(s) and publish everything as artifacts. Then have different configurations (for different deployment environment, for example) to deploy, each may share similar steps and scripts.
The benefit is you get more control over queue priority, agent loads, etc. But the trade off is that the end-to-end build process may take longer and have more moving parts.