如何在集成服务器上进行构建？
假设您有两名开发人员在他们的笔记本电脑上本地处理一个项目（A 和 B）。 他们每个人都有 SVN 存储库的工作副本，并且他们在 VS 中进行编码。 每个应用程序都有一个功能齐全的副本。 他们在每个停止点都重新承诺 SVN。
您有一个集成/测试服务器（C），其中有另一个工作副本，每当您想要测试时都会更新该工作副本。
您还有生产服务器 (D)，它具有来自 C 的构建后 xcopy。
假设代码是一个 Web 应用程序项目，因此它需要显式构建（与仅获取源代码并即时构建）。
您如何在集成服务器 (C) 上对此进行管理？
如果开发人员在他们的机器（A 和 B）上构建，然后将 DLL 推送到集成服务器（C）...这是行不通的，因为集成服务器必须从它们的机器上获取代码并开发一个通用的 DLL 。 因此，所有源代码都必须到达集成服务器 (C)，在那里构建，然后仅将所需的文件和 DLL 推送到生产环境 (D)。
如何管理集成服务器 (C) 上的构建？ 您有从命令行进行定时构建吗？ 您是否在集成服务器（C）上安装 VS 并以这种方式构建？ 如果从命令行执行此操作，如何管理 VS 通常在 CSPRJ 或 SLN 文件中管理的所需引用和其他设置？
Assuming you have two developers working on a project locally on their laptops (A and B). They each have working copies of the SVN repo, and they're coding away in VS. Each one has a fully-functioning copy of the app. They commit back to SVN at every stopping point.
You have an integration/test server (C) which has another working copy which is updated whenever you want to test.
You also have production server (D) which has a post-build xcopy from C.
Say the code is a Web Application Project, so it requires an explicit build (as opposed to a Web Site Project which just takes the source code and builds on-the-fly).
How do you manage this on the integration server (C)?
If the developers build on their machines (A and B), then push the DLLs to the integration server (C)...this won't work, because the integration server has to take code from both of them and develop a common DLL. So, all the source code has to get to the integration server (C), be built there, and just the required files and DLL pushed to production (D).
How do you manage the build on the integration server (C)? Do you have a timed build from the command line? Do you install VS on the integration server (C) and build that way? If doing it from the command line, how to do manage the required references and other settings that VS normally manages in a CSPRJ or an SLN file?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
这个问题的最佳解决方案是使用持续构建解决方案，例如 CruiseControl。 您正确地识别了自己执行此操作的所有陷阱，并且最终设置第三方软件包会简单得多，而不必自己解决这些问题。
CruiseControl 可以配置为基于颠覆提交、定时或按需构建。 此外，它还可以运行所有单元测试，并在出现问题时向人们发出警报。 这完全是一个非常棒的包。
The best solution to this question is to use a continuous build solution such as CruiseControl. You're correct in identifying all the pitfalls of doing it yourself, and in the end it will be far simpler to set up a third party package and not have to solve these problems yourself.
CruiseControl can be configured to build based on a subversion commit, on a timed basis, or on demand. In addition, it can also run all of your unit tests and alert people when things go wrong. It's altogether a pretty great package.
我们还使用 svn 存储库中的 subversion 提交挂钩，它会在每次提交时激活单元测试构建。 我们链接不同的构建，因此集成测试和 Web 测试在单元测试构建绿色时运行。 此外，我们真的很想在所有这些结束时链接发布版本，但我们的集成测试对此不够稳定（不稳定的后端环境和开发中的 SLA 很糟糕 - 我讨厌它！）。 目前我们手动启动发布版本。 从质量角度来看，我们可以直接从所有绿灯转到验收测试服务器，但这意味着您可能希望在验收测试中运行交替映像，因为如果构建系统每次重新部署，它可能会造成相当多的停机时间。成功的提交已经全部完成。 （在我们的项目中，从上午 10 点到下午 2 点，我们大部分时间都处于停机状态，因为在那个时间段会有连续不断的提交流；）
We also use a subversion commit hook from out svn repo, which activates the unit test build on each commit. We chain the different builds, so the integration test and the web tests run when the unit tests build green. Furthermore we'd really like to chain the release build at the end of all of these, but our integration tests aren't stable enough for this (flaky back-end environments with bad SLAs in development - I hate it!). At the moment we manually start the release builds. From a quality perspective we could go straight from all green lights to acceptance test servers, but that means you probably want alternating images running in acceptance test, since the build system can be creating quite a lot of down-time if it redeploys every time a successful commit has gone all the way through. (In our project we'd be down most of the time from 10am to 2pm, since there's a continious stream of commits around that time ;)
我们使用 Cruise Control 在集成服务器上进行持续集成。 我们的巡航控制脚本执行以下步骤：
上述命令均在我们的 CC.net 服务器上配置并安排在凌晨 1 点执行。 为了便于维护，我们在集成服务器本身上部署了 CC.net 服务器。 如果它是一个 Web 应用程序，这还可以帮助我们自动执行测试用例并发送结果。 任何代码损坏都会通过电子邮件发送给配置的订阅者，并在第二天采取适当的措施。
一旦集成服务器上一切正常，我们只需“更新”生产服务器上的“发布”分支即可。
您可以此处找到有关 cc.net 的更多信息。
如果您需要有关脚本的帮助，我可以一定会帮助你。
We use Cruise Control for continuous integration on the Integration server. Our cruise control script executes the following steps :
The above commands are all configured on our CC.net server and scheduled for 1.00 am execution. For ease of maintenance we have deployed our CC.net server on our Integration server itself. that also helps us in executing our test cases automatically and sending out the results, if its a web application. Any code breakage is sent out in an email to configured subscribers and appropriate actions are taken the very next day.
Once everything is fine on Integration server, we simply "update" the "release" branch on Production server.
you can find more info about cc.net here
if you need help with the scripts, i can surely assist you.