数据迁移脚本步骤_将封闭的软件迁移到开源的10个步骤

数据迁移脚本步骤

Difio是一个基于Django的应用程序，可以跟踪软件包并在更改时通知您。 它提供了多个变更分析，因此您可以在何时或升级什么方面做出明智的决定。 Difio是作为封闭软件创建的，然后我决定将其迁移到开源，以允许内部部署并吸引整个项目社区。

将封闭的软件迁移到开源的10个步骤

简化

已经存在了几年的任何应用程序都已经积累了不再使用的代码和功能。 删除所有可以安全删除的内容，以使代码更清晰，更简单。 开源Difio首先删除了大约20％的现有代码库。

这包括：

• 未使用和过时的设置
• Django应用
• 静态文件和模板
• 模型类
• 旧版网址
• 不推荐使用的功能
• 其他Python实用程序

例如，对于额外的依赖关系和一次性代码，我在某些模板中使用了markdown，在其他模板中使用了纯HTML。 我有一些仅在一个或两个地方使用的自定义模板标签。 所有这些都被删除，并使模板之间更加一致。

进行快速原型制作时，硬编码的路径，值，URL等是不可避免的。 在某个时候，封闭源应用程序会继承其部署环境的构件，因此需要对其进行清理。 我在需要的地方使用了自定义模板标签和设置。

创建独立的模块

换句话说，重新组织文件结构也将增加简单性并使事情感觉更自然。 使模块独立且独立可以使以后更轻松地分离它们。

Difio的Web后端部署在OpenShift上，后者对模板和静态文件使用了不同的目录布局。 我必须四处移动文件并更新Django的设置，以便它们能够正确加载。 这也使我重新考虑了将原始静态文件提供给CDN后端的方式。

内部与外部分开

在您的应用程序内部包含一些内部代码是很自然的，以便为您提供更多信息。 例如，使用情况跟踪和其他指标，计费等。 对于基于Web的服务，这些服务通常与核心功能集成在一起，需要分开。

这也是决定什么结果而不是什么结果的好机会。 例如，Difio不发布其测试用例，因为它们需要更多工作才能与CI环境完全分离，并且可以针对整个Web服务和独立应用程序运行。

Difio包含五个单独的模块：

1. difio /（核心用户体验）
2. 个人档案子系统
3. 计费模块
4. 扩展管理界面
5. 与部署相关的模块（主要是设置）

所有这些都被适当地分离和彼此隔离，从而消除了导入和内部依赖性。 目前，difio /依赖于一些提供合理默认值的配置文件API。
此步骤还可以帮助您从核心用户体验中分离出操作工件（例如，自定义的电子邮件模板）。

代码重构

毋庸置疑，重构和测试应该是持续的工作。 但是，到目前为止，您可能已经对整个现有源代码（或其中大部分）进行了快速回顾，并且注意到许多需要改进的地方。 这是这样做的机会。

这也是创建简短路线图并在公共问题跟踪器中预加载要修复的错误的好机会。 这将有助于您的新生项目在早期活动中展示活动并不断改进，而新的贡献者仍然不见了。

使用Difio，我重构了一些方法，主要是内部方法，以使其适合新的应用程序结构。 外部方法留待以后修复，因为它们很容易拥有，而不必拥有。

法律工作

根据软件和组织的大小和复杂性，迁移到开源可能会非常耗时。 在此步骤中，应考虑所有因素，包括选择适当的许可证，打上商标，指定单个作者，进行法律审查以及潜在地搜索专利侵权代码。

对于Difio而言，这要简单得多。 我选择了Apache 2.0许可证，将许可证标头添加到所有源文件中，并为我在Internet上找到的外部代码正确分配了作者和版权（大多数时间未指定任何特定术语）。

更新并列出外部依赖项

作为软件开发人员，您必须采取额外的步骤来升级到最新版本，并确保您的软件可以正确使用（或至少相当不错）。 没有人愿意使用旧的依赖项来运行您的代码，而且很多时候甚至不可能。

还提供一个依赖项列表（例如，requests.txt文件），并在运行软件之前让人们知道如何安装它们。 幸运的是，作为基于Django的应用程序，Difio仅有很小的升级问题，并且外部依赖项数量适中。

提供文档和示例

文档对于您项目的任何新手都是一个很好的选择。 毕竟，您正在开放一些东西，希望能吸引一个社区。 必须编写文档和示例。

对于Difio，我编写了具有详细设置的README文件，因为该应用程序具有多个子系统（消息层，cron调度程序等），可以用多种方式对其进行配置。 我创建的第二个文档是《 内容管理指南》，因为并非所有内容都是自动化的，有时还需要手动调整。 这两个文件总结了Difio最重要的设计和部署功能-但您可能需要为项目编写更多或其他文档。

创建一个公共代码库

现在是创建公共代码存储库并将软件推向上游的时候了。

对于Difio，我决定将整个difio /目录复制到之前的位置，并进行一次初始提交。 这样做的缺点是以前的所有历史记录都不可用，但我已决定采用这种方式以避免泄露在某些时候可能已经硬编码的秘密密钥和密码。

在生产中，将difio /目录替换为git子模块，以加快发布/部署周期，这主要是因为我的云环境使用git作为部署机制。

从现在开始，您对来源所做的一切都应该公开进行。

在全新的环境中测试独立部署

直到最近，您可能一直在研究现有的本地副本，并继承了来自应用程序专有版本的所有工件，例如依赖项，环境配置等。 从外部用户的观点出发，在全新的环境中进行测试将有助于您进一步完善文档并清理剩余的问题。

在测试Difio时，我发现了一些缺失或额外的要求，缺失和不适当的设置，少量的错误以及不完整的文档。

完成后，重新开始并再次重复，直到正确地解释了每个步骤并立即可用！ 这将确保将来的贡献者和用户至少能够安装您的软件。

宣布

这是最后一步！ 撰写新闻稿，并将新软件发布给全世界。 恭喜，您现在已开源！

翻译自: https://opensource.com/business/14/5/10-steps-migrate-closed-to-open-source

数据迁移脚本步骤