As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
It took me an hour or so to work out Hudson has only branched recently (Jan/2011)
I have no idea how rapid the change of each branch is now, but more importantly, what is the direction each branch is taking and what are key points so one could make a choice between which to go with?
Anybody have links to product roadmap and feature differences?
Use Jenkins.
Jenkins is the recent fork by the core developers of Hudson. To understand why, you need to know the history of the project. It was originally open source and supported by Sun. Like much of what Sun did, it was fairly open, but there was a bit of benign neglect. The source, trackers, website, etc. were hosted by Sun on their relatively closed java.net platform.
Then Oracle bought Sun. For various reasons Oracle has not been shy about leveraging what it perceives as its assets. Those include some control over the logistic platform of Hudson, and particularly control over the Hudson name. Many users and contributors weren't comfortable with that and decided to leave.
So it comes down to what Hudson vs Jenkins offers. Both Oracle's Hudson and Jenkins have the code. Hudson has Oracle and Sonatype's corporate support and the brand. Jenkins has most of the core developers, the community, and (so far) much more actual work.
Read that post I linked up top, then read the rest of these in chronological order. For balance you can read the Hudson/Oracle take on it. It's pretty clear to me who is playing defensive and who has real intentions for the project.
As chmullig wrote, use Jenkins. Some additional points:
In fact, arguably it was Oracle who did the forking! And technically, too, that's kinda what happened.
It's interesting to see what comes out of "Hudson" though. While the "Winston summarizes the state and rosy future of the Hudson project" stuff they posted on the (new) Hudson website originally seemed like odd humour to me, perhaps this was a purposeful takeover, and the Sonatype guys actually have some big ideas up their sleeve. This analysis, suggesting a deliberate strategy by Oracle/Sonatype to oust Kohsuke and crew to create a more "enterprisy" Hudson is a very interesting read!
In any case, this brief comparison a fortnight after the split—while not exactly scientific—shows Jenkins to be by far more active of the two projects.
...and a little background info:
The creator of Hudson, Kohsuke Kawaguchi, started the project on his free time, even if he was working for Sun Microsystems and later paid by them to develop it further. As #erickson noted at another SO question,
[Hudson/Jenkins] is the product of a single genius
intellect—Kohsuke Kawaguchi. Because
of that, it's consistent, coherent,
and rock solid.
After the acquisition by Oracle, Kohsuke didn't hang around for long (due to lack of monitors...? ;-]), and went to work for CloudBees. What started in late 2010 as conflict over tools between the dev community and Oracle and ended in the rename/fork/split is well documented in the links chmullig provided. To me, that whole conundrum speaks, perhaps more than anything else, to Oracle's utter inability or unwillingness to sponsor an open-source project in a way that keeps all parties (Oracle, developers, users) happy. It's not in their DNA or something, as we've seen in other cases too.
Given all of the above, I would personally follow Kohsuke and other core developers in this matter, and go with Jenkins.
Just my take on the matter, three months later:
Jenkins has continued the path well-trodden by the original Hudson with frequent releases including many minor updates.
Oracle seems to have largely delegated work on the future path for Hudson to the Sonatype team, who has performed some significant changes, especially with respect to Maven. They have jointly moved it to the Eclipse foundation.
I would suggest that if you like the sound of:
less frequent releases but ones that are more heavily tested for backwards compatibility (more of an "enterprise-style" release cycle)
a product focused primarily on strong Maven and/or Nexus integration (i.e., you have no interest in Gradle and Artifactory etc)
professional support offerings from Sonatype or maybe Oracle in preference to Cloudbees etc
you don't mind having a smaller community of plugin developers etc.
, then I would suggest Hudson.
Conversely, if you prefer:
more frequent updates, even if they require a bit more frequent tweaking and are perhaps slightly riskier in terms of compatibility (more of a "latest and greatest" release cycle)
a system with more active community support for e.g., other build systems / artifact repositories
support offerings from the original creator et al. and/or you have no interest in professional support (e.g., you're happy as long as you can get a fix in next week's "latest and greatest")
a classical OSS-style witches' brew of a development ecosystem
then I would suggest Jenkins. (and as a commenter noted, Jenkins now also has "LTS" releases which are maintained on a more "stable" branch)
The conservative course would be to choose Hudson now and migrate to Jenkins if must-have features are unavailable. The dynamic course would be to choose Jenkins now and migrate to Hudson if chasing updates becomes too time-consuming to justify.
Up front .. I am a Hudson committer and author of the Hudson book, but I was not involved in the whole split of the projects.
In any case here is my advice:
Check out both and see what fits your needs better.
Hudson is going to complete the migration to be a top level Eclipse projects later this year and has gotten a whole bunch of full time developers, QA and others working on the project. It is still going strong and has a lot of users and with being the default CI server at Eclipse it will continue to serve the needs of many Java developers. Looking at the roadmap and plans for the future you can see that after the Maven 3 integration accomplished with the 2.1.0 release a whole bunch of other interesting feature are ahead.
http://www.eclipse.org/hudson
Jenkins on the other side has won over many original Hudson users and has a large user community across multiple technologies and also has a whole bunch of developers working on it.
At this stage both CI servers are great tools to use and depending on your needs in terms of technology to integrate with one or the other might be better. Both products are available as open source and you can get commercial support from various companies for both.
In any case .. if you are not using a CI server yet.. start now with either of them and you will see huge benefits.
Update Jan 2013: After a long process of IP cleanup and further improvements Hudson 3.0 as the first Eclipse foundation approved release is now available.
Jenkins is the new Hudson. It really is more like a rename, not a fork, since the whole development community moved to Jenkins. (Oracle is left sitting in a corner holding their old ball "Hudson", but it's just a soul-less project now.)
C.f. Ethereal -> WireShark
I've got two points to add. One, Hudson/Jenkins is all about the plugins. Plugin developers have moved to Jenkins and so should we, the users. Two, I am not personally a big fan of Oracle's products. In fact, I avoid them like the plague. For the money spent on licensing and hardware for an Oracle solution you can hire twice the engineering staff and still have some left over to buy beer every Friday :)
For those who have mentioned a reconciliation as a potential future for Hudson and Jenkins, with the fact that Jenkins will be joining SPI, it is unlikely at this point they will reconcile.
From the Jenkins website, http://jenkins-ci.org, the following sums it up.
In a nutshell Jenkins CI is the leading open-source continuous integration server. Built with Java, it provides over 300 plugins to support building and testing virtually any project.
Oracle now owns the Hudson trademark, but has licensed it under the Eclipse EPL. Jenkins is on the MIT license. Both Hudson and Jenkins are open-source. Based on the combination of who you work for and personal preference for open-source, the decision is straightforward IMHO.
Hope this was helpful.
Related
Im doing research regarding continuous integration tools and there benefits. For my research im looking at the following tools:
GitLab CI
Jenkins
Bamboo
GoCD
TeamCity
Now I wont bother you with all the requirements and benefits. But so far im not finding so many differences between the tools except for these:
Fan-in fan-out support GoCD
Community size, Jenkins and GitLab seem to have most contributors
Costs
Open source or not
Amount of plugins available
I was wondering if some people who have had to choose a continuous integration tool aswell could share there experience and why they chose that tool and if there are certain differences that are worth thinking about before choosing which I didn't cover.
Now im leaning towards GoCD because of fan-in fan-out support and the visualisation of the continuous delivery pipeline does anybody have experience with the support on issues for this tool?
Thanks in regard,
Disclaimer: I was an active contributor to GoCD before previous Fall.
I haven't used GitLab CI so won't talk about that :) Also, I haven't used any of these tools in the past one year.
I think TeamCity is a good CI tool. It integrates very well with IDE if you want to debug some failures. The test reports are brilliant. But I don't think they are that advanced in CD space and in my opinion you need both. But if you are interested only in CI, you might want to give it a look. However, you will miss on some of the good features of GoCD I've mentioned below.
Jenkins has a huge community but Jenkins has its own disadvantages. Many a times one plugin doesn't work due to another plugin for some compatibility issues for instance.
GoCD has Fan-in/Fan-out support which avoids many unnecessary builds saving a lot of build time and resources. The value stream map is intuitive and helps to get a better picture of the build stage from a developer's, QA's or even Deliver Manager's point of view. The pipeline modeling in GoCD is also very good. If you read Jez Humble and David Farley's book on Continuous Delivery, you will see the power behind such a build design.
Now, to your second question:
Now im leaning towards GoCD because of fan-in fan-out support and the
visualisation of the continuous delivery pipeline does anybody have
experience with the support on issues for this tool?
Good to hear that :P I love GoCD. The support is good. If you choose to go the Open Source way, the mailing list is pretty active. You can expect a reply from the GoCD team within a day or two. Of course, your questions have to be genuine and specific. Looking through the forums before posting a question helps :)
You can also choose to buy support for GoCD from ThoughtWorks. They used to offer multiple support tiers, not sure of the current support model. You might face issues only when your DB grows too huge (~5-7 GB) when you might want to go for the proprietary Postgres DB support from ThoughtWorks. I've seen very few users of GoCD with that DB size.
I have a lot of experience with Teamcity and some with Gocd. If you are interested in fan-in/fan-out it's also possible to do the same in Teamcity -- it's called Build Chains.
Also there is a good post about this topic on official blog.
If I could choose I would prefer Teamcity. It's more mature and more feature rich product suitable for use in corporate environment.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I know there are some questions already regarding Plastic SCM, but they are over a year old. Has anyone used Plastic SCM lately? What do you think about it.
I have used git, and I am currently using Hg. I love the Hg source control, but Visual Studio integration is not great, and related task/project management tools have not been great. Plastic SCM was recommended, but I like to get a community view on it. - And no, I don't care about grammar on the website. I prefer well engineered solutions to well marketed websites.
Yes, we use Plastic SCM (small team of 5) for 2 years already and it works great and even gets better every update!
Support is very good (within an hour or at least the same day a response!).
Also branching and merging works very good in practice. Every programmer can work on it's own in his own branch (using branch per task pattern). Such a big relief. When you switch to another branch all changes are automatically shelved/stored on the server. When you switch back, the changes are reloaded, which is a really nice feature! You don't have to worry to loose changes, because Plastic handles everything very good.
Without doubt Plastic SCM is the best Version Control System I've ever seen (used MS Sourcesafe, CVS, SVN, StarTeam). Also heard of other's the branch support is much better than MS Team Foundation.
We have used Plastic SCM for a few years already and it has evolved a lot. The integration with Visual Studio is pretty good, you have all the graphical views of their visual client inside VS.
The biggest challenge was the switch to the branch per task thing, kind of a best practice to use it. But now when we have to use SVN for a project, we miss our task branches.
we use Plastic SCM allready for over two years. it's probably the best product for doing SCM. Having used PVCS, Subversion and ClearCase in the past. I definitely recommend using the branch per task approach used in Plastic. It makes your integration work so easy.
Using scrum or another extreem programming process, plastic enables you to control the code in a very easy way.
Plastic is also evolving very fast and has a very strong technical team behind its development.
I made some investigation, in 2010, for my company considering PlasticSCM as option. I found some places to improvement which was critical for our company. I made this being in touch with really fantastic, extraordinary and responsive Plastic SCM Support Team.
The problem is missing triggers for push/pull operations. Also internal/external API is not done yet (but You can find some examples of plugins available at PlasticSCM's forum). Without hooks working on central server there is no way to use Plastic SCM in distributed scenario at our company. That is why we choose Git.
Second thing is not missing, but not released support for PostgreSQL. I red on forum You can ask about such ability - and PlasticSCM posses such code somewhere.
PlasticSCM contain so many functions available as plugin and so rich GUI that You want to implement something more "inside". But we still wait for some API to released. I can't wait this.
There is also no floating/enterprise licences and current, "per user", licence model is very expensive. Of course You can contact with sales :)
I have been using plastic now for about 3 years. It simply is the best Version Control Software out there. Excellent support and responsive feedback. Now it integrates with Git also. Excellent UI and all commandline capable as well. Xlinks are a very cool feature and now you can have writeable XLinks.
What would be the best tool to use that can support cross platforms, remote builds and deployment for windows, linux and macosx and cost effective?
Right now were using Groovy(grails), Java, and .NET
Thanks
Your requirements are pretty vague, so expect vague answers. Hudson sounds like it would be a reasonable fit (cross platform, remote builds, etc), but your best bet is to actually try it! Hudson has a good community and plenty of activity. Read the wiki, search the mailing lists and ask questions when you get stuck.
The "cost effective" requirement is nearly impossible for an outsider to measure because we have no idea what tradeoffs you're willing to make with build vs buy, nor do we know how valuable your time is compared to your money.
Wikipedia's Comparison of Continuous Integration software may be helpful if you want an overview of what else is out there.
My company uses Bamboo. I can recommend it as a decent product. I have not used Hudson extensively enough to say that it's better, although my limited experience with it says that it is at least as good.
The fact Hudson is free has to be one plus for it.
Try them both out, and see which you like better. Bamboo has a 30 day free trial. link
One thing about Bamboo that has been a negative is that we have a huge number of plans, and plan maintenance and creation is all Web GUI driven. There is very little room to automate plan creation, from my experience. I believe Hudson "plans" can be created almost on the fly via command line arguments.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
What is a best way to organize many software development projects, interaction with clients, project documentation, sources, emails, knowledge, time tracking, issue and features tracking, support for releases and versions etc. for a small company?
For me (and I believe for many others) it is obvious that it must be some sort of web-based solutions. It would be great if it could provide an interface for iPhone (if not, it is also OK).
Important thing: it must be hosted on our servers, so PHP + MySQL is the best platform so far.
I have found the following system to consider:
http://www.activecollab.com/ (but I didn't found issue tracking as well as support for releases and versions, so it is not the best match for software development company)
http://www.mantisbt.org/ (Great tool, but no project planing...)
http://www.twproject.com/ (didn't try yet, but it has very strange interface)
But none of them is a 100% solution for me.
It also should (but not must) support SCRUM
We have about 25 people in our team and about 50 from client side. At once we run about 3-7 projects (some in dev. phase, some in support).
So, my questions: does anybody knows any good web-based system that gives everything software development company needs? I believe this information will be useful for many of us.
I would recommend FogBugz
They have a very interesting (admittedly not everyone's cup of tea) scheduling system and is apparently supporting scrum.
Their support for release management is something i'm particularly fond of, but i should also say that i have very little experience of other similar systems.
Another feature that I like is the ability to link different e-mail accounts as well as pure HTML forms to different projects.
Oh, and it is not a MySQL/PHP solution.
Some of the features are:
Issue tracking
Project planning
Scheduling
Customer support
Wiki
References:
Scrum and Fogbugz / Fogbugz questions / FogBugz Knowledge Exchange
I think it really depends on your company size. I used activecollab for a while but it never really convinced me and then they made it commercial anyway. There is an open source fork of it called ProjectPier.
Even if it is not MySQL + PHP but Ruby On Rails Redmine convinced me the most from all tools I tried (and installing the ruby module into apache is a question of 5 minutes). It is simpel and yet has anything I need (including Eclipse Mylyn, SCM integration, E-Mail Notification and time tracking). With a little RoR knowledge it is easily customizable, too.
The most popular Open Source sollution is probably Trac. It is written in Python, so it is not a PHP either.
But maybe it makes sense to consider a non PHP sollution. I didn't find any PHP open source tool that had the functionality and simplicity of Redmine or Trac. If you don't mind a hosted sollution Basecamp is probably the first address to turn to (never tried it though).
Trac with Agilo plugin might be a good option.
Here is link for Trac pluigns, some category are:
Code Documentation
User feedback and discussions
For another pespective - having used many of the above solutions, and liking them very much for bug tracking, wiki documentation and tracking information - I tend to move towards keeping much of my project "meta-data" (summary information pulling together wiki, bugs, schedules, communication) in spreadsheets now.
For those now climbing onto the top rope of the ring preparing for a takedown, here's why... I come from a programming background, and one of the best books I read early in my career was The Pragmatic Programmer. One of the tenets they preach is finding a fundamental editor that you like, and get good with it (for various Very Good Reasons). After trying (frustratingly) to port and adapt my PM/Dev Management approach multiple times to multiple systems, I've extrapolated that Pragmatic tooling philosophy to the product/project management world I now inhabit. To stretch the metaphor, my editor is now Excel.
I can't guarantee that for any company I work with, they have "Software Project Management xyz" or "Bug Tracking System abc" with the proper plugins - but I can be darn well sure they have Excel or some variant available. I know if I get ninja-like with that tool, I can continue to use it - and focus on the project, not the tools.
This spreadsheet approach comes with some caveats:
Excel done poorly can suck. We've all seen that. Watch for bloat and stupidity.
Keep the bugs in the bug tracking system, the wiki stuff in the wiki. The spreadsheet is meant to pull this stuff together, not replace it.
Keep it readable. Don't stuff everything in just because you can. Summary sheets are good.
Try to standardize your templates and macros meaningfully for tasks and information, to maximize reuse over time and projects. Just like good programming.
Back it up - use a document management system if you can. This approach isn't in the cloud or hosted centrally by default, so be aware of that.
Have you tried Assembla? They've recently released a new product called Portfolio which is great if you have to manage multiple projects + you get free clients! :)
You might like to consider http://targetprocess.com/ We use that in my current job and it works pretty well, from a developer point of view. I'm unsure as to whether it supports your installation requirements, however.
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 11 years ago.
Improve this question
Is Microsoft Project the best tool for managing software development or IT projects or is there an alternative that is better?
Project is not good for managing development at all. I find it marginally useful for scheduling / work breakdown.
If you're on a Microsoft stack, Team Foundation Server is a good project management solution. It integrates with Project for scheduling and also provides the essentials of source control, work item (task / defect) tracking, and document management (via sharepoint.) The 2008 version has matured nicely, and the 2010 version looks very promising, especially in the area of requirements specification and traceability.
You can replicate the TFS features with a stack of open source and/or less expensive off-the-shelf software, but it is more work to integrate. It's debatable which is more flexible and easier to maintain once set up.
The following are required, regardless of platform:
Bug tracking
Work item / story / progress tracking of some kind (may be managed by above)
Collective team discussion (may be managed by above - discussion on work items, like FogBugz for example)
Source control (anything but SourceSafe)
Continuous build integration that runs unit tests
Instant messaging (OpenFire works great if your network blocks external services)
Document library
Farm of virtualized test machines (especially useful for install/upgrade testing)
I tend to use MSProject for capacity planning - a nice big broad brush of who could do what over a period, at a level of abstraction that makes it easy to rejig plans. For day to day tracking of the real work, I use Fogbugz. I think of it as MSProject/Gantty stuff for the strategic planning, and Fogbugz for the tactical management and planning.
Depends on the process you're using - if it's a waterfall like process, or there's a lot of non-software parts of the project (infrasstructure, manufacturing, marketing etc) then Project's OK for the overall task management - it's certainly competitive with other similar tools.
I don't think any of the "project management" tools (tasks, WBS, gannt charts etc) are much good at the management of the detailed tasks that happen when you're into the main software development phase - I usually end up in Excel for the projects I'm involved in.
And of course, there is much more to the successful management of a non-trivial software project than the bit that can be managed with a tool like Project. It doesn't help much with managing the requirements, issues, defects, meetings, test development etc - but then it's not supposed to.
Because of these limitations, I find I usually get most value out of Project in the planning phase - working out the task breakdown, what needs to be done, and roughly what needs to happen in what order.
As Eisenhower put it: "In preparing for battle I have always found that plans are useless, but planning is indispensable." MS Project is a useful tool for planning.
If also need a free and open alternative to Project, you have OpenProj: http://openproj.org/openproj
We use Target Process here. It has a few "-isms", but overall is a good agile project management tool
We've been successfully using MS Project for planning but were missing the ability to share MS Project plans with customers and colleagues who don't have it installed. This led us to the idea of online Microsoft Project viewer - a service that would allow to view and share MS Project files (.mpp) online, apart from MS Project:
Hope this helps.
We use Acunote at my work place, but we follow a Agile/Scrum methodology.
What constitutes the "best tool" depends on many things. How you run your projects, who will be using them, etc.
There are many better alternatives, at least for software development. One such is embedded in Microsoft Visual Studio Team System. You may also want to check out tools from Rally Software and Version One. The latter are well suited to agile methods, while the former supports both agile and traditional CMM methods.
Well, given the fact that not even the Project team uses Project for Project (Source: Joel Spolsky), I would not want to use it for development.
I track my development tasks in our Bug Tracker, and the Project File just has something like "Planning 1 Week, Development 5 Weeks, QA 3 Weeks, Deployment 1 Week", aka. a VERY broad overview.
As for the BugTracker, FogBugz has this nice Estimate-Tracking that I find quite useful for making schedules, which is for me just another reason to not use Project.
But then again, I am not a Project Manager, so to me, Project is just an unnecessary complex, not really multi-user friendly and somewhat dated-feeling Tool to be used when building Houses, Highways or Space Stations, but not for Software.
We use Primavera on my project. Its supposed to be great although its the only tool I haven't really used for project management so far so I can't really compare it to anything else. Its not that easy to pick up but it can do everything I need (and apparently much more).
My favourite feature is the built in timesheets functionality which means my developers can book their hours to their tasks at the end of the week meaning that I don't need to constantly bug them about how they are progressing against their plans.
personally i dont believe ms project is good for software dev (i have used it, im not bashing it to be a purist)
its great if you are building a house or something which doesnt have such uncontrollable variables (e.g. how many bugs will you have? how long will bugs take to fix? how much feature-creep will there be?)
i like to keep my schedules very simple so more people can understand them, hence why i just use a google spreadsheet
the structure i use is described further here: Project Schedules with Google Spreadsheets
hope this helps
--LM