DevOps模型驱动设计

Posted 2021-04-16 微服务技术社区

       前面我们已经学习了领域模型驱动设计一书，本周我也小试牛刀了一下，从模型驱动设计的角度出发重新设计优化我们的DevOps流程，并且也在部门内部分享了一下。大家听完分享后也纷纷表示觉得模型驱动设计感觉挺清晰的，想要继续学习并尝试去运用到实际工作中。所以本篇文章将把我分享的内容写下来，方便大家在学习和运用中做为参考和比较，能够提出更多的想法一起交流，共同进步。

        首先，我们来看一下DevOps需求描述：

1. 按业务范围和领域划分，确认需要开发的需求落到具体哪个业务中心

2. 为业务定义一个code,通过系统注册项目，并自动在GitLab上创建代码仓储（创建项目需全局观看，要符合context划分）

3. 完成开发提交代码，提交tag以release为前缀的，表明此次提交是可发布版本

4. gitlab webhook触发release版本编译打包镜像，自动累计版本号

5. dev环境发布版本

1. 发布需选择测试人，测试截至日期

2. 填写发布说明、配置变更、db脚本变更

3. gitlab自动创建议题事件，assgin给测试人

4. 如项目有自动化单元测试用例，自动执行，并可查看测试报告

5. 测试人确认通过测试后关闭议题，触发自动发布到qas

6. qas环境测试

1. 用户或业务responser进行UAT测试

2. 完成测试后，标记【测试通过】

7. prd发布

1. prd运维每天能收到当天16点前通过UAT测试的待发布新版本统计

2. 运维者点击一键发布或逐个发布

3. 完成发布后通知用户、业务responser已同步更新prd

上面的需求描述因为是从现有DevOps的基础上提出的改进需求，所以看起来已经是比较清晰了，一般如果是第一次的需求，可能会更模糊，更难以理解。但是也没关系，领域模型设计，本来就是需要多次迭代，才能得到更好的更适合更深层次的模型。接下来，我们就要分析需求开始设计了哦。

一、找对象

我们采用对象建模的方式，所以第一步，我们需要做的事情就是找对象，从上面的需求描述中，我们来找找看有哪些和实现DevOps密切相关的对象。从1，2两句描述要注册项目，那么项目这个客观存在的事物就是其中一个对象了。接着，注册了项目就会创建一个代码仓储，第二个对象是仓储；然后开发人员提交代码，每次release提交会打包镜像，所以第三个对象是镜像；有了镜像之后，我们会部署环境，那么部署实例又是一个对象。

二、确定对象关系

对象我们已经找出来了，接下来我们需要确定关系，也许你找出的对象比上面列出的对象要多，这也没关系，你一样可以把它写下来，因为接下来的事情会帮助我们明确，哪些才是我们需要重点关心的对象。这一步我们需要确定对象与对象之间的关系，是一对多、一对一还是多对多等等，以及建立关系的key是什么？对象的关系就如我们生活中的对象关系一样，你有很多个对象也没关系，因为我们非常明确与对象之间的关系，只要关系清楚不乱，就不用担心太多对象会出事。在这里，比如项目与代码仓储的关系是一对一，代码仓储与镜像的关系是一对多，镜像与部署的关系是一对多。我们有同事提出了镜像与环境有关系，不过这个关系就复杂了，一个镜像可以部署到多个环境，一个环境也可以部署很多镜像。所以这里，我们就要砍掉镜像和环境的关系，因为这样复杂的关系，会导致你的模型不清晰，也会导致你的代码实现很乱。因为模型里面对象与对象的关系应尽量简单清晰，我们都很少会建立双向的关系。

三、发现变与不变

在我们确定对象关系之后，非常重要的事情来了，我们需要去发现模型中哪些对象、操作、关系是不变的，哪些是经常变的或者可能变的。不变的事物我们可以用对象、值对象、函数方法等去实现，而变化的事物可以考虑用SERVICE、SPECIFICATION等去实现。然后要降低变与不变之间的耦合关系。在我们的例子中，编译打包的判断规则是可能变化的，环境也可能变化的，不同环境部署的条件也是可能变化的。所以我们设计出来的模型如下图

我们将编译打包的条件做为规则，不同环境的发布条件做为规则。以保证，适应规则的变化，模型的主体对象是不需要任何改动。另外要强调的一点，模型设计必须明确所有的关系和规则，所有的逻辑都可以从模型上表现出来，不要有隐形规则，这样会导致你的代码与模型不一致，那么模型慢慢的就无法体现正真的实现，模型就会失去意义。

上面的模型体现了设计，那么当开发人员需要以及模型开发时，需要更清晰的模型对象直接关系的流程走向，所以可以增加一个时序图，能更加清晰的表述流程走向。

最后，我们可以在从模型的角度出发，用模型语言来阐述一下功能设计：

1. 在系统中注册一个Project （Project根据实际业务发展需要进行注册，注意Project按业务领域划分）

2. Project注册完成，触发创建一个Repository（Repository对应GitLab上的一个代码库，即注册完成，开发人员即可以拉取Git代码进行开发工作）

3. 开发人员完成开发，提交代码

4. 符合CommitSpecification的代码提交会触发编译打包动作

5. 每一次符合规则的Commit都会生成一个Image，并且每个Image都有一个唯一的版本号

6. 开发人员完成Release代码提交后，在系统中选择对应的Project，点击发布

7. DEV发布需选择测试人、选择用户、确认配置变更、确认DB脚本变更

8. DEV Deployment完成，触发生成GitLab测试Issue，Assign To测试人

9. DEV完成测试后，测试人Close Issue，触发QAS自动发布

10. QAS Deployment完成，用户执行UAT测试

11. 用户完成UAT测试，在系统中标记测试通过，选择通知运维、最终用户

12. 运维收到待发布PRD统计，确认后执行PRD发布

13. 完成PRD Deployment后，通知最终用户，系统已上线

上面的描述，有很多加粗的部分，就是模型语言的关键术语名词，一定要保证所有的参与人员用户、架构师、开发、测试等，所有人的认识是一致的，这是运用领域模型设计的基础，认知一致，语言一致，最终的交付才能是用户正真需要的。

        好了，今天的模型驱动设计就介绍到这里，这里所讲的只是运用了领域模型驱动设计的一小部分知识，还有更多的好用的知识等着我们大家一起去实践~