协同开发

Sailing

从修改频度的角度来考虑，分成framework、domain和modules三个库最合适。framework为Sailing开发平台的基础库，domain为应用框架库，modules为应用功能库。framework可服务于全公司所有数据驱动管理系统产品线；domain服务于供应链管理系统，其他类型的产品可能会有其他的domain来支撑；modules则是ERP6的具体业务功能，元数据也放置在这一层，这个库有可能分出许多项目分支。

但由于技术原因，framework和domain库中的前后端需要拆分成两个，因此，实际上暂时分成了5个库：

• framework-frontend：framework前端代码
• framework-backend：framework后端代码
• domain-frontend：domain前端代码“
• domain-backend：domain后端代码
• modules：应用功能的前端代码、后端代码和元数据

从这5个库的作用来说，两个domain和两个framework是一体的，仅仅因为技术原因不得不分开，因此需要确保release版本一致。以后我们就再区分framework和domain的前后台了。

这3个库的依赖关系如下：

domain和framework都是处于被依赖的位置，其中framework还被domain依赖。因此，domain和framework必须有配套的发布机制来管理依赖。
理想情况下，domain和framework应该有不同的发布节奏。但目前出于产品成熟度和管理成本的考虑，domain和framework采用相同的发布节奏，以两周为一个单位。每两周安排下一个周期需要发布的内容计划，并发布版本。但版本发布并不限定为2周一个，如果有需要紧急修复或者紧急追加的内容，也可以随时发布版本。

domain和framework

中心库中的master始终作为最新的开发代码基线。所有的修改通过本地分支或fork到私有库修改，因为目前研发小组成员较少，并不强制必须fork到私有库。
每次release时，必须填写release说明，为对应节点打上release标签，并注明版本号。
如果需要临时修复某次release发现的问题，有两种办法：

1. 从指定release分支出来修复，并在分支上新增一个release。随后讲分支合并到master

   例如：master：1.1 -> 1.2 -> 1.3。发现1.2有个bug需要修复，则从1.2开一个分支1.2branch：1.2 - 1.2.1。发布1.2.1后，分支合并回master，并发布1.3.1

2. 在master上修复后（也需要在本地分支修复），新增一个release。在以上例子中，意味着直接发布1.3.1

后续（预计为明年年中）需要走多发布并行的过程，同一时间需要管理已发布版本，即将发布版本和开发中版本。等积累了一定经验后再来总结。

modules

modules库的核心是元数据以及作为支撑的扩展组件和服务。这个库的分支会比较多。
master分支对应的是产品的最新开发基线，并采用framework和domain库类似的方式来标记release。为了保持产品设计本身的一致性和严谨性，防止项目因素过度
每个项目也有一个自己的分支，并标记线上版本。这是为了在硬件上简化产品和项目的管理，保留灵活性。而为了防止项目和产品分化，需要配合两条制度原则：
1. 每个项目启动，都必须从产品release中挑选一个版本作为项目分支的起点，一般来说这个节点是当时最新的release。
2. 项目初期、有重大变动或新增内容的时候，产品开发组必须安排至少一名成员参与。
另外，最好能安排项目后期的总结。但这一点比较难做到。