不同版本产品的项目结构 [英] Project Structure for Product with Different Versions

查看:25
本文介绍了不同版本产品的项目结构的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们希望开发一种产品并将其交付给多个客户.现在我们有这样的情况,一些客户想要一个额外的特征 x 而另一个客户想要拥有特征 y.部分功能还需要对产品的软件架构进行一些更改.

we want to develop a product and deliver it to several customers. Now we have the case that some customer want to have an additional feature x and another customer want to have feature y. Some of the features also need some changes in the software architecture of the product.

当然,所有客户都希望受益于所有客户定义的官方功能.

And all customers of course want to benefit of the official features definied by all customers.

现在我的问题是如何最好地处理这个问题?我们目前正在使用 SVN 进行版本控制,只要您有一个主干并且可以创建标签,这就会非常有效.

Now my question is how to handle this at the best? We are currently using SVN for versioning and this works really well as long you one trunk and the possibility to create tags.

我知道我们可以为每个客户创建多个主干,然后将所有功能合并到多个客户主干中,但这需要大量手动工作,而且很快就会变得混乱.

I know we can create several trunks for each customer and then merge all features into the several customer trunks but this is a lot of manual work and could get messy very quickly.

感谢您的帮助

推荐答案

这是一个大而毛茸茸的话题 - Martin Fowler 写了一篇很棒的 Feature Branching (http://martinfowler.com/bliki/FeatureBranch.html);还有抽象分支(http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/).

This is a big, hairy topic - Martin Fowler has a great write up of Feature Branching (http://martinfowler.com/bliki/FeatureBranch.html); there's also Branch by Abstraction (http://continuousdelivery.com/2011/05/make-large-scale-changes-incrementally-with-branch-by-abstraction/).

最大的风险是您最终使用 SVN 作为正确"架构的替代品.如果您需要以这种方式支持多个功能,您可能应该构建解决方案以在运行时(通过配置)或在构建时(通过配置)支持它;执行此操作的常用方法是使用插件.

The big risk is that you end up using SVN as a stand-in for a "proper" architecture. If you need to support multiple features in this way, you should probably architect the solution to support this at run time (through configuration), or at build time (through configuration); the common way to do this is to use plug-ins.

使用源代码控制系统合并"功能会使合并过程变得不可预测、不稳定——事实上你可以从另一个分支合并代码并不意味着这一切都有意义——以及开发人员在不同的功能/分支上工作可能会重复彼此的工作,或者在设计上做出相互排斥的决定.

Using your source code control system to "merge in" features makes the merging process into an unpredictable, unstable mess - the fact you can merge in code from another branch doesn't mean that it will all make sense - and the developers working on the different features/branches may be duplicating each others' work, or making mutually exclusive decisions on design.

这篇关于不同版本产品的项目结构的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆