CruiseControl.NET 和网页界面定制
大家！
我对构建服务器的改进感到非常困惑。 关键是我们公司有一个特定的构建流程。一方面，它非常简单：
- 从 SVN 更新源代码
- 构建 VisualStudio 解决方案（C++ 和 C#）
- 构建发行版
- 将发行版移动到特定服务器文件夹
另一方面，一个项目有大约 200 个不同的发行版。我们不想每天都构建所有这些，但是一天中有些人需要构建一些分配器。最初我们有一个 cmd 文件来构建项目。然后，我编写了简单的 Web 界面来生成 cmd 文件并组织构建队列。这个解决方案是可以接受的，但是
随着项目的增长，它的维护变得非常痛苦。
现在我有一个选择 - 使用 CruiseControl.NET（或类似的东西）或改进我自己的程序。我真正需要的是：
- 用户可以选择分配和一些构建参数的 Web 界面
- 带有一些统计信息的 Web 界面（构建、所做的、存储库的当前修订版、工作副本的当前修订版等）
- 灵活的配置来自定义构建
过程据我所知，我可以使用 CruiseControl.NET 开箱即用地获得 (2) 和 (3)，但是 (1) 呢？另外，我不确定，当我实际上不需要 CI 时，使用 CI-server 是一个不错的决定。
所以，我的问题是：使用 CC.NET 是一个好的决定还是我应该改进自己的程序？
PS我已阅读这篇文章，但我仍然不确定 CC.NET Web 界面的机会...
everybody!
I'm really puzzled with my build server improvements.
The point is that we have a specific build process in our company. On the one hand, it's quite simple:
- Update source code from SVN
- Build VisualStudio solution (C++ & C#)
- Build distributives
- Move distributives to specific server folder
On the other hand, we have about 200 different distributives of one project. We don't want to do build of all of them every day, but during a day some people need to build some distributives. Initially we had a cmd file to build the project. Then, I wrote the simple web-interface to generate cmd files and organize a build queue. This solution is acceptable, but
its maintanence is becoming really painful as project grows.
Now I have a choice - use CruiseControl.NET (or something like that) or improve my own program. What I really need is:
- Web-interface where user can choose distributive and some build params
- Web-interface with some statistics (builds, that were made, current revision of repository, current revision of working copy etc)
- Flexible config to customize build process
As far as I know, I can get (2) and (3) out of box with CruiseControl.NET, but what about (1)? Also, I'm not sure, that use CI-server, when I actually don't need CI, is a good decision.
So, here is my question: is it a good decision to use CC.NET or should I improve my own program?
P.S. I've read this article, but I'm still not sure about CC.NET web interface opportunities...
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
您始终可以使用混合模式：您自己的小型应用程序为 CC.NET 或 HUDSON 集成任务提供服务。
除了外观和感觉的修改之外，更改这些工具的 GUI 并不那么容易。
You can always have a mixed mode : Your own small applciation serving a CC.NET or HUDSON intergation tasks.
It is not so easy to change the gui of these tools, beyond the look and feel modification.
我们通过为所需的某个“参数”的每个值创建一个 cc 项目，使用 ccnet 实现了#1。
我们从 ccnet 中的增量构建和完整构建开始。
增量构建更新了工作副本，构建了它，运行了部分单元测试集并通过电子邮件发送了结果。
完整版本更新了不同的工作副本，重建了解决方案，运行所有单元测试，生成安装程序，将安装程序导出到某些位置，最后在其他指定的测试机器上触发回归测试。
完整的构建做了很多事情，有时我们只想重建代码并生成安装程序。我们希望避免运行单元测试并生成回归测试。
因此我们添加了另一个名为 fullbuild_notest 的 cc 项目。这会执行与完整构建相同的 nant 目标，只是它会跳过测试部分。我们有一个 nant 构建文件，它是一个带有入口点的引导程序。首先，我们将名为“fullbuild-testing-enabled”的属性设置为 true 或 false，然后调用子目标来执行实际构建。子目标及其子目标检查“fullbuild-testing-enabled”标志以确定是否进行测试。
在某种程度上，这很好，因为它为仪表板用户提供了一组特定的选择。从某种程度上来说，这很麻烦，因为每次需要新的参数或参数值时，都需要更改 nant/ccnet 代码。
We achieve #1 with ccnet by creating a cc project for each value of a certain "parameter" that is needed.
We started out with an incremental build and a full build in ccnet.
The incremental build updated a working copy, built it, ran a partial set of unittests and emailed the results.
The full build updated a different working copy, rebuilt the solution, ran all the unittests, generated installers, exported the installers to certain places and finally triggered regression tests on other designated test machines.
The full build did a lot of stuff and sometimes we only wanted to rebuild the code and generate the installers. We wanted to avoid having to run the unittests and spawn the regression tests.
So we added another cc project called fullbuild_notest. This executes the same nant targets as the fullbuild except it skips the testing part. We have a nant build file that's sort of a bootstrapper with entry points. At the beginning we set a property named "fullbuild-testing-enabled" to true or false and then call a child target to do the actual building. The child target and its children check the "fullbuild-testing-enabled" flag to determine whether or not to do testing.
In a way this is good because it gives the dashboard users a certain set of choices. And in a way it's cumbersome because every time a new parameter or parameter value is needed, a change to the nant/ccnet code is required.