问管理开源集成

EN

开源项目喜欢贡献。当您对开源软件进行增强时，请以通用的方式进行，而不是破坏性的。让您的开发人员参与支持软件的社区，并将这些更改贡献给项目。

假设您使用的是1.1.2版本，其中包含自定义特性a、b和c。如果您遵循此建议，那么当项目发布1.2.0版本时，您可以按原样采用它，因为特性a、b和c都包含在主发行版中。

成功并蓬勃发展的开放源码项目使用此模型。没有以这种方式收到捐款的项目通常根本无法生存。因此，你做出贡献的动机是2倍的：

• 如果您确实做出了贡献，您的版本迁移将不会那么痛苦
• 如果您不做出贡献，项目可能会失败，您将被迫将资源投入到采用其他

中

对于这类事情，您有几层质量保证。

1. 开源鉴定。

您必须测试操作系统组件，以确保它们确实可以工作。大多数情况下，这涉及到运行组件提供的测试。

但是，您可能需要特定的功能，或者API或其他任何东西。您必须有一个测试，它可以简单地确定组件完成了您对do.

• Development集成测试的期望。

使用开源组件的开发人员将在需要新版本中的特定新功能时进行集成测试。

如果升级了OS库，您就没有“义务”升级任何东西。毕竟，你不是在为支持付费。你有消息来源了。没有理由“自动”升级您的OS component.

• Production集成测试副本。

升级开源组件时，必须使用应用程序套件进行集成测试。如果这个方法有效，并且投入生产，那么你的所有开发人员都必须进行相同的升级。全盘。

这方面的配置管理非常简单。整个原始发行版必须保存在您的存储库中，并且必须作为应用程序的一部分进行分发。

开源发行版的每个版本都是独立的。你将不得不保留你正在使用的每个版本。你必须把它们分开，这样你才能分辨出哪个是哪个。

/opt/some-package/some-package-1.1/
/opt/some-package/some-package-1.2/
etc.

每个开发人员都应该进行适当的安装。同样，集成测试人员也应该进行适当的安装。此外，一旦通过集成测试，生产环境就必须安装操作系统包。

是的，它将包的一个版本放在多个地方。

是的，您必须弄清楚如何绝对确保产品升级会直接导致每个开发人员也进行升级。您需要某种版本号审计，以确保每个开发人员都拥有正确的OS组件集。