配置Hudson以部署构建 [英] Configuring Hudson to deploy a build

问题描述

我正在尝试配置Hudson，以便我能够自动部署一个构建（一个.war文件）到Tomcat。

I'm trying to configure Hudson so that I will be able to automatically deploy a build (a .war file) to Tomcat. The newly deployed build will then be used by someone to test the application.

我已经尝试使用Deploy Plugin自动部署.war文件，这是有效的。但是，构建.war文件的作业将在每次scm更改后运行（每当代码提交时）。使用部署插件，.war文件将在每次构建时部署到Tomcat。因为代码是频繁提交的，这意味着web应用程序也会频繁重启，这将中断测试过程。

I've tried using the Deploy Plugin to automatically deploy the .war file, and this works. However, the job that builds the .war file will run after every scm change (whenever code is committed). With the Deploy Plugin, the .war file would be deployed to Tomcat every time a build is made. Because code is commited frequently, this will mean that the web application will be restarted frequently as well, and this will interrupt the testing process.

我欣赏哈德逊运行我的单元测试，并定期构建，所以我不想改变这个工作的触发器。

I appreciate the fact that Hudson runs my unit-tests and makes a build regularly, so I don't want to change the triggers for this job.

我正在寻找一种方式，我可以手动决定从Hudson部署。我尝试创建一个单独的作业，将部署.war从第一个工作，但这不工作。

I am looking for a way that I can manually decide to deploy from within Hudson. I tried creating a separate job that will deploy the .war from the first job, but this didn't work. Does anyone have any experience setting something like this up?

推荐答案

如何获取工件

查看如何回滚或重新部署之前的版本部分部署+插件>部署插件页面。它描述了基本的想法。它使用复制Artifact插件将构件从构建作业复制到当前作业（部署作业）。

How to get the artifacts

Look at the section "How to rollback or redeploy a previous build" on the Deploy Plugin Page. It describes the basic idea. It uses the Copy Artifact Plugin to copy the artifacts from the build job to your current job (the deploy job). From there you do the same that you did in your build step.

在启动部署后无法触发构建作业，因此首先运行构建，而不是部署作业。因此，有几个选项：

The build job can not be triggered after you start the deploy so that first a build runs and than the deploy job. So there a a few options:

• 手动触发构建。启动部署的用户需要选择特定的构建作业运行。


• 预定部署这可能是每夜任务的一部分。作业以一定的间隔（例如每晚或每个周末）触发。由于它是自动的，所以部署作业应该选择最后一次成功构建（然后不需要参数化作业）。


• 每次构建成功时部署作业会触发（不符合您的要求） ，但已列出以完成列表）


• 某些其他（深奥）触发。这可以是许多不同的想法。通过调用构建URL远程触发。呼叫可以来自您的票务系统，测试实验室管理系统或任何其他您喜欢的系统。您还可以通过源代码管理系统中的特定更改（例如更改发布号）（例如，在提交消息中标记关键字）触发部署。这个触发器可以在Hudson内部或外部实现。还有其他触发器。这包括但不限于html页面更改，文件系统的受监视部分上的更改，IM消息，电子邮件。前三个是由Hudson插件实现的。看看插件列表，知道什么是所有可用的
  或者在这两种情况下，您需要确保构建作业存档部署所需的所有工件。

• manually trigger the build. The user that starts the deployment needs to select a specific run of the build job.
• scheduled deployment This could be part of the nightly tasks. The job gets triggered at a certain interval (like every night or every weekend). Since it is automated, the deploy job should pick up the last successful build (you don't need a parametrized job then). You don't have a chance to pass in a run number.
• the deploy job gets triggered every time a build finishes successful (doesn't fit your requirement, but listed to complete the list)
• Some other (esoteric) trigger. This can be many different thinks e.g. remotely triggered by calling the the build URL. The call can come from one of your ticketing systen, test lab management system, or any other system you like. You can also trigger the deployment, by specific changes in your source control system, like changing the release number (e.g. marked by a keyword in the commit message). This trigger can be implemented within or outside of Hudson. There are other triggers available too. This includes but is not limited to html page change, change on a monitored part of the file system, IM message, email. The first three are implemented by a Hudson plugin. Have a look at the plugin list, to know what is all evailable or In both cases you need to make sure that the build job archives all artifacts needed for deployment.

这篇关于配置Hudson以部署构建的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！