Difio 是一个基于 Django 的应用程序，用于跟踪软件包并在软件包发生更改时通知您。它提供多种变更分析，以便您可以就何时或升级什么做出明智的决定。Difio 最初是作为闭源软件创建的，然后我决定将其迁移到开源，以允许内部部署并吸引围绕该项目的更大社区。
将闭源软件迁移到开源的 10 个步骤
简化
任何已经存在了几年的应用程序都会积累不再使用的代码和功能。删除所有可以安全删除的内容，以便获得更简洁的代码以进行共享。Difio 开源化的第一步是删除了大约 20% 的现有代码库。
这包括
- 未使用和过时的设置
- Django 应用
- 静态文件和模板
- 模型类
- 旧版 URL
- 已弃用的功能
- 其他 Python 实用程序
对于额外的依赖项和一次性代码，例如，我在一些模板中使用了 markdown，而在另一些模板中使用了纯 HTML。我有一些自定义模板标签，仅在一个或两个地方使用。所有这些都被删除了，并且模板彼此之间更加一致。
在进行快速原型设计时，硬编码的路径、值、URL 等是不可避免的。在某个时候，闭源应用程序会继承其部署环境的产物，这些产物需要清理。我在需要的地方使用了自定义模板标签和设置。
创建自包含模块
换句话说，重新组织文件结构，这也增加了简洁性，并使事情感觉更自然。使模块自包含和独立，使其更容易在以后分离它们。
Difio 的 Web 后端部署在 OpenShift 上，它对模板和静态文件使用了不同的目录布局。我不得不移动文件并更新 Django 的设置，以便它们能够正确加载。这也让我重新思考了将原始静态文件提供给 CDN 后端的方式。
将内部与外部分离
在您的应用程序内部有一些内部代码来为您提供更多信息是很自然的。例如，使用情况跟踪和其他指标、计费等等。对于基于 Web 的服务，这些通常与核心功能集成在一起，需要分离。
这也是决定哪些内容对外公开，哪些内容不对外公开的好机会。例如，Difio 不发布其测试用例，因为它们需要更多工作才能与 CI 环境干净地分离，并针对整个 Web 服务和独立的应用程序运行。
Difio 包含五个独立的模块
- difio/（核心用户体验）
- 配置文件子系统
- 计费模块
- 扩展的管理界面
- 部署相关模块（主要是设置）
所有这些都被适当地分离并彼此隔离，删除了导入和内部依赖项。目前，difio/ 依赖于一些配置文件 API，为此它提供了合理的默认值。
此步骤还有助于您将操作工件（例如，自定义电子邮件模板）与核心用户体验分开。
代码重构
不用说，重构和测试应该是一项持续的努力。但是，到目前为止，您可能已经快速浏览了整个现有源代码（或大部分源代码），并且注意到了许多需要改进的地方。现在是这样做的机会。
这也是创建简短路线图并在您的公共问题跟踪器中预加载要修复的错误的好机会。这将有助于您新生的项目在早期显示活动和持续改进，而此时新的贡献者仍然缺失。
对于 Difio，我重构了一些方法，主要是内部方法，以使它们适应新的应用程序结构。外部方法被留到以后修复，因为它们是锦上添花，而不是必不可少的。
法律工作
根据软件和您的组织的大小和复杂性，迁移到开源可能非常耗时。从选择合适的许可证、品牌推广、命名个人作者、进行法律审查以及可能搜索专利侵权代码——都应在此步骤中考虑在内。
对于 Difio 来说，这要简单得多。我选择了 Apache 2.0 许可证，将许可证头添加到所有源文件，并正确地注明了我在互联网上找到的外部代码的作者身份和版权（大多数时候它没有指定任何特定条款）。
更新并列出外部依赖项
作为软件开发人员，您必须采取额外的步骤来升级到最新版本，并确保您的软件与它们正常工作（或至少相当好地工作）。没有人愿意使用旧的依赖项来运行您的代码，而且通常甚至不可能这样做。
还要提供依赖项列表（例如 requirements.txt 文件），并让人们知道如何在运行软件之前安装它们。幸运的是，Difio 是一个基于 Django 的应用程序，在升级和适度数量的外部依赖项方面只有小问题。
提供文档和示例
文档对于您项目的任何新手来说都是一个很大的优势。毕竟，您正在开放一些东西，希望吸引一个社区。编写文档和示例是必须的。
对于 Difio，我编写了一个README 文件，其中包含详细的设置，因为该应用程序具有多个子系统（消息传递层、cron 调度程序等），可以以无数种方式进行配置。我创建的第二个文档是内容管理指南，因为并非所有内容都是自动化的，有时需要手动调整。这两个文件总结了 Difio 最重要的设计和部署功能——但您可能需要为您的项目编写更多或其他文档。
创建公共代码存储库
创建公共代码存储库并将软件推送到上游的时候将会到来。
对于 Difio，我决定将整个 difio/ 目录从其先前的位置复制出来，并进行一次初始提交。这样做的一个缺点是所有以前的历史记录都不可用，但我决定这样做是为了避免泄露可能在代码中硬编码的密钥和密码。
在生产环境中，difio/ 目录被 git 子模块替换，以便实现更快的发布/部署周期，主要是因为我的云环境使用 git 作为部署机制。
从现在开始，您对源代码所做的一切都应该公开进行。
在新环境中测试独立部署
直到最近，您可能一直在您现有的本地副本中工作，并继承了来自应用程序专有版本的所有工件，例如依赖项、环境配置等等。从外部用户的角度在新环境(s) 中进行测试将帮助您进一步改进文档并清理剩余的问题。
在测试 Difio 时，我发现了一些缺失或额外的要求、缺失和不适当的设置、一些错误和不完整的文档。
完成后，重新开始并再次重复，直到每个步骤都得到适当的解释并开箱即用！这将确保未来的贡献者和用户至少能够安装您的软件。
宣布
这是最后一步！撰写新闻稿并向全世界宣布新软件。恭喜，您现在是开源的了！
5 条评论