哪个持续集成系统最容易从备份在新机器上重新建立？
我很高兴使用 Hudson（现在是 Jenkins）几年了，我喜欢该系统的总体态度 - 这确实是一个很好的程序 - 但重点不在我需要良好运行的一件事上。
好吧，如果我们的构建服务器发生问题，并且我们需要从备份磁带（整个工作区）重建它，那么使用 Jenkins 并不容易做到这一点。由于我们本身不依赖任何 Jenkins 特定的功能，因此我正在考虑其他 CI 系统是否有更好的方法。
基本上，当从 git 中提取时，我们有多个彼此相邻的 Eclipse 项目。每个构建条目都指向随后构建的项目之一中的 ant 脚本。我们需要对所使用的 Ant 和 Java 版本具有充分的灵活性。这可以在项目中某处的“启动配置”文件中完美地描述，因此所需要做的就是指向（甚至可能自动发现）所述启动文件。
如果历史也能建立起来，那就更好了，但我真的希望能够让工作恢复并运行。
有什么建议吗？
（注释 2013-02-18：我们将构建过程迁移到 Maven。这极大地简化了 Jenkins 配置，并使这个问题不再那么重要。很高兴知道您是否可以从备份磁带或从头开始轻松引导 CI 配置（基于存储在各种 pom 文件中的信息））
I have had the pleasure of using Hudson (now Jenkins) for a few years now, and I like the general attitude of the system - it's really a nice program - but the focus is elsewhere than one thing I need to get running well.
This is, well, if something happens to our build server and we need to rebuild it from backup tapes (of the whole workarea), this is not easily done with Jenkins. As we do not as such rely on any Jenkins-specific features, I was considering if other CI systems have a better method in place.
Basically we have multiple Eclipse projects next to each other when extracted from git. Each build entry points to an ant script in one of the projects which is then built. We need full flexibility with the version of Ant and Java used. This can perfectly well be described in a "launch configuration"-file somewhere in the project so all that is needed is to point at (or perhaps even auto-discover) said launch file.
It would be better, if the history could be established too etc, but I'd really like just to be able to get the jobs back up and running.
Any recommendations?
(Note 2013-02-18: We migrated our build process to Maven. This simplified the Jenkins configuration greatly and made this question less important. It is still nice to know if you can bootstrap a CI-configuration easily from backup tapes or scratch (based on information stored in the various pom files))
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
备份 Jenkins 相当容易。
备份所有配置文件。我有一个 Jenkins 作业，每小时运行一次，扫描任何 config.xml 更改或添加，并在我们的 Perforce 服务器中添加/更新它们。此外，如果我把配置搞得够糟糕，它使我能够回滚到旧的配置，只需在 Perforce 中进行同步即可。
备份您的插件。我只是将 .hpi 文件再次备份到 perforce 中。这样我就不必记住我的服务器上有哪些插件，如果我需要重建它。
备份您的工作区目录。我不这样做，因为我不关心我的 CI 构建，并且我的夜间构建存储在另一台服务器上。我发现 Jenkins 副本非常非常慢，因此我将构建脚本中的所有工件/源代码复制到存档服务器，该服务器已由 IT 每晚备份（它是 san）。唯一的问题是我无法将 Jenkins 作业工件指向单独的位置并让 Jenkins 将它们链接为工件。我还没有找到一个插件可以做到这一点，而且我一直在编写的插件运行速度很慢。但这并不是太糟糕的权衡。
这三个允许我恢复 Jenkins，但没有日志文件（我真的不需要它们，只要我有输出，tee.exe 就是你的朋友），如果我的服务器死机的话，可以在很短的时间内恢复。
It's fairly easy to backup Jenkins.
Backup all your config files. I have a Jenkins job that runs once an hour, scans for any config.xml changes, or additions, and adds/updates them in our Perforce server. In addition it gives me the ability to rollback to an old config , if I mess up a config bad enough, just by doing a sync in Perforce.
Backup your plugins. I just backup the .hpi files, again into perforce. That way I don't have to remember what plugins I have on my server, should I need to rebuild it.
Backup your workspace dir. This one I don't do, as my CI builds I don't care about, and my nightly builds are stored on another server. I found the Jenkins copy to be very very slow, so I copy all artifats/sources inside my build scripts instead, to an archive server, that is backed up nightly, by IT already(it's a san). The only problem with this, is I can't point a Jenkins job artifacts to a separate location and have Jenkins link them as artifacts. I haven't found a plugin to do this, and the plugin I've been writing to do it is coming along slow. But it's not too bad of a tradeoff.
These 3 allow me to restore Jenkins, but without log files(I don't really need them, as long as I have the output, tee.exe is your friend) in a pretty short order should my server ever die.
这可能不是您问题的直接答案，但是......
我们使用 Jenkins（以前称为 Hudson）已经一年半多了。我们没有使用任何 Jenkins 特有的、我不会在其他 CI 系统上使用的功能。然而，在最初配置了 buildbot 和 CruiseControl（抱歉，请不要恨我）之后，我发现大量的可用插件和 Jenkins 的普遍易用性使得这个选择变得理所当然。我们现在正在构建 86 个项目，并拥有两台服务器 - 一台用于开发，一台用于 QA 和发布版本。
至于备份，我们实际上每周备份一次整个 Jenkins 主文件夹（对于两台服务器）。我们每月一次备份所有虚拟机（整个虚拟硬盘）。
请注意，我们的服务器和所有从属服务器都是虚拟机。
这样，如果出现问题，我至少可以轻松恢复作业配置 - 最旧的配置是一周。
无论如何，存储库拥有所有最新代码，并且虚拟机可以恢复到（最多）一个月前的版本。
此外，Jenkins 还有一个备份插件 - https://wiki.jenkins-ci.org /display/JENKINS/Backup+Plugin - 这使得备份至少配置变得非常容易。
考虑到备份不是 CI 系统的主要功能，因此它们很可能都有自己的备份和恢复怪癖。
只是我的 2 派萨/美分/便士。
This probably is not a direct answer to your question, but...
We've been using Jenkins (formerly Hudson) for just over a year and a half now. We have not used any feature that is Jenkins specific that I would not get on other CI systems. However, after going through configurations of buildbot and CruiseControl (sorry, please don't hate me) initially, I found that the plethora of plugins available and the general ease of use of Jenkins made the choice a no-brainer. We now have 86 projects building, and have two servers - one for development, and one for QA and Release builds.
As for backups, we actually back up the entire Jenkins home folder once a week (for both servers). Once every month, we back up all our virtual machines (entire virtual hard disk).
Note that both our servers and all slaves are VMs.
This way, if something goes wrong, I can restore at least the job configurations easily - the oldest it will be is one week.
The repository has all the latest code anyway, and the virtual machines can be brought back to a version which is (at most) one month old.
Also, Jenkins has a backup plugin - https://wiki.jenkins-ci.org/display/JENKINS/Backup+Plugin - which makes it quite easy to back up at least the configuration.
Considering that backup is not the primary function of a CI system, chances are all of them are going to have their own quirks for backup and restore.
Just my 2 paisa/cents/pence.