Submitted by rtyler on Tue, 2010-06-22 06:00
Last Friday the Hudson team released release 1.363 which is yet another mixed bag of enhancements and bug fixes. Along with the usual bunch of fixes, this release includes a number of localization updates courtesy of a team of Hudson community volunteers participating in the Hudson Internationalization project.
It is also worth noting that this post is being published on Tuesday, contrary to the schedule that I operated on with Continuous Blog, I will no longer be posting release updates on Monday morning. Traditionally Hudson is released Friday afternoon (PST), meaning any potential regressions are reported early on Monday morning after our European users start to upgrade. Publishing this release announcement on Tuesday gives me more time to test out the release so I can report with greater confidence in the reliability of the update. (Note: This may change in the future as we push for easier RC testing capabilities within Hudson)
If you're a regular reader of the Hudson Labs blog, you may also notice that this change log looks eerily similar to the 1.362 announcement from last week. Turns out I had mistakenly taken the upcoming changes from 1.363 and reported them as fixes in 1.362; I've since updated the post regarding 1.362's change log.
Fix queue handling to close locking gap between removing job from queue and starting build,
to prevent unintended concurrent builds (refactor of change first made in 1.360).
Allow multiple dependencies between same two projects, as they may trigger under
different conditions and with different parameters.
Timeline on build trend page should use server timezone instead of always GMT.
Don't mask the cause of the checkout related exception.
"who am I?" page should be visible to everyone.
Reinstall a JDK when a different version is selected.
Avoid pointless and harmful redirection when downloading slave.jar.
Cache downloaded JDKs.
Integrated community-contributed translations (Germany, Greek, Spanish, Finnish, Hungarian, Italian, Japanese, French,
Russian, Slovenian, Dutch, Traditional Chinese, Swedish, Ukrainian, and Portuguese.)
Upgraded bundled Ant to version 1.8.1.
The 1.362 release of Hudson has a few bug-fixes and a few minor enhancements, all together a good stabilization release. Not too much interesting to discuss so straight on to the changelog!
Restored optional container-based authentication for CLI.
Add setting so job views may show only enabled or disabled jobs.
File parameters can now be downloaded from the build Parameters page.
Added an ability to point to different update sites.
Added a new extension point to plug in custom utility to kill processes.
Added a proactive error diagnostics to look for a broken reverse proxy setup.
People often configure Hudson to start a new build whenever a change is made to the repository. In fact, this is often considered central to the practice of continuous integration.
There are two ways to achieve this. One is the "pull" model, where Hudson periodically reaches out to a Subversion repository to see if there is any changes. The other is the "push" model, where you make the Subversion repository reach out to Hudson.
Both approaches have trade-offs. The pull model is easier to configure, since you can do this entirely from Hudson. But this comes at the expense of increased load to the Subversion server. Even though the overhead of Subversion polling is relatively low, as you add more projects to Hudson and increase the polling frequency, the overhead may get non-trivial (imagine the number of Hudson pollings that the poor java.net Subversion server gets, for example.) A more serious downside, in my opinion, is that this increases the delay from your commit to a build. For example, if your build just takes 5 mins, then even if you poll every minute, you pay on average 30 seconds delay before a build starts — a 10% overhead!
A few weeks ago I passed a job listing that I had found through one of my many Google Alerts for Hudson-related queries to Andrew (
abayer), following up on one of those job listings Andrew recently signed an offer to join the nice folks over at Digg to be their resident "build guy." On its own I thought "great for Andrew!" and nothing more, then I saw this thread on reddit which poses the question:
Anyone here a build engineer, or part of the build team? Could you please share your experience?
It seems, to me at least, the notion of "release engineering" is making a come-back, particularly in the aging "Web 2.0" world where companies like Digg, Facebook, Reddit, Twitter, etc are anywhere from five to ten years old. As these companies have aged a couple of important things have happened, their code-base has aged increasing the possibility of bitrot, but they have also expanded in terms of headcount. Start-ups that might have once slighted larger corporations like Oracle, Cisco VMWare and IBM for their burdensome process and longer release schedules now find themselves ensnared with massive code bases, larger development teams and complicated deployments.