CruiseControl Enterprise 最佳实践 (6) :Scaling up
I was an Infrastructure Specialist at ThoughtWorks. In my role I make sure that we are building our software so it can successfully be deployed to production. In this series of blog posts I hope to pass on my top ten tips for using CruiseControl Enterprise effectively. I'm writing these with the developers or systems administrators in mind: the people who most often manage CruiseControl. However, I hope that anybody who is interested in Continuous Integration will get something from these articles.
# 6: Scaling up
第 一件要做的事就是确保你可以同时构建你的多个项目. CruiseControl使用Java线程来管理构建和项目. 每个项目都有自己的项目线程. 而至少有一个构建线程来真正的运行一次构建. 实际上有一个构建队列, 来调度从项目线程到发到构建线程的请求. 你要给CruiseControl足够的构建线程来运行: 缺省情况下只有一个构建线程. 它的影响就是如果你配置了 5 个项目, 你也只能一次构建一个. 这也可以接受, 如果你只有一台很弱的构建服务器, 或者项目之间不能和平共处.
另一方面, 如果你有强大的计算能力可以使用, 你就可以从额外的构建线程中得到提速. 正确的线程数量设置会随着时间而变化; 不要不情愿去做性能管理来找到你的服务器的最优的设置.
<cruisecontrol>
<system>
<configuration>
<threads count="2" />
</configuration>
</system>
<!-- rest of config file suppressed -->
</cruisecontrol>
Jeffrey Frederick 则明智的指出设置多于项目个数的构建线程数是没有意义的.
在 调优你的持续集成服务时, 还有大量的其它因素可以考虑: 你的版本控制系统的速度, 你在哪里存储你的构建产物, 日志, 等等. 今天我要提到的一个因素是硬盘带宽. 编译软件是一个很耗硬盘的过程. 即使构建已经完成了编译Java代码和打包jar包等操作, CruiseControl还得写日志文件. 所有这些事情很容易就会让单个硬盘满负荷运转. 理想情况下你想确保你的机器能够一次构建多个项目.
在 我很早期的一个ThoughtWorks项目中, 我们的团队运行了两个CruiseControl服务器, 显然是因为最初的那个Solaris服务器太慢了. 对我来说这看起来不对劲. 于是我深入的看了一下. 依靠我的系统管理员背景, 我发现了某个硬盘100%的忙于运行操作系统, CruiseControl和构建. 我把工作负载分布到系统中的四个硬盘上, 然后那台机器就能管理多得多的项目了.
在我后续的项目中, 这个模式不断的重复. 以我的经验, 没有多少CI服务器是因为处理器过载而受到限制. 不幸的是, 一旦系统启动并开始运行, 矫正磁盘问题通常会很痛苦. 在调优和人们开始抱怨缓慢的构建之前, 定购大量的快速的硬盘驱动器并祝自己好运.
实 现这个模式的方法是使用CruiseControl的配置文件. <log>元素用来告诉CruiseControl把日志文件写到哪. 缺省情况下它是CruiseControl安装目录下的一个子目录. 如果你修改了<log>元素的"dir"属性, 你就能够确保日志文件可以写到没有运行CruiseControl的硬盘上. 如果你使用 Ant 来构建你的代码, 你可以使用配置文件中<ant>元素的 "antWorkingDir" 属性来保证你的项目在另外一个硬盘上构建.
我 无法为此给出一个很好的例子, 每个CruiseControl的实例之间太不一样了. Buildx是一个使多个安装更一致的尝试. 如果你看一下各个部分在硬盘上的布局方式, 你就会发现CruiseControl的安装在/usr/share/cruisecontrol, 但是projects和logs安装在/var/spool/cruisecontrol: 我们这么做的原因是这样的话你就能 mount /var 目录到另外一块硬盘, 如果系统开始变得繁忙. 如果你想知道更多的话随时告诉我.
另一方面, 如果你有强大的计算能力可以使用, 你就可以从额外的构建线程中得到提速. 正确的线程数量设置会随着时间而变化; 不要不情愿去做性能管理来找到你的服务器的最优的设置.
<cruisecontrol>
<system>
<configuration>
<threads count="2" />
</configuration>
</system>
<!-- rest of config file suppressed -->
</cruisecontrol>
Jeffrey Frederick 则明智的指出设置多于项目个数的构建线程数是没有意义的.
在 调优你的持续集成服务时, 还有大量的其它因素可以考虑: 你的版本控制系统的速度, 你在哪里存储你的构建产物, 日志, 等等. 今天我要提到的一个因素是硬盘带宽. 编译软件是一个很耗硬盘的过程. 即使构建已经完成了编译Java代码和打包jar包等操作, CruiseControl还得写日志文件. 所有这些事情很容易就会让单个硬盘满负荷运转. 理想情况下你想确保你的机器能够一次构建多个项目.
在 我很早期的一个ThoughtWorks项目中, 我们的团队运行了两个CruiseControl服务器, 显然是因为最初的那个Solaris服务器太慢了. 对我来说这看起来不对劲. 于是我深入的看了一下. 依靠我的系统管理员背景, 我发现了某个硬盘100%的忙于运行操作系统, CruiseControl和构建. 我把工作负载分布到系统中的四个硬盘上, 然后那台机器就能管理多得多的项目了.
在我后续的项目中, 这个模式不断的重复. 以我的经验, 没有多少CI服务器是因为处理器过载而受到限制. 不幸的是, 一旦系统启动并开始运行, 矫正磁盘问题通常会很痛苦. 在调优和人们开始抱怨缓慢的构建之前, 定购大量的快速的硬盘驱动器并祝自己好运.
实 现这个模式的方法是使用CruiseControl的配置文件. <log>元素用来告诉CruiseControl把日志文件写到哪. 缺省情况下它是CruiseControl安装目录下的一个子目录. 如果你修改了<log>元素的"dir"属性, 你就能够确保日志文件可以写到没有运行CruiseControl的硬盘上. 如果你使用 Ant 来构建你的代码, 你可以使用配置文件中<ant>元素的 "antWorkingDir" 属性来保证你的项目在另外一个硬盘上构建.
我 无法为此给出一个很好的例子, 每个CruiseControl的实例之间太不一样了. Buildx是一个使多个安装更一致的尝试. 如果你看一下各个部分在硬盘上的布局方式, 你就会发现CruiseControl的安装在/usr/share/cruisecontrol, 但是projects和logs安装在/var/spool/cruisecontrol: 我们这么做的原因是这样的话你就能 mount /var 目录到另外一块硬盘, 如果系统开始变得繁忙. 如果你想知道更多的话随时告诉我.