Subversion, Hudson, Maven, Trac. What's good/bad? [closed]
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question 开发者_运维百科Our project is soon migrating to these open source tools. In a proactive effort, I'm wondering from the experts - What you've found to be the good, bad, and uglies about these products? What is less than intuitive? No need to comment on all of them, but feel free if you want!
If this should be a wiki or edited to be more "questiony," please advise or edit. Thanks yall!
Our company started using Maven about 8 months ago. It forces you to organize your project into logical modules. Before, we had two projects for a client/server application, with circular dependencies. Now we have a framework project for the shared code, and individual server and client projects for the unique stuff. All of our 'standalone' apps (custom installer builder, etc) can also branch off of the framework too. Depending on how complex your setup is, it may be time-consuming to "Mavenize" your project. However, I've found that once you do so, things such as dependency management are no longer an active concern.
Maven is also useful in that it hooks nicely into Hudson, which is a continuous integration server. Hudson will do regular builds for you, whether by polling Subversion on some regular basis, or simply every night. It will also automate all of your unit testing as well (you /are/ using JUnit or a similar appropriate framework, right?) Hudson is incredibly simple to set up. You can deploy it into Tomcat pretty much instantly, with a minimum of configuration. It provides a decent selection of plugins if you want to work with a tool such as Sonar.
Subversion is a fairly popular source control tool. I don't mind it; it's what I have the most experience. I've played with Mercurial, but not enough to really contrast Subversion with it. The most important thing to learn with Subversion is how to branch and merge properly. Knowing this will let you maintain separate branches for disjoint feature requests, bug fixes, etc. You can more easily do experimental builds or a special build for QA/your test group. Merging can be painful. I've heard some horror stories, but the worst I've run into is dealing with the 'normal' sort of conflicts that crop up when working on a team.
I've left out Trac because I have no experience with it beyond hearing the name before. Edit: a quick Google informs me it is bug tracking software. I've had decent luck with Bugzilla, which is another open-source bug tracker, but configuring it properly is aggravating and upgrading can be a nightmare due to how picky its permissions setup is, especially when trying to integrate with suexec. YMMV
I'm going to concentrate on Hudson since that's what I know. First, some quick advice:
- Subscribe to the Hudson blog. It's a good place to learn about important changes and best practices.
- Hudson has an API so you can write scripts that integrate with the rest of your environment. The most up to date documentation is in your Hudson server: http://your-hudson-server/api
- For Hudson and Subversion integration, set up a Subversion commit hook to push notifications to Hudson.
Hudson is a moving target. There are frequent releases and a lot of plugins that extend the functionality. That has both advantages (there's always something new) and disadvantages (there's always something new!). It can be difficult to find the right plugin to handle the particulars of your build process. Currently, the best search tool is Ctrl-F on the Hudson Plugins page. I recommend installing just the plugins that you'll use because if you install everything, you'll end up with many, many configuration options that can make navigating your build setup confusing. Here are some generally useful plugins:
- Warnings
- Hudson Release
- xUnit
- Sectioned View
It's typically easy and relatively painless to upgrade (or install that new plugin you want to use), but constant upgrades just to keep up with the most recent release are unnecessary if everything is working for you. You'll want to come up with an upgrade policy that works for you.
I've recommended this before (in the context of my answer about upgrading Hudson), but I find it useful to have a Hudson playground that's separate from the main Hudson that the team uses. That lets me do a sanity check on an upgrade before performing it in on the "production" instance and it's an easy way to try out new features / plugins that provide better reporting.
For all of your tools, there will be a learning curve. Especially in the case of Hudson, it pays off to experiment with it and learn to use it because it's very powerful and it gives the whole team the kind of power that used to rest in the hands of the "build guy."
Regarding Subversion, I totally agree with @Tom's "learn to branch and merge" advice. Lately, I've been using git's svn integration to manage my development work (see this popular blog post about git-svn). git makes it much easier to work on a couple of topics at a time and keep them separate, i.e. the bug fix that I need to make doesn't interfere with the feature I'm working on. I recommend learning some of the tricks that DVCS's allow because expanding your horizons is a good thing.
To really be able to answer your question, can you share what products you are migrating /from/?
My team recently moved from VSS to Subversion and we love it. It gives us significantly more capabilities and far fewer problems. It is important that you learn how it works before using it, especially (as someone mentioned) branching and merging. Thankfully, the official Subversion book is freely available (just google "subversion book") and very well-written. In particular, we enjoy Subversion's atomic commits, the ability to easily branch, the ability to handle most merges automatically, and the 'blame' feature which can tell you who last changed a line of code. Our main dislike was the learning curve. Subversion is quite different from VSS and it took some of our older developers quite a while to get used to it. Several devs have started using git to interface with the svn repository and have reported improved productivity, but I haven't done that myself yet. There are also a wide variety of Subversion tools available, so its easy to find one that fits your style.
Trac is much more than just a bug tracker. We just implemented Trac, and it has been an instant hit. Trac's ability to automatically cross-reference repository commits and tickets is making our QA team's job much easier. Being able to also link a ticket to the wiki-based documentation and searching through everything from a single search box makes it very easy to locate information and learn about parts of the project that you haven't worked on before. The "milestone" feature (plus a couple of plugins) is automating some of the project management tasks that we used to do by hand. Again, the downside is the learning curve. Its something new that developers have to get accustomed to using, and the wiki uses a markup syntax that has to be learned. It's not too big of a hurdle, though. We only had Trac up and running for a week before two or three other teams were wanting their own. I personally enjoy the fact that Trac is open-source and easily extendable with a little Python.
I haven't used Maven or Hudson, so I can't comment on those.
They are all good. Trac did not work for me, but this might because I did something wrong during installation. Where I work we use Subversion, Hudson and Maven and that works really well. You might want to have a look at Nexus or Artifactory as well.
加载中,请稍侯......
精彩评论