经过两年多的积累和打磨，OSSA终于在去年下半年成功开源。 OSSA作为Taro生态中的UI组件库，一经开源就得到了Taro官方推荐。 本文将带您回顾OSSA的前世今生，并重点讨论OSSA在走向开源过程中遇到的问题和挑战。

1 简介

经过两年多的积累和打磨，OSSA终于在去年下半年成功开源。 OSSA作为Taro生态中的UI组件库，一经开源就得到了Taro官方推荐。 本文将带您回顾OSSA的前世今生，并重点讨论OSSA在走向开源过程中遇到的问题和挑战。

2. OSSA的前世今生

2.1 背景

时间回到2019年，经过两年的迭代，微信小程序生态已经日趋成熟。 行业已经充分认识到小程序的商业价值，各大平台都推出了自己的小程序系统。

当时，严选想抓住微信小程序、抖音小程序的流量窗口，进行快速商业试水。 因此，在技术上有必要同时维护多个针对不同平台的小程序。 基于研发效率的考虑，技术团队当时确定了多终端统一开发的方向。

当时市面上已经有多种多终端统一框架可供选择。 团队在选择多端框架时遵循以下两个原则：

在综合考虑经验和技术战后，我们决定使用多终端框架Taro来开发部分业务。 之所以选择Taro，首先是基于它当时的设计理念。 输出的小程序具有媲美原生小程序的性能体验，保证了业务交付的质量和体验。 其次，Taro 是基于技术栈的，这与精心挑选的技术栈是一致的。

2.2 组件库腾飞

选择了Taro框架后，我们从保证网易精心挑选的视觉风格统一、提升开发体验的角度出发，开始寻找合适的基础组件库。 截至 2019 年，Taro 生态中可用的组件库仍然非常有限。 经过研究和比较，我们发现现有组件库的视觉风格与网易严选现有的风格相差较大，并且没有一套可以称为企业级的组件库解决方案。 经过综合考虑，我们决定创建一套新的属于我们自己的基础组件库。 从长远来看，满足了业务侧快速迭代、技术侧视觉统一、效率提升的需求。

在决定建立新的组件库后，我们与设计部门联合成立了OSSA评审委员会，负责组件库的可视化控制、评审、规划和实施。 经过精心挑选的电商业务的沉淀和积累，OSSA已初具规模。 整体结构如下图所示。 具体施工流程请参考《》

2.3 开源机会

OSSA自上线以来，一直在精心挑选的内部项目中大放异彩。 主要是因为如果我们要开源，我们面临以下挑战：

2021年下半年，严选业务方开始尝试创新业务。 基于历史多终端研发业绩以及对行业竞品的研究，前端团队在与各方沟通后毅然选择多终端统一开发。 借助创新项目茂卡开发的契机网易严选小程序开发，OSSA在业务发展过程中逐步完善了不同业务场景下的组件体验，验证了组件库在多场景下的易用性。 OSSA在毛咖啡馆业务发展中的出色表现，让我们感觉到OSSA有条件将其推广给更多的人，为更多的商家所用。

为了保证代码的可靠性，提高可信度，OSSA项目组通过完整的测试用例对组件进行全面检查。 经过多场景、多维度的测试，保证了各个组件的功能性以及后续迭代的稳定性，其可靠性也在猫咖项目中得到了进一步的验证。

如果你想在开发之外兼顾日常业务研发并维护一个开源项目，就必须想办法吸引更多的外部贡献者。 通过参考大量现有的开源项目，结合我们项目的特点，我们将逐步提升OSSA社区的能力和经验。 目前，OSSA已经拥有完整的官方网站和教程文档，并提供详细的贡献说明，方便其他开发者参与。

3. 开源前的准备工作 3.1 项目层面

我们主要看一个开源项目必须具备什么。 首先我们来看看官方开源项目应该包含哪些元素：

3.1.1 开源协议（）

开源许可证清楚地表明您的软件可以做什么和不能做什么。 目前常用的开源协议有MIT、2.0和. 关于如何选择开源许可证，您可以通过询问以下问题来确定：

作为前端npm大军中的一员，OSSA毫无疑问选择了MIT协议。 如果以上两个问题不能帮助你做出选择，那么我建议你直接选择MIT协议。 既然选择了开源，那么我们就将开源精神贯彻到底，因为MIT协议基本上不会对开源项目施加任何限制。 用户可以随意在您的项目中使用它。

3.1.2

该文件会显示在首页、npm包主页等很多地方。 一般来说，该文件将包含以下部分：

3.1.3 贡献指南（ ）

项目开源后，其他开发者很可能对你的项目感兴趣，想要为你的项目做出贡献，而外部贡献者是一个开源项目健康发展的重要指标，所以需要一个文档来告诉你如何做外部开发人员可以参与您的项目。 一个好的贡献指南应包含以下部分：

3.1.4 文档和演示

用于构建您自己的文档和演示模型。 对于前端项目来说，基本上每个技术栈都会有对应的快速建站框架。 目前主流的文档生成框架如下图所示：

3.1.5 行为准则（准则）

现在建议为开源项目添加类似“服务条款”的声明。 您可以自己编写，需要包含以下内容：

你也可以直接使用统一的模板，直接粘贴一份到你的项目中即可。

3.2 正式开源

准备好以上要素并通过公司的开源辅导后，项目就具备了投入开源的条件。 在正式开源之前，还需要做两件事：

在项目开源之前，肯定已经有很多信息了。 如果原件中包含一些与业务相关的信息，建议在上传前删除原件信息。 如果原始信息不涉及敏感信息，建议保留，因为这些信息可以帮助其他开发人员了解功能的演变。

完成上述准备工作后，您的项目应该已经在互联网上占有一席之地。 下一步是在互联网上迭代和发展该项目。 项目的社区维护也正式开始。

4.开源社区维护

在一个正常运转的开源社区中，每天都应该上演以下场景：

作为项目维护者，除了项目本身的功能迭代外，其他工作量主要集中在上述场景。 接下来我将以OSSA项目为例，介绍一下在上述场景下如何尽可能减少项目维护人员的工作量。 OSSA的具体做法只适用于前端项目，但其思想可以适用于各类开源项目。

4.1 能力

在开始具体想法之前，我们先来了解一下提供的两种能力。 他们分别是 和 。

4.1.1

首先，我们来看看功能。 是提供的CI/CD能力，功能与CI类似。

利用可以定义在某些特殊时间或行为节点触发一系列操作。 与其他 CI/CD 工具相比，最有用的部分是它提供了官方市场。 用户可以上传自己的包，然后用户可以直接引用自己已有的包。 官方市场上有很多有趣的东西，比如自动同步仓库更新到仓库、自动给第一次贡献的开发者发送欢迎信息等等。

4.1.2

是官方提供的免费静态资源托管服务。 如果您的项目有单独的介绍网站或文档，则可以轻松地将其直接托管在 . 它提供了两种使用方法。 第一个是一起使用，并引用其中官方的/-，这样你的页面就可以部署在任何可以触发的节点上。 第二种是从特定分支进行部署。 一般来说，会创建一个新的 gp-。 当源代码合并到主分支时，会触发打包和编译，然后将产品作为更新提交到 gp- 上。 每次提交都会触发从分支拉取最新产品进行部署。

4.2 自动化处理

工作量主要是定位和求解。 对此，自动化流程起不了多大作用，但正如上面提到的，你可以通过创建模板并强制开发人员提供必要的信息来降低定位问题的成本。 。 为了添加特定的标签，方便其他人从历史记录中快速找到对自己有帮助的信息。 我们可以自动化添加标签的步骤。 官方市场上已经有不止一种解决方案可供选择。

目前OSSA还不是很活跃，所以我们还没有使用它。 不过官方市场上的一些创意工具给了我灵感，比如TODO to，它可以收集代码中的TODO，并将TODO转换为轨迹。 因为大家遇到问题的时候，一般都会在 中寻找解决方案，所以我们其实可以通过具体的方式在代码中注释一些与代码相关的解释性的东西，并利用自动转换的方式在 中提供源文件链接，这样可以极大的方便用户使用。

4.3 PR的自动化处理

以OSSA为例，OSSA项目目前包括三个部分：OSSA组件库、OSSA组件库演示、OSSA组件库文档。 如果我不使用一些自动化流程，那么当其他开发者发起 PR 时，我需要将这个 PR 的更改同步到我的本地。 首先在本地运行一下，看看性能是否符合预期，然后检查修改后的代码是否符合规范。 并且如果有更好的解决方案，则在本地运行测试以确认所有测试用例都通过。 上述流程中，只有代码逻辑是核心工作，其他工作可以完全自动化。

4.3.1 自动部署

如果在创建 PR 时，可以自动部署 PR 中的代码，然后提供部署后预览链接，那么您只需直接打开此链接即可知道更改是否按预期运行。 理想情况下，上述过程是使用搭配来完成的。 但由于安全策略的原因，自动部署从fork仓库提交的PR比较麻烦。 另外，OSSA还有文档和demo两个独立的静态资源需要部署，所以我们选择了一个部署体验更好、功能更强大的来部署OSSA。

使用和部署开源资源需要两个步骤。 首先，在您的项目中启用该应用程序。 激活过程非常简单。 您只需授权该应用程序即可。 第二步，注册账号，在 中新建项目，并配置项目地址、项目打包命令、项目产品输出目录。 然后所有的配置都完成了，接下来就会自动托管项目的部署了。 当主分支合并时，线上环境会自动部署。 当在其他分支提交代码或者提交 PR 时，这些更改将自动部署在测试分支中，并直接在预览地址对更改进行评论。 结果如下图。

部署体验已经做到了极致，但是在国内使用时，会遇到部署的预览版.app域名被屏蔽的问题。 目前官方的解决方案是使用自己的自定义域名，然后将自定义域名转为专门为中国提供的DNS解析域名，然后在后台配置自定义域名，这样会自动将您的自定义域名与你的。 相应的项目。 需要注意的是，自定义域名目前仅支持主分支对应的环境。 PR分支部署的预览域名默认为.app。 如果您还想支持自定义域名，则需要充值。 只有加钱才能变强~

4.3.2 自动测试

只要部署完成，就会触发更改。 现在我们可以感觉到部署完成了，我们只需要配置一个什么时候触发，就可以在这完成项目的测试工作了。 具体的测试步骤取决于所使用的测试框架。 测试框架生成的测试报告可以使用Test来注释相应的变化。

经过上述自动部署和自动测试后，您可以在页面上直接看到变化后的页面性能和测试用例执行状态。 项目维护人员可以将更多的精力投入到代码变更上。

4.4版本自动发布

一个健康的开源社区应该定期发布新版本。 不同的技术栈需要发布不同的产品和平台。 前端项目通常需要发布npm包。 因为整个OSSA项目是一个架构，为了自动管理多包版本，我们选择了项目费用的解决方案。 一个产品矩阵是开源的，涵盖了多包项目从开发到发布的所有阶段。

4.4.1 版本描述文件创建

与其他基于信息的自动版本升级方案相比，该方案要求开发者在提交变更时提交本次变更对每个包版本影响的描述文件。 描述文件包含合并此更改时每个包的更改。 应该升级的版本。 这个描述文件可以通过提供的交互式命令行工具自动生成，也可以直接手动创建。

4.4.2 版本描述文件检查

虽然生成版本描述文件的步骤并不复杂，但与传统项目相比，确实多了一步，所以很多开发者在提交 PR 时忘记生成版本描述文件。 为了确保PR中包含描述文件，提供了检查版本描述文件是否存在的App。 只需要在项目中启用即可。 如果开发者提交的PR不包含版本描述文件，该PR会被自动注释，提示描述文件缺失。

添加个人资料后，它会自动更新评论。

4.4.3 版本发布

上面提到的版本更新也是对项目内版本描述文件的更新。 如果想要真正更新npm包，需要将产品上传到npm仓库。 提供版本发布，其工作大致流程如下：

整个过程大致可以分为三个阶段：

手动合并 PR 到主分支

理论上，所有的修改都应该以PR的形式合并到主分支中。 PR发布后，该分支就可以合并到主分支中。

自动将更改提交到分支

当主分支有新的提交时，会检查提交是否包含信息。 如果包含信息，则会根据该信息自动更新包版本，并将修改提交到 ，并创建新的 PR。 在该版本发布之前，步骤1和2可以针对不同的PR执行多次。

手动合并到主分支

当需要发布版本时，手动将之前自动创建的版本的 PR 合并到主分支。 这时项目办公室的变化就可以被检测到，真正的版本发布过程就会开始。 对于OSSA来说，主要包括发布npm包、根据版本创建新标签以及根据版本生成和添加注释。

5.写在最后

以上只是OSSA目前开源经验的总结。 这是一个蕴藏着许多有趣想法的宝库。 希望你能参与其中，体验别人创造的有趣的东西，自己也创造有趣的东西给别人体验。

本文由作者授权严选技术团队发表。