Ed Burns

author
+ Follow
since Sep 11, 2006
Merit badge: grant badges
For More
Cows and Likes
Cows
Total received
5
In last 30 days
0
Total given
0
Likes
Total received
1
Received in last 30 days
0
Total given
0
Given in last 30 days
0
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by Ed Burns

Can you make it so Jenkins is a link to hudson-ci.org, then?

Ed
10 years ago
Because mastery of Maven is essential to effectively using Hudson, we cover Maven extensively in our book, "Hudson Continuous Integration in Practice". Here is a little excerpt from Chapter 5: Hudson and Automated Testing.


TIP
Maven is an extreme example of the principle of “inversion of control.” The key to success with Maven is to work with it, not against it. This is best achieved by avoiding trying to change how Maven does things. Rather, it is best to find out the way Maven intends to do the sort of thing you want and then provide input to that process.

All of the action in Maven happens on top of the backbone of the build lifecycle. All of the work done by Maven during a build is done by plugins executing at specific phases during the build lifecycle. Each specific thing that a plugin does is called a “goal.” Plugins typically declare in which lifecycle phases their goals are designed to execute. There are actually three lifecycles that are used in Maven, called clean, default, and site. Every invocation of mvn will use at least one of these three lifecycles. When analyzing its command-line arguments, Maven determines which of the three lifecycles to run and the end phase for each one, based on the order in which the arguments are specified. The clean and site lifecycles deal with running the clean and site goals. Clean resets the project to its nonbuilt state, usually just deleting the target directory. Site generates reports, such as code coverage and unit test results. The default lifecycle is the most interesting and is where most of the work is done by Maven and its many plugins. Hudson jobs that invoke Maven will usually have cause to use all of these different lifecycles in one way or another.
Each of the three lifecycles consists of several different phases, each with a name and purpose and executed in sequence by Maven. Maven always executes at least one of the three lifecycles, and when it does, it always executes them from the start phase until the user-specified end phase. You can think of the execution of the lifecycle phases as a journey on a non-express train from the starting station through multiple stations. When traveling on a such a train from the starting station, you can get off at any station, but no stations can be skipped.



Ed
10 years ago
I think it's interesting that any time the word Hudson appears on this forum, it's automatically formatted into a link to Jenkins!

Touche CloudBees.

Ed
10 years ago
Hello Yvette,

We wanted this book to be much more than just Hudson documentation. We wanted it also to be a guide for how to get the most of Hudson in software development. Rather than type some text, I'll just copy and paste a bit from the chapter itself.


The previous chapter introduced Hudson and explained the process of setting up a working Hudson instance and creating a simple job. One thing that is immediately apparent after completing that first job is the unique nature of Hudson: it’s a product that is only useful in combination with other products. For this reason, skill in using Hudson is only valuable when combined with skill in using the other products with which Hudson integrates. This chapter introduces the tools most commonly used with Hudson, and introduces the software development concepts in which Hudson can play a central role. It is beyond the scope of this book to provide full coverage of all these tools, but references are provided where full coverage can be found.

Hudson in the Software Development Lifecycle

It is difficult to understate the importance of software in history and in today’s economy. Even though software is an extremely recent development in history, it is only the fifth knowledge storage medium in history. Philip G. Armour, in his 2003 book The Laws of Software Process, identifies five knowledge storage media in history: DNA, brains, tools, printed media, and software. The pervasiveness of software and its impact on everyone’s life means that software should be as high quality as possible. To achieve high-quality software, the processes for creating, testing, documenting, delivering, and maintaining software should be as good as possible. This is the purpose of the software development lifecycle.
Though the sole purpose of the software development lifecycle is to make software, many ways have been devised over the years to partition the required tasks, with various names such as “waterfall,” “spiral,” and “agile.” Such topics are well beyond the scope of this book, but all of these approaches are made more successful when automation can be brought to bear in their execution. This is where Hudson comes in. Regardless of the process used for software development, or the number of people involved, Hudson can be used to achieve higher-quality software.



Does this give you a flavor of the chapter? It's only Chapter 2, and its title is Precondition Primer, so you get the idea that it's a chapter that explains stuff that some readers will already know, but hopefully with a fresh perspective.

Ed
10 years ago
That's correct, as far as I know there have been no mergebacks into Hudson from Jenkins.

Ed
10 years ago
Thanks for your question, Hrishikesh.

That's a matter of taste. The subtitle of our book is "Maximize Code Quality and Minimize Software Development Time". I feel that discipline in writing or enhancing testcases for every non-formatting code change does increase the chances that the goal captured in the subtitle of the book will be achieved. Now, technically, you can use Hudson and perform continuous integration and still achieve the subtitle goal even when don't do it before *every* commit. As long as you have some test coverage, you'll still be achieving value because you will be guarding against side-effect regression.

Ed
10 years ago
Hello Bernd,

Our book is squarely and firmly a Hudson book. It doesn't cover Jenkins. However, you must keep in mind that both Hudson and Jenkins are tools that deal with lots of other tools, and the set of those other tools is pretty much identical for both Hudson and Jenkins. So while the book doesn't cover Jenkins, it does cover Maven, and the content about Maven is just as applicable to Jenkins as it is to Hudson, for example.

Ed
10 years ago
Hello Jeanne,

It's a term I made up. I looked around and didn't find a suitable term in the existing literature, and it fit my needs. I wanted to get across that it's all a matter of perspective. One person's production code, which is the code under test, is another person's containing code. For example. In my day job I help maintain an implementation of JSF. For me, that's my production code. However, to most users, that's containing code, because their code runs on top of JSF. This perspective goes all the way down the stack, through the seven layers of the TCP spec, to the bare metal, etc.

Ed
10 years ago
Hello Jeane,

As an advocate of Hudson, I can't speak directly to your question, but I can say the biggest thing is the extent to which the plugins you rely on exist on Jenkins.

Ed
10 years ago
Hello Yvette,

I wouldn't call that misuse, or even underuse. The key value Hudson brings to the picture is to reduce the cost of automation. Even if it's just doing things that you could otherwise do with a cron(8) job, it's still a valid use. Consider the appendix B in the book. This advocates using a personal Hudson instance to automate things such as workspace maintenance on an individual contributor's workstation.

Now, regarding the separate and more interesting question of how easy it is to configure and maintain Oracle's software, that's a product level concern. In my day-job, I work on GlassFish, and I must say that while it's easier to configure than WebLogic, there are still some challenges. What Hudson tries to bring to the picture is to make it possible to get useful things done, even when the other tools in the toolchain are not so well suited to automation.

Ed
10 years ago
Thanks for your question. Let's face it, both Hudson and Jenkins sprung from the same source: the fertile mind of rockstar programmer Kohsuke Kawaguchi. The very reason we have Hudson and Jenkins instead of just Hudson is the competitive impetus of Open Source Software. In my experience in writing the book, and in talking to users at conferences, is that the plugin community and the compatibility of plugins is the biggest difference. Early in the book authoring process, Winston mentioned there were some differences in how Hudson and Jenkins implemented the matrix build concept, but I'm not able to discern that easily.

Ed
10 years ago
I'm going to let Winston talk about this in more detail, but I'm aware that Oracle is leveraging its experience in cloud platforms to bring an end-to-end development experience to the cloud, and also I'm aware that Hudson is at the center of this effort.

Winston?

Ed
10 years ago
Hello ranchhands,

I'm happy to be here. It's nice to talk about something other than JSF for a change!

Ed
10 years ago
http://www.theserverside.com/news/2240146307/Is-Java-ready-for-HTML5

Hello, normally TSS articles have a threaded discussion on them but this one does not. Is there something wrong with the site? Should there be a threaded discussion on that article?

Thanks,

Ed
11 years ago
JSF
It was an impl feature in 2.0. It is required behavior in 2.1.
13 years ago
JSF