I have searched the SO site for question about Hudson but some of it are a little dated now say 2 years or more. Some comments link Hudson as 'newbie' ing the CI Field
I just would like to know if Hudson is mature right now and is the best option for a CI tool.
Thanks
P.S. I just would like to hear latest feedback from community.
I would thoroughly recommend Jenkins, which is a fork of Hudson made in late 2010/early 2011 (wikipedia has more information on the split if you're interested). You'll find more contemporary resources if you do a search for Jenkins - but at the moment most Hudson tutorials are still relevant.
As to stability/maturity, we've been using it for many months without any issues that I'd attribute to maturity :)
We are using Jenkins for our continuous integration and found it quite useful.
All the basics are there, regarding starting builds, getting and generating statistics from i.e. build results, unit tests, function tests. It is also very flexible as you can ask Jenkins to execute a script which does pretty much anything you need.
Jenkins is the best I've tested so far, and also it is free.
I think nobody can answer if it is the best option for you. It might be mature and everything, but that doesn't mean it's the best for your particular problem
Related
I'm some kind of 'Maven expert' in my company, the problem being that I have a good basic knowledge of Maven, but I'm absolutely not an expert when it comes to release, etc...
I'm desperately searching for some kind of good online training for Maven that is not for beginners and that will speak about release and other advanced stuff.
I have no problem to have a course that starts at the very beginning of Maven, but I want to go further than basic dependency management, basic lifecycle and simple project build, my real goal being to be comfortable with full Maven release.
Has anyone a good website, or something for me ?
Thank you,
Seb
This is a question that's broader than just Maven. Because what you do with Maven is determined by the dev process.
If you're interested in general in dev/release process, you could research Continuous Deliver topic as well as Continuous Integration. You could start with Continuous Delivery book which gives a good perspective on both CI & CD (it's pretty boring though).
As for the videos, you could just search in the internet for Continuous Delivery. I like in particular videos from Sam Newman.
As for the Maven itself, there are books like Maven Complete Reference or Apache Maven 2 Effective Implementation (which is a bit old, but Maven was pretty stable from the end user perspective, so not much changed).
What are the current downsides of Gradle? I have been researching different build tools but I haven't seen anything that seems to point out problems with Gradle as of October 2014. I have seen things a bit dated saying that Gradle users are on the bleeding edge. Is that still true or has Gradle reached decent point of maturity? (As far as I know, in terms of ide integration it might be more mature than others). Searching "why not use gradle" doesn't really help and "problems with gradle" shows people getting help (a plus). Most of what I have read were build tool comparisons and newer ones didn't list any flaws of Gradle.
Having not really used gradle except with libgdx projects I can't confirm issues presented in old comparisons still exist, but it seems like they don't.
The one thing I have seen that might be a problem is that it is "slow". If slowness is really an issue please explain how slow and what are the impacts.
Another somewhat reasonable downside is that people need to learn it to use it. To a person knowing how to use 0 tools this isn't really a problem and for others, it seems that Gradle is well documented and easy enough to learn.
I understand there are complications with switching and making sure the build still fully works so I am not asking what are the downsides of switching to gradle specifically but more generally why not use it now in a new project?
Looking for non opinionated reasons/problems.
I am currently using Gradle as part of Android Studio, and its working decently. For me I had a HUGE headache getting started because the default settings of Gradle requires internet connection for the initial build (I assume it was for updates) and it fails to build if it can't make communication with the internet the first time. (so there are some Firewall issue you might need to work around) So the only 'Con' I have to add is that Firewalls can be a problem with initial set up of Gradle.
I'm tasked with migrating our product's build/dependency-management technology from Buckminster to Maven. I'm quite decent with Maven, but before I drill down into Buckminster's inner-workings (which I'm not currently very knowledgeable on), I thought I'd see if there was an available tool to automate this, as it would be a rather lengthy task if done manually. If not, I guess I'll write one myself.
Any input would be much appreciated! Thanks!
It is around 10 months now that Jenkins split off from Hudson.
When looking at the project homepages I am wondering what the differences between Hudson and Jenkins in the meantime really are. From the changelog I do not realy learn much. There are a bunch of changes and the major difference seems to be that Jenkins releases more often with less changes and Hudson less frequently, but then with more changes in a release.
Are there any notable differences yet?
So are there things that make me as a developer needing a CI system more productive rather with the one or the other?
Is one of them more stable than the other?
Is there any difference yet that has nothing to do with politics around Oracle?
What is the most notable difference from your point of view?
One notable difference is that a big number of plugins moved to Jenkins. While you would still be able to use the old versions with Hudson, the newer versions depend on Jenkins already. Also new plugins are mostly created with dependencies on quite recent Jenkins versions, so you probably won't be able to use them without hassle on Hudson.
This will probably differ from plugin to plugin, some might be more compatible with Hudson than others, while still others provide versions for both tools. But if something does not work well with a plugin you will receive help easier if you use Jenkins.
EDIT: Here is an interesting link I found, not only providing some solid numbers on the different paths Jenkins and Hudson have taken, but also addressing the (non-)issue of IP that was mentioned in the other post here...
check out the work being done on cleaning up the code and the IP checks that are needed to belong to Eclipse Foundation. This is one of the big differentiators if you care about clean IP.
How many plugins are you using? Hudson supports many of the most important plugins independently and is working with plugin owners to keep compatibility with those that are still maintained by their owners at Jenkins.
See the JavaOne presentations that show how Hudson is being maintained and new features added.
https://oracleus.wingateweb.com/scheduler/eventcatalog/eventCatalogJavaOne.do (search for Hudson)
Also check out the Hudson project at Eclipse http://www.eclipse.org/hudson/
I'm setting up my team's source control + build/integration process from scratch. We were using VSS and a tool we created in-house to perform the build process. We decided to move on to a more modern environment. I have the SVN running, and I would like to set a continuous integration process with CruiseControl.NET.
Is there a good step-by-step starter guide that will get me started with the best practices of this tool?
Before leveraging CruiseControl to it's fullest extent, you need to create an automated build script that can be run by msbuild or nant. After you get your project building in one step, then you can start integrating CruiseControl into the mix. Here are some resources to help get you started:
CruiseControl.net Wiki - A very good resource.
CruiseControl.net SourceControl Block - Shows how to use svn with CruiseControl.net with the sourcecontrol block
Getting CruiseControl.net, MsBuild, and SVN setup - A resource stepping you through the steps to get everything meshing together.
An excellent resource I've found for CI recently is by Martin Fowler, author of the famous "Enterprise Application Architecture" book.
URL: http://martinfowler.com/articles/continuousIntegration.html
Here are some links that might be useful:
http://www.codeproject.com/KB/dotnet/cruisecontrol_continuous.aspx
http://devlicio.us/blogs/ziemowit_skowronski/archive/2007/03/10/continuous-integration-1-the-environment-and-the-first-build.aspx
http://code.google.com/p/ci-factory/
One tip we have learned - if you have a reasonably large team and the product you're referring to is some "push to QA so people can test" type of scenario, resist the urge to have it build every single time someone checks something in. It will likely take down QA for some amount of time and cause QA to be disrupted a lot before you figure out that people are checking stuff in all day long.
For a "push to QA" scenario, just have it go off every evening if it detects changes.
For a "see if it builds" scenario, once every hour is good (again, people check in stuff way too often on a decent sized team to make instant builds worthwhile)
If you're looking a .NET CI could I suggest you have a look at Team City. I think it's better and it is free for up to 20 users.
Really, the documentation is pretty solid