源控制分支需求

时间:2010-05-23 15:16:21

标签: version-control

我们正在创建医院信息系统软件。该项目将是不同的医院和医院,并包含不同的用例。但很多部分都是一样的。所以我们将使用源代码控制的分支机制。如果我们在一家医院发现了一个错误,我们怎么知道其他分支机构是否有相同的错误。

IMAGE http://img85.imageshack.us/img85/5074/version.png

我们附上的图片中的数字显示了每个医院的软件。

你有解决这个问题的方法吗?

哪个源控件(SVN,Git,Hg)我们会适合这个问题?

谢谢。!

2 个答案:

答案 0 :(得分:0)

您提到的所有VCS(版本控制系统)都与“共享组件”的概念兼容,它允许您定义公共共享和部署的代码库,以及每个分支中的一些专业化:

<强> CVCS (Centralized)

<强> DVCS (Distributed)

考虑到发布管理过程的分布式方面,DVCS会更合适 如果错误位于公共代码库中,您可以快速查看其他分支中的:

  • 他们所指的共同组件的确切版本。
  • 他们引用该公共组件的相同或较旧版本,而不是发现错误的版本(在这种情况下,他们也有可能存在错误)

答案 1 :(得分:0)

好的,这不是真正的VCS问题,这首先是体系结构问题 - 如何构建和构建应用程序,以便您可以根据需要将特定用例交付给每个医院如你所知,能够修复通用代码中的错误。

我认为可以肯定地说,如果您按照图像中建议的模型进行操作,则无法始终如一地有效地执行此操作。你最终得到的是许多不同的,离散的应用程序,它们必须单独维护,即使它们在某些时候来自一组通用的代码。

很难做出更好的概括我想到的方式将是以下几点:

首先,您需要一个核心应用程序(或一组应用程序或一组应用程序库),这些将构成任何交付系统的基础,因此也是一组维护的代码(尽管这个核心本身可能包含外部库)。

然后,您可以为自定义应用程序(每个医院实例)提供多种选项,您可以通过多种方式定义可用功能:

  • 在一个极端,通过配置 - 让一个应用程序包含所有代码,并在每个实例的基础上有效地打开和关闭事物。
  • 在另一个极端,每个医院的应用程序基本上包含定制的核心代码。

然而,可能的情况是,尽管每个医院的用例总数不同,但个别用例在多个实例中都是常见的,因此您需要针对模块化系统,即从共同核心开始的事情。可以通过组合扩展和配置,也可以通过任何其他方式进行扩展和配置。

这意味着您可能希望广泛使用Inversion of Control和Dependency Injection来为您提供通用框架内的灵活性。您想要查看可扩展性框架(我做.NET,因此我将查看Managed Extensibility Framework - MEF),它允许您在运行时而不是在编译时“组装”应用程序。

你还需要注意你将如何部署 - 特别是你要更新的方式 - 你的应用程序,此时你是对的,你需要同时拥有你的版本控制和你建立了正确的环境。

一旦你知道你将如何构建你的应用程序,那么你可以看看你的版本控制系统 - 当他说关键功能是能够将共享项目中的代码包含到多个可交付项目中时,@ VonC就是现货。

如果是我,现在,我可能有一个核心(可能本身就是多个项目/解决方案),然后是每个医院的一个项目/解决方案,但我的目标是尽可能少的代码每个医院项目 - 理想情况下,只有足够的框架来定义特定于实例的配置和UI自定义

至于使用哪个......如果你是微软的商店,那就仔细研究一下TFS,拥有一个良好的集成环境可以提高生产力。

否则(无论如何),DVCS(Mercurial,Git,Bazaar等)在我们成熟时似乎在更传统的系统上获得优势。我认为SVN是一个很好的工具(我使用它并且它可以工作),我认为你需要一个中央存储库来进行这种开发 - 尤其是因为你需要一个触发你的持续集成服务器的地方 - 但是你可以实现同样的目的DVCS的功能和能够频繁进行本地,增量,提交但没有“破坏构建”的能力以及DVCS给你的灵活性意味着如果你有一个选择现在那么这几乎肯定是通往go(但你确实需要确保建立良好的实践,以确保代码尽早推送到您的核心存储库)

我认为纯粹从VCS问题中解决的问题还有很多 - 但是你无法详细了解这一点,直到你知道如何构建交付的解决方案。