Continuous integration tool hudson(Continuous Integration)CI

1. What is
continuous integration? The core concept of continuous integration The
CI process often builds software components; in many cases, software components are built whenever the code in a source code repository (such as Subversion or ClearCase) changes. The benefit of CI is that building software frequently ensures that problems (such as code defects) are encountered early, before problems are discovered later in the software development cycle when they become complex.
Tools and Processes
Although CI is actually a process, the term continuous integration is often associated with one or more tools. In this tutorial, I'll show you how to install, configure, and use Hudson as a CI server, but keep in mind that CI is much more than a tool. In practice, the tools used can be a relatively minor aspect of CI, since all a CI tool does is run a build when a modification is detected in the code repository. The build process itself is far more important than the tool used to run it.
Getting started with CI Getting
started with CI requires three components:
An automated build process with tools like Ant or Maven
A code repository, such as CVS or Subversion
A CI server, such as Hudson, but cron jobs can also suffice.
Let 's discuss these in detail components.
Automated build
CI processes will often integrate software, which needs to be done through builds. In the Java environment, Ant is a commonly used build platform. Tasks such as compilation, testing, and even software inspection and deployment can be reliably automated using Ant. Once you have mastered all the components of CI, you will find that a build strategy is the most important aspect of a successful CI process. Without a proper build process, CI is difficult to function.
source code management
For CI to function properly, a source code management (SCM) system or repository, such as Subversion or CVS, is required. The CI server queries the SCM repository for code modifications. When a modification is found, the CI server performs a checkout (i.e. updates the local sandbox) and performs a build. The build process is the same as the build performed in the local environment, except that it is executed more frequently.
CI Server
For a successful CI process, it is also very important to have an automated process that monitors the SCM repository and runs builds when changes are detected. For the Java platform, there are many CI servers available, including open source software and commercial products. They all have a similar basic configuration, suitable for monitoring a specific SCM and running a build when a modification is detected. All CI servers have their own pros and cons. Hudson is of particular interest because of its ease of configuration and powerful plugins that display information such as test result trends.

2. Introduction to

Hudson Hudson is a revolutionary open source CI server that draws many lessons from previous CI servers. One of Hudson's most attractive features is that it's easy to configure: it's hard to find a CI server that's easier to set up, or one that's so feature-rich out of the box. The second reason Hudson is easy to use is that it has a powerful plugin framework, so it's easy to add features. For example, a Hudson plugin can track FindBugs and code coverage over time. It can also report trends in test results (from JUnit or TestNG) as well as build results and corresponding execution times.

Hudson requires Java 5 to run. If you need to use a container other than the embedded container (Winstone) that comes with Hudson, then just use a Servlet 2.4 container. For most cases, Winstone is sufficient.


3. Hudson use

The final aspect of the CI process is the CI server itself. The primary role of a CI server throughout the development process is that of a controller: when the server detects a modification in the code repository, it delegates the task of running the build to the build process itself. If the build fails, then the CI server will notify the relevant parties and continue to monitor the repository. Its role appears to be passive; however, it is the key to responding quickly to problems.

Installing Hudson

One of the main benefits of using Hudson is that it's easy to set up. In the simplest case, Hudson requires only two steps:

download the latest version (which is packaged as a WAR file). Hudson official website: https://hudson.dev.java.net/
run java -jar hudson.war.
that's it. Because the download is a WAR file, you can deploy it in a container such as Tomcat or JBoss if you prefer. This is entirely up to you. Of course, Hudson assumes Java 5 is running on the machine where it is installed, and if the JAVA_HOME environment variable is defined, Hudson will use it. (As mentioned earlier, Hudson requires Java 5.)

After installing and running Hudson (deploy the WAR file to a servlet container or execute java -jar hudson.war from the command line), start a browser and visit the default installation location. If you are running Hudson from the command line and you are on your local machine, you can visit http://localhost:8080/.

Guess you like

Origin http://10.200.1.11:23101/article/api/json?id=326995951&siteId=291194637