您使用什么自动化构建系统？ 您的构建需要多长时间？
我当前的项目有 5 个独立的自动构建，在每次签入后启动：
单元测试（模拟数据库调用）：~6 分钟
集成测试（仅针对数据库）：~40 分钟
网站 1 UI（Selenium，从 UI 到 DB）：约 80 分钟
网站 2 UI1（Selenium，从 UI 到 DB）：~90 分钟
网站 2 UI2（Selenium，从 UI 到 DB）：约 100 分钟
我们使用 Maven2、JUnit 和 Selenium。
我认为将大大减少集成测试时间的一种策略是将尽可能多的集成测试移至单元测试中，并简单地使用集成项目来测试数据库的持久性。
我想知道您发现哪些策略有助于减少大型项目的构建时间。
My current project has 5 separate automated builds that kick off after each check-in:
Unit Tests (DB calls mocked out): ~6 Minutes
Integration Tests (just to the DB): ~40 Minutes
Website 1 UI (Selenium, from UI to DB): ~80 Minutes
Website 2 UI1 (Selenium, from UI to DB): ~90 Minutes
Website 2 UI2 (Selenium, from UI to DB): ~100 Minutes
We are using Maven2, JUnit and Selenium.
One strategy that I think will reduce drastically reduce Integration test time, is moving as many Integration tests as possible into the Unit Tests, and simply using the Integration project to test persistence to the DB.
I'm wondering what strategies you've found that have helped to reduce build times on large projects.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
我们的构建运行时间几乎相同，在 selenium 上可能稍微少一些（我想说大约 3x50 分钟的运行时间，在 Firefox、ie 和 Opera 上进行相同的站点测试）。 我们的解决方案是投入更多的CPU，我们有一个完全集群的bamboo环境7个双核节点。
我们发现在 web-container/selenium 测试的单独盒子上运行 selenium-rc 和浏览器可以显着改善 selenium 运行时间。
We have just about the same build runtimes, maybe slightly less on selenium (I'd say around 3x50 minutes runtime, same site tests on firefox, ie and opera). Our solution was to throw more cpu at it, and we have a clustered bamboo environment of totally 7 dual-core nodes.
We found that running selenium-rc and the browser on a seperate box from the web-container/selenium test improved selenium runtimes quite significantly.
我正在使用 GNU make 来自动化一切。 根据项目的不同，需要 2 分钟到 30 分钟不等。
I'm using GNU make to automate everything. Depending it takes from 2 minutes to 30 minutes depending on the project.
团队系统：所有事情不到1小时
Team System: under 1 hour for everything
我假设您的项目由几个子项目组成。 如果没有，您可能需要重构代码库，以便它可以。 这样，您可以选择仅构建整个应用程序的特定部分，测试各个部分，然后在解决了正在处理的子项目上的错误后运行集成测试。
I assume your project consists of several subprojects. If it does not you may want to refactor the code base so that it does. This way you can chose to only build specific parts of the overall application, test the individual part then run your integration tests when you’ve worked out the bugs on the subproject you are working on.
我们使用 Hudson 构建一个大型 C# 解决方案，其中包含一些 Windows 服务、Web 服务和可执行文件。 通过 MSTest.exe 进行大约 800 次左右的测试，每个构建大约需要 12-15 分钟。 由于 MSTest 速度很慢，测试占据了很大一部分。
为了减少时间，我们尝试限制生成的通过 MSTest 运行的程序集的数量，因为安装和拆卸似乎需要一段时间。
编辑：我们的构建还部署到我们的证书环境，其中包括 Web 服务、Windows 服务、可执行文件和数据库部署。 只是为了让您了解范围
We use Hudson to build a large C# solution containing a handful of windows services, web services, and executables. Around 800 or so tests via MSTest.exe and it takes about 12-15 minutes per build. Tests take up a large portion since MSTest is slooow.
To cut down on time we've tried to limit the number of assemblies produced to run through MSTest since the setup and teardown seems to take a while.
Edit: Our build also deploys to our cert env which includes web services, windows services, executables and database deployment. Just to give you an idea of scope
Erlang Common Test - 主要关注系统测试而不是单元测试。
Erlang Common Test - mostly focussing on System Tests as opposed to Unit Tests.
我们所有的自动化构建都是通过 Team City 完成的。
我们使用的最自动化的项目实际上是编译器。 我们的测试套件由大约 20000 个编译和运行的测试查询组成，在每次签入时运行。 过去，这需要一个小时的时间，但将完整的测试套件保存在构建机器上的 RAM 驱动器中（而不是每次都检查它）可以将这个时间缩短到几分钟。
每天晚上都会触发第二个构建，运行这些相同的测试，但在 4 个不同的配置文件下运行，同时在 NCover 下运行，生成代码覆盖率报告。 此场景需要几个小时，这就是它作为夜间构建完成的原因。 同时生成其他内部报告，以确保一切正常运转。
测试套件本身的更新是单独触发的，并签出到 RAM 驱动器，为下次运行做好准备。 否则检查测试会花费大部分构建时间。 测试套件的一部分来自我们无法控制的远程 CVS 存储库，甚至查询此存储库的更新也会增加几分钟的构建时间，因此这也是在“更新测试”构建中完成的。 这种松散的耦合意味着我们必须将该项目的构建限制在一台机器上，但由于反馈如此之快，这不是一个大问题。
事实证明，在保持代码库的高覆盖率的同时，尽可能快地保持“常规”测试构建非常有帮助。 任何缓慢的测试（超过一秒左右）都已被拉到夜间构建中。 在我们的例子中，将测试保存在 RAM 驱动器中确实很有帮助，尽管我们的场景相当专业。 我想模拟你的数据库是最接近的等价物。 我的建议是通过删除任何“笨重”或缓慢的测试来保持一个构建“精简和平均”，让快速响应知道您可能没有破坏任何东西。 其他构建可以在单独的机器上运行，或者在晚上运行，以保持快速构建的快速响应。
从长远来看，我们拥有的最长的自动化构建（对于另一个项目）有时需要一天以上的时间，尽管幸运的是它不需要定期运行。
All our automated builds are done with Team City.
The most automated project we work with is effectively a compiler. Our test suite consists of around 20000 test queries that are compiled and run, which is run on every checkin. This used to take the best part of an hour, but keeping the complete test suite in a RAM drive on the build machine (rather than checking it out each time) reduces this to a few minutes.
Every night a second build is triggered that runs these same tests, but under 4 different profiles, whilst running under NCover which produces a code coverage report. This scenario takes several hours, which is why it is done as a nightly build. Other internal reports are produced at the same time to ensure that everything is working as it should.
Updates to the test suite itself are triggered separately and checked out to the RAM drive ready for the next run. Checking the tests out was otherwise taking most of the build time. Part of the test suite comes from a remote CVS repository out of our control and even querying this for updates added a few minutes to the build time, so this is also done in the "Update tests" build. This loose coupling has meant that we have had to restrict builds of this project to one machine, but since feedback is so quick, this is not a big problem.
It has proved immensely helpful to keep the "regular" test build as fast as possible whilst retaining high coverage of the codebase. Any slow tests (more than a second or so) have been pulled through to the nightly build. In our case keeping the tests in a RAM drive has really helped, although our scenario is rather specialist. I guess that mocking your database is the nearest equivalent. My advice is to keep one build "lean and mean" by removing any "chunky" or slow tests, allowing a snappy response to know you probably haven't broken anything. The other builds can be run on separate machines, or at night in order to keep the response quick from the fast build.
For perspective the longest automated build we have (for another project) sometimes takes more than a day, although thankfully it is not one that needs to be run regularly.
不幸的是，在我当前的客户中，BuildForge（来自 ClearCase SCC）：一到三天。 认真的。 我真的不知道他们在构建中做了什么，也不知道为什么需要这么长时间。
At my current client, unfortunately, BuildForge (from ClearCase SCC): anywhere from one to three days. Seriosuly. I don't really know what they do in a build or why it takes so long.