前言
上一章我们一起学习了物料的相关知识以及该如何设计一个通用的物料系统，大家应该也对物料的价值以及设计有一个初步的概念。
在本章我们将会介绍物料系统的开发以及服务端构建的相关知识，注意本章的内容虽然会涉及到物料产物 CICD 相关的范围，但实际小册提供的物料系统并不包含 CICD 构建的模块，所以有想将物料系统实际用于生产的同学需要自己来实现 CICD 的功能。
物料系统开发
先来回顾一下上一章的内容，物料的产物分类有下面几种：
构建类型产物
其中所有的组件类都是需要通过构建产出的，其他的如模板、代码区块都是以 code 模式存在。既然存在构建过程那么物料系统就需要对接 Devops 系统，通过 CICD 来构建产物上传物料。
所以在物料系统中会有 Project 的概念对应的是 Git 仓库，每一个 Project 都会对应一个 Git 仓库方便 Devops 系统进行工程构建，于是我们第一个物料系统的表为 Project：
Project表主要是存储CICD项目构建信息，所以这张表一般情况下也是存在于Devops系统中，所以如果有Devops系统的话，就没必要在物料系统中再创建一张表，一般可以由Devops直接提供CICD底层服务通过微服务集成到物料系统或者使用双写表模式来共同管理Project表（双写表模式并不推荐，存在互相覆盖以及重复开发的情况）。
在上一章我们也提到了，物料中存在两种包管理方式分别是 monorepo 与 multirepo，根据 multirepo 类型的物料，物料系统是可以根据产物直接推断出版本依赖结果，但是 monorepo 类型的物料并做不到，只能通过以创建虚拟物料的方式来推断出产物结果。
通常情况下物料的数量一般比较多，而且也会与各个业务线有关联，所以在物料系统中会有一个物料集的概念，来管理同一类的物料，比如电商物料库与 CRM 物料库等，所以我们的物料表结构可以如下所示：
从上图的实体类可以看出，虚拟物料集与实体物料类会保存 ProjectId 字段，物料系统可用根据 ProjectId 字段可以查询出 Project 的项目信息，从而进入 CICD 流程来进行项目构建。
表中的 alphaVersion、betaVersion、gammaVersion 分别对应的是 NPM 产物中的 alpha、beta、gamma 类型的包如：@boty-design/fe-cli@0.0.1-beta.8，小数点最后一位则使用 devVersion、testVersion、preVersion 来表示物料当前的版本分别在各个环境已经构建了多少次，当然最终生产环境打出来的包为 @boty-design/fe-cli@0.0.1。
在构建完毕项目之后，就需要保存对应的产物结果，NPM 类型的物料结果是可以通过物料实体类中的 name + version 两个字段直接推断出来如：@boty-design/fe-cli@0.0.1，而 CDN 类型的产物需要带有全连接才行如：https://abc.com/boty-design/fe-cli/0.0.1/idnexjs（如果能保证 CDN 的域名一致的话，其实也可以使用 name + version 推断出产物结果），所以产物结果表可以为：
所以结合上述所有的表，最终构建类型物料的表结构如下：
理论上以上的表结构设计足够满足绝大部分类型的物料存储，各位同学可以根据自己的实际情况来进行调整，比如团队中不需要 dev、test 环境的，可以删除 alpha、beta 相关的字段。或者想使用 CICD 的方式来产出对应的页面或者区块的话，也可以拓展 MaterialConfig 的表结构。
代码类型产物
除去组件这种强依赖构建的类型之外，剩下如区块、模板都可以以 Code 形式直接存储在数据库当中。所以他们的表结构相对于简单，只涉及到对应配置的增删改查：
在 Config 表中有一个 contain 的字段是用来保存 Code 的，与物件类型的物料不同，CodeMaterial 表除了 currentVersion 之外额外多了 currentConfigId 字段，在客户端消费区块跟模板的时候需要使用 currentConfigId 从 Config 表中查询对应的数据，获取存储的 Code 内容。
网关资源
网关一般只需要代理前端页面级别的资源，其他的资源一般都是放在 CDN 或者 OSS 上，所以我们需要一张 Page 表来存储对应的访问域名、路径与产物：
网关基础服务会将访问域名解析为 domain 与 path，再读取 Page 表来查询对应的配置信息，最后将查询出来的 HTML 资源返回给前端访问。
最后放上物料系统的终极表结构设计：
物料构建
上述是物料系统的开发，接下来我们简单讲述一下物料系统的构建过程：
常规的流程如上图所示，物料系统会创建一条 task 来记录物料的发布信息，同时触发 Devops 的构建流程，在 Devops 构建流程完成之后，由 Devops 系统推送构建消息给物料系统，物料系统根据推送消息的结果，来判断是否来保存物料的产物信息。
这里有一个非常重要的点，所有的物料产物结果尽可能的保持结构唯一尤其是 CDN 类型的产物，CDN 的最终产物的结果一般可以为 https://domain/ptah/name/version/index.js，如果不能保证产物的格式统一的话，那么对于物料系统来说可以有两种解决方案：
- 所有的产物结果保存都由
CLI工具构建出真实产物后上传 - 使用拓展字段来手动修正产物结果，使得
CDN的数据有效
但这两种解决方案无疑都是会造成额外的使用与学习成本，所以最好的方案是开发物料的时候，可以以统一脚手架与模板来约束研发开发物料，对于物料系统的开发与管理成本会比较少，另外统一的规范也是能够在团队快速推广物料系统的好手段。
写在最后
物料系统的地址为 feat/material，需要的同学自取，会持续更新。
其实对于网关系统来说，只需要代理页面级别的资源，根据域名匹配返回对应的 HTML 内容，所以上述的所有表只有 Page 与 Config 这两张表在网关体系是真实有用的。
Page 的产物一般与 CICD 或者搭建系统有关，但无论是 Devops 还是搭建系统，两者都属于一个非常庞大的系统，在网关系统的小册中肯定是完成不了的，单独拎出去写两本小册恐怕都不够，但我又想多一个实战的项目给大家历练，所以最后选择了将 Page 相关的开发直接升级为物料系统。
最终的物料系统代码目前也在开发中，跟用户系统一样，小册里面不会过多的展示相关的代码，每个人的实际需求与风格都不相同，不想做过多的约束，但我会按照上文中的架构与表结构设计直接开发一套完成的工程放在 github 上供给同学们参考。
希望同学们最好可以根据小册的内容加上自己的理解独立完成物料系统的开发，在不涉及 Devops 的情况下，物料系统开发的难度远不如用户系统，如果开发过程遇上任何的难处或者疑惑的地方，欢迎加群或者加我的微信来讨论解决方案。
如果你有什么疑问，欢迎在评论区提出或者加群沟通。 👏