Subversion、Hudson、Maven、Trac。什么是好/坏?

发布于 2024-10-13 05:45:27 字数 1431 浏览 4 评论 0原文

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

猫七 2024-10-20 05:45:27

我们公司大约 8 个月前开始使用 Maven。它迫使您将项目组织成逻辑模块。之前,我们有两个具有循环依赖关系的客户端/服务器应用程序项目。现在我们有一个用于共享代码的框架项目,以及用于独特内容的单独服务器和客户端项目。我们所有的“独立”应用程序(自定义安装程序生成器等)也可以从框架中分支出来。根据您的设置的复杂程度,“Mavenize”您的项目可能会很耗时。然而,我发现一旦你这样做了,依赖管理之类的事情就不再是一个需要关注的问题了。

Maven 也很有用,因为它可以很好地连接到 Hudson,这是一个持续集成服务器。 Hudson 将为您进行定期构建,无论是定期轮询 Subversion,还是只是每天晚上。它还将使您的所有单元测试自动化(您/正在/使用JUnit或类似的适当框架,对吗?)Hudson 的设置非常简单。您可以立即将其部署到 Tomcat 中,只需进行最少的配置。如果您想使用 Sonar 等工具,它提供了一系列不错的插件选择。

Subversion 是一种相当流行的源代码控制工具。我不介意;这是我最有经验的。我曾经使用过 Mercurial,但还不足以真正将 Subversion 与它进行对比。使用 Subversion 学习的最重要的事情是如何正确地分支和合并。了解这一点将使您能够为不相交的功能请求、错误修复等维护单独的分支。您可以更轻松地为 QA/测试组进行实验构建或特殊构建。合并可能会很痛苦。我听过一些恐怖故事,但我遇到的最糟糕的情况是处理在团队工作时出现的“正常”冲突。

我没有提到 Trac,因为除了以前听说过这个名字之外,我没有任何使用它的经验。 编辑: Google 快速告诉我这是错误跟踪软件。我在 Bugzilla 上运气不错,这是另一个开源错误跟踪器,但正确配置它会让人烦恼,而且由于其权限设置非常挑剔,尤其是在尝试与 suexec 集成时,升级可能会是一场噩梦。青年MMV

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

剪不断理还乱 2024-10-20 05:45:27

我将专注于 Hudson,因为这是我所知道的。首先,一些快速建议:

哈德逊是一个移动的目标。有频繁的发布和许多扩展功能的插件。这既有优点(总是有新的东西)也有缺点(总是有新的东西!)。找到合适的插件来处理构建过程的细节可能很困难。目前,最好的搜索工具是 Hudson 插件页面 上的 Ctrl-F。我建议只安装您将使用的插件,因为如果您安装了所有内容,您最终会得到很多很多配置选项,这些选项可能会使构建设置的导航变得混乱。以下是一些通常有用的插件:

升级(或安装新的
您想要使用的插件),但不断升级只是为了跟上最新的
如果一切都适合您,则无需发布。你会想来的
制定适合您的升级政策。

我之前推荐过这个(在我关于升级的回答的背景下
Hudson
),但我发现拥有一个 Hudson 游乐场很有用
与球队使用的主要哈德逊分开。这让我可以对
在“生产”实例上执行之前进行升级,这是尝试提供更好报告的新功能/插件的简单方法。

对于所有工具,都会有一个学习曲线。尤其是在这种情况下
Hudson 的实验和学习使用它是值得的,因为它
非常强大,它给整个团队带来了以前休息时的力量
在“建造者”的手中。

关于Subversion,我完全同意@Tom的“学习分支和
最近,我一直在使用 git 的 svn 集成 来管理我的
开发工作(请参阅这篇有关 git-svn 的热门博客文章)。 git 让它变得很多
更容易一次处理几个主题并将它们分开,
即我需要进行的错误修复不会干扰我正在使用的功能
正在努力。我建议学习 DVCS 允许的一些技巧
因为扩大视野是一件好事。

I'm going to concentrate on Hudson since that's what I know. First, some quick advice:

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:

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.

羁〃客ぐ 2024-10-20 05:45:27

为了真正能够回答您的问题,您能否分享您正在迁移/从/迁移哪些产品?

我的团队最近从 VSS 迁移到 Subversion,我们喜欢它。它为我们提供了更多的能力和更少的问题。在使用它之前了解它的工作原理非常重要,特别是(正如有人提到的)分支和合并。值得庆幸的是,官方的 Subversion 书籍是免费提供的(只需谷歌“subversion 书籍”)并且写得非常好。特别是,我们喜欢 Subversion 的原子提交、轻松分支的能力、自动处理大多数合并的能力,以及可以告诉您最后更改一行代码的“责备”功能。我们主要不喜欢的是学习曲线。 Subversion 与 VSS 有很大不同,我们的一些老开发人员花了很长时间才习惯它。一些开发人员已经开始使用 git 与 svn 存储库交互,并报告了生产力的提高,但我自己还没有这样做。还有多种可用的 Subversion 工具,因此您可以轻松找到适合您风格的工具。

Trac 不仅仅是一个错误跟踪器。我们刚刚实施了 Trac,它立即引起了轰动。 Trac 能够自动交叉引用存储库提交和票证,这使我们的 QA 团队的工作变得更加轻松。还能够将票证链接到基于 wiki 的文档并通过单个搜索框搜索所有内容,从而可以非常轻松地查找信息并了解您以前未参与过的项目部分。 “里程碑”功能(加上几个插件)正在自动化我们过去手动完成的一些项目管理任务。同样,缺点是学习曲线。它是开发人员必须习惯使用的新东西,并且 wiki 使用必须学习的标记语法。不过,这并不是太大的障碍。在其他两三个团队想要拥有自己的 Trac 之前,我们只让 Trac 启动并运行了一周。我个人很喜欢 Trac 是开源的,并且可以使用一点 Python 轻松扩展。

我没有使用过 Maven 或 Hudson,所以我无法对它们发表评论。

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.

夏尔 2024-10-20 05:45:27

他们都很好。 Trac 不适合我,但这可能是因为我在安装过程中做错了什么。在我工作的地方,我们使用 Subversion、Hudson 和 Maven,效果非常好。您可能还想看看 Nexus 或 Artifactory。

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.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文