What is the workflow of continuous integration with Hudson?

Today I belong to Hudson.

I had heard of continuous integration before, but I have no idea what kind of Cyprus server it is.

Hudson is really easy to install on Ubuntu, and after a few minutes I was able to install an instance of it.

But I do not quite understand the ci server workflow or how to use it?

Please tell me if you have experience with ci, thanks in advance.

Edit:

I am currently using Mercurial as my SCM, and I am wondering how to use it correctly with Hudson.

I installed Mercurial Plugin from Hudson and I am creating a new task with a local repository. When I commit to the repository, the Hudson job is built with the latest version of my source code.

If I use a remote repository, what is a workflow?

Is this something like the following?

  • Set up a Hudson job in the repository
  • Developer creates a local repository clone
  • Developer Completion and Commit
  • Updating a remote repository using an inbound change set
  • Launch Hudson build

Perhaps something I did not understand at all, please help me point this out.

+6
continuous-integration hudson
source share
2 answers

Continuous integration is the process of "software integration" continuously, as often as possible (ultimately, after each set of changes) in order to avoid large-bang integration and all subsequent problems, receiving immediate feedback.

To implement Continuous Integration, you first need to automate the assembly of your software (where the build tools, of course, compile the sources, package them, but also compile the tests, perform the tests, check the quality, etc., all that will help to get feedback about the health of your code). Then you need to call the assembly on the latest version of the sources on a specific event (a change in the repository, a temporary event) to create reports and send notifications in case of failure (by mail, twitter, etc.).

And this is precisely the duty of the CI mechanism: to offer trigger mechanisms, to get the latest version of sources, start assembly, generate and publish reports, send notifications. CI engines implement this.

And since assembly startup is the intensity of the processor and disk, CI engines usually run on a dedicated machine (or even a farm of machines if you want to build many projects).

Let's get back to your question now. Once you start Hudson, configure it ( Manage Hudson> Configure System ): configure JDK, build tools, etc. Then set up the Hudson Job and follow the steps: set up the location of the source repository, build tool, trigger, notification channel, and you're done (you can do more complicated things, but this is the beginning).

For more configuration information, check:

+8
source share

Martin Fowler Continuous Integration Review is one of the canonical references. In my opinion, using automation to provide a healthy code base is one of the most useful things you can customize.


Refresh Sorry I did not have much time to expand my answer. @Pascal_Thivent is right that in order to use CI effectively, you must be able to automate your builds, tests, etc. CI is actually a good enforcement function for this. For me, this is one of those little warning flags if I start to think that it would be too painful to build the assembly in Hudson. This means that something is wrong.

What I like about Hudson is that it is flexible enough to fit various workflows. We use it for both assembly tests and modules. And this eliminates a lot of concern about some of the release procedures that work only in one person’s environment.

What I don't like about Hudson is that it is sometimes unstable when new builds break plugins. I had several updates (2 out of 10 or so) that do not work well due to incompatibilities. I am doing two things now:

  • I never upgrade my team's Hudson server to the very latest and best right away. I usually update only with significant new features or bug fixes.
  • Now I have a basic Hudson instance configured with all my plugins in a virtual machine with some dummy strings that I run to test any new updates before doing this on a public server.
+7
source share

All Articles