当前位置：文江博客话题详情

源代码控制分支需求

发布于 2024-09-02 13:55:57 字数 377 浏览 2 评论 0原文

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

图片 http://img85.imageshack.us/img85/5074/version.png

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

对于这个问题你有解决办法吗？

哪种源代码控制（SVN、Git、Hg）适合我们解决这个问题？

谢谢。！

原文

分享到QQ

分享到微博

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

发布评论

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

哆兒滾 2024-09-09 13:55:57

好吧，这并不是一个真正的 VCS 问题，这首先是架构问题 - 如何构建和构建您的应用程序，以便您可以根据需要向每个医院提供特定的用例，同时能够正如您所建议的，修复通用代码中的错误。

我认为可以肯定地说，如果您遵循图像中建议的模型，您将无法始终如一且有效地做到这一点。最终您将得到许多不同的、离散的应用程序，即使它们在某些时候来自一组通用的代码，也必须单独维护。

很难做出更好的概括但是我对此的思考方式将是以下几行：

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

然后，您可以为自定义应用程序（每个医院实例）提供多种选项，您可以通过多种方式定义可用功能：

在一种极端情况下，通过配置 - 拥有一个包含所有代码的应用程序并有效地打开和关闭事物基于每个实例。
另一个极端是每个医院都有一个应用程序，该应用程序基本上包含可定制的核心代码。

然而，很可能的是，虽然每家医院的用例总和不同，但各个用例在许多实例中都是常见的，因此您需要瞄准模块化系统，即从公共核心开始并且可以扩展的系统并通过组合进行配置，就像通过任何其他方式进行配置一样。

这意味着您可能希望广泛使用控制反转和依赖注入，以便在通用框架内提供灵活性。您想要查看可扩展性框架（我使用 .NET，所以我会查看托管可扩展性框架 - MEF），它允许您在运行时而不是在编译时“组装”应用程序。

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

一旦您知道如何构建您的应用程序，您就可以查看您的版本控制系统 - @VonC 说得对，他说关键功能是能够将共享项目中的代码包含到多个可交付项目中。

如果是我，现在我可能会有一个核心（它本身可能是多个项目/解决方案），然后每个医院有一个项目/解决方案，但我的目标是在每个医院项目中使用尽可能少的代码- 理想情况下，框架足以定义实例特定配置和 UI 定制

至于使用哪个......如果您是 Microsoft 商店，那么请仔细研究 TFS，拥有良好集成的环境可以提高生产力大量。

否则（无论如何），在我看来，DVCS（Mercurial、Git、Bazaar 等）随着更传统的系统的成熟，似乎正在获得优势。我认为 SVN 是一个优秀的工具（我使用它并且它有效），并且我认为您需要一个用于这种开发的中央存储库 - 尤其是因为您需要触发持续集成服务器的地方 - 但是您可以实现相同的目标DVCS 的特点以及在不“破坏构建”的情况下进行频繁的本地增量提交的能力，以及 DVCS 为您提供的灵活性意味着，如果您现在有选择，那么这几乎肯定是实现目标的方法。 go（但您确实需要确保建立良好的实践，以确保代码尽早推送到您的核心存储库）

我认为纯粹从 VCS 问题来看，仍然有很多需要解决的问题 - 但您无法在有用的情况下解决这个问题详细信息，直到您知道将如何构建交付的解决方案。

Ok, this is not really a VCS question, this is first and foremost and architectural problem - how do you structure and build your application(s) in such a way that you can deliver the specific use cases to each hospital as required whilst being able, as you suggest, to fix bugs in commom code.

I think one can state with some certainty that if you follow the model suggested in your image you aren't going to be able to do so consistently and effectively. What you will end up with is a number of different, discrete, applications that have to be maintained separately even though they have at some point come from a common set of code.

Its hard to make more than good generalisations but the way I would think about this would be something along the following lines:

Firstly you need a core application (or set of applications or set of application libraries) these will form the basis of any delivered system and therefore a single maintained set of code (although this core may itself include external libraries).

You then have a number of options for your customised applications (the per hospital instance) you can define the available functionality a number of means:

At one extreme, by configuration - having one application containing all the code and effectively switching things on and off on a per instance basis.
At the other extreme by having an application per hospital that substantially comprises the core code with customisation.

However the likelyhood is that whilst the sum of the use cases for each hospital is different individual use cases will be common across a number of instances so you need to aim for a modular system i.e. something that starts with the common core and that can be extended and configured by composition as much as by any other means.

This means that you are probably want to make extensive use of Inversion of Control and Dependency Injection to give you flexibility within a common framework. You want to look at extensibility frameworks (I do .NET so I'd be looking at the Managed Extensibility Framework - MEF) that allow you to go some way towards "assembling" an application at runtime rather than at compile time.

You also need to pay attention to how you're going to deploy - especially how you're going to update - your applications and at this point you're right you're going to need to have both your version control and you build environment right.

Once you know how you're going build your application then you can look at your version control system - @VonC is spot on when he says that the key feature is to be able to include code from shared projects into multiple deliverable projects.

If it were me, now, I'd probably have a core (which will probably itself be multiple projects/solutions) and then one project/solution per hospital but I would be aiming to have as little code as possible in the per hospital projects - ideally just enough framework to define the instance specific configuration and UI customisation

As to which to use... if you're a Microsoft shop then take a good long hard look at TFS, the productivity gains from having a well integrated environment can be considerable.

Otherwise (and in any case), DVCS (Mercurial, Git, Bazaar, etc) seem to me to be gaining an edge on the more traditional systems as they mature. I think SVN is an excellent tool (I use it and it works), and I think that you need a central repository for this kind of development - not least because you need somewhere that triggers your Continuous Integration Server - however you can achieve the same thing with DVCS and the ability to do frequent local, incremental, commits without "breaking the build" and the flexibility that DVCS gives you means that if you have a choice now then that is almost certainly the way to go (but you do need to ensure that you establish good practices in ensuring that code is pushed to your core repositories early)

I think there is still a lot to address purely from the VCS question - but you can't get to that in useful detail 'til you know how you're going to structure your delivered solution.

回复收藏 0 原文