更新 Hudson 和插件
我想知道哪些步骤是升级 Hudson 和插件的最佳步骤。
我现在运行的是1.347。我曾经尝试更新，但由于某些插件不兼容而导致混乱。
另外我想删除一些插件是否适合只删除 hpi 文件？很高兴知道其他人如何执行此步骤以及按什么顺序执行。
我应该先升级 hudson 然后再逐个插件升级吗？
如果插件破坏了某些东西，再次降级怎么办？看来工作量很大。 或者有什么简单的方法吗？
另外，保存所有 xml 配置文件是否足够，以防出现可以恢复的损坏？
提前致谢。
I was wondering which steps are the best to upgrade hudson and the plugins.
I'm running 1.347 at the moment. I once tried to update which resulted into a mess because some plugins were incompatible.
Also i want to delete some plugins is it appropriate to just delete the hpi file? It would be nice to know how other people do this step and in which order.
Should i first upgrade hudson and then plugin by plugin?
And if a plugin breaks something downgrade it again? It seems to be a lot of work.
Or is there any easy way?
Also is it enough to save all the xml configuration files in case something breaks that i can recover?
Thanks in advance.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我的解决方案有点矫枉过正，但我被烧伤了两次（一次是 Hudson bug，一次是插件不兼容），并吸取了教训。
我在虚拟机上安装了 Hudson，其插件与我的生产实例相同，并且进行了一些简单的构建。当我觉得需要升级或想要查看最新版本时，我会在虚拟机上升级 Hudson 并验证它是否启动并可以进行构建。我只在升级测试系统后升级所有开发人员使用的生产系统。我通常不会对我的测试系统进行详尽的测试；这足以确保升级后的 Hudson 和插件的组合正确启动。
当升级虚拟机或主系统时，我升级所有插件，然后升级 Hudson 本身并重新启动。 （因为我有一个测试系统，所以我并不特别担心一步一步做事。）
我在 Hudson 引入降级支持之前就想出了我的流程。我仍然使用这个过程，因为对我来说重要的是要相信升级不会破坏其他开发人员使用的系统。这个设置还允许我有一个独立于主 Hudson 系统的实验设置，我发现这很有用。
My solution is overkill, but I was burned twice (once by a Hudson bug and once by plugin incompatibilities) and learned my lesson.
I have Hudson installed on a VM with the same plugins as my production instance and a couple of simple builds. When I feel it's time to upgrade, or want to check out the latest release, I upgrade Hudson on the VM and verify that it starts up and can do builds. I only upgrade the production system that all of our developers use after I've upgraded my test system. I generally don't do exhaustive tests on my test system; it's enough to make sure the combination of upgraded Hudson and plugins starts up properly.
When upgrading either the VM or the main system, I upgrade all the plugins, then upgrade Hudson itself and restart. (Since I have a test system, I'm not particularly worried about doing things step by step.)
I came up with my process before Hudson introduced downgrade support. I still use this process because it's important to me to have confidence that an upgrade is not going to break the system that other developers use. This setup also allows me to have an experimental setup that's separate from the main Hudson system, which I find useful.
我通常先更新 Hudson，然后再更新插件。
Hudson 的最新版本对此过程提供了一些支持：
这意味着升级插件后，您有一个按钮可以让您根据需要降级到以前安装的版本。
即将推出的 Hudson 1.387 将避免使用原子
HUDSON_HOMEcode>*.xml 文件，这将使关键配置文件的备份过程变得更加容易。（目前，使用 Hudson 1.386，我在
HUDSON_HOME下看到：）
I usually update Hudson first, then the plugins.
The recent versions of Hudson have some support for this process:
That means after upgrading a plugin, you have a button which allows you to downgrade to the previous installed version if needed.
And the upcoming Hudson 1.387 will avoid littering
HUDSON_HOMEwith atomic*.xmlfiles, which should make the backup process of critical config files that much easier.(Currently, with an Hudson 1.386, I see under
HUDSON_HOME:)