标签：build 生成 dep 业务逻辑 opera 组合 sem 附加 策略
DevOps（Development和Operations的组合词）是一组过程、方法与系统的统称，用于促进开发（应用程序/软件工程）、技术运营和质量保障（QA）部门之间的沟通、协作与整合。它是一种重视“软件开发人员（Dev）”和“IT运维技术人员（Ops）”之间沟通合作的文化、运动或惯例。透过自动化“软件交付”和“架构变更”的流程，来使得构建、测试、发布软件能够更加地快捷、频繁和可靠。
本篇主要概述的是Dev环节的支撑平台。如何一套Dev平台来同时支持传统企业交付模式以及互联网业务交付模式。关于支撑Ops阶段的平台涉及内容庞大复杂，后续从数据中心Ops的角度展开论述。
关于本人对Dev与Ops环节的支撑平台的划分，大致为如下：
互联网业务的特点是自开发，自运维，标准的devops模式，从研发活动来看，涉及五个阶段，code，build，test，deploy，monitor。每个阶段的职责不同。
传统IT业务的特点是研发团队负责开发交付，IT技术支持团队负责实施（部署，升级），客户负责运维。且传统IT企业交付的往往是一整套完整的解决方案。
相比较互联网业务模式，研发活动流程变为了如下，增加了assemble(装配过程)。
也就是如何将开发团队的输出装配为面向客户交付的解决方案包。
两种场景下的共同诉求都是devops理念中构建，测试，发布更加快捷，频繁，可靠。
核心目标是如何快速，低门槛的开发，同时对于QA来说，如何可进行统计度量（代码量，产出率等）。而快速，低门槛则尽可能让开发只聚焦与核心业务逻辑的实现，更多的工程相关的属性依托于可视化，自动化的构筑生成。因此需要契约化的工程结构，以支撑后续的运行维护管理。微服务架构模式下，微服务是最小的工程单元，因此也即是定义一种符合微服务的契约化的工程属性。微服务的特征要求具备独立可编译部署变更，对外需要清晰的API等。
因此可以定义譬如下面的开发工程的目录结构
一般一个微服务的开发顺序可参照如下：
一般在设计阶段就需要输出API定义，传统的往往是word或者excel等定义，用于评审，然后开发阶段需要编写代码去定义，此部分则可以完全简化，基于YAML/JSON定义API文件，并基于Swagger直接可视化展示API用于评审，开发阶段同样基于此文件直接生成API代码和到业务逻辑的调用。最终开发者直接编写API的实现单元即可。
依托于契约化松耦合的目录结构，需要devops平台具备如下的能力：
1：微服务的初始化管理服务。微服务自身就是个后续需要被维护管理的对象，故而需要一个微服务管理的能力。包含：微服务定义，开发工程生成，以及关键指标的搜集（代码量，开发语言，责任人，提交次数等）
2：基于主流开发工具（Eclipse，IDEA）可一键式生成API代码。
微服务初始化管理服务（后续简称codeinit）结构可大致表述为如下
至此基于微服务管理服务的code过程变为：
核心目标是检查原始代码的质量并编译生成可执行的包。
，
Assemble核心目标是微服务包到服务包，服务包到解决方案大包，或者微服务包到解决方案大包的自动化装配过程。
需要一种契约化的包的装配规则的定义，包含目标包类型（解决方案，服务），包含的服务或者微服务。最终客户拿到的是一个基于部署系统可部署的完整的大包，不用自己手动下载组装配套的多个包。
最终效果：研发团队视角提供微服务，形成一种原子能力的微服务池子，不同解决方案定义不同的微服务打包策略，基于devops平台自动装配不同的解决方案包。
Deploy阶段隶属于Ops范围，涉及上下文很多，后续详细展开论述，此部分只做概要介绍。
部署系统的核心目标是可视化/自动化的将解决方案包/服务包/微服务包部署到不同的环境的节点上。这里面涉及几个名词：包，部署动作，环境，节点，需要展开论述。
包指的是开发活动交付的软件的载体。可以是zip/镜像等。
环境：指的是部署活动中涉及的Alpha（服务内自验证环境），Beta(服务间联调环境)，Gamma(类生产环境)，Gamma(生产环境)。
节点：这里面定义的是在可直接部署包的介质，需要强调的是可直接部署性。一般性硬件和软件是分离的两拨人，一个数据中心内允许两次驻场，以此是设备采购到位后，硬件调测人员进驻进行硬件安装配置，其次是软件调测人员驻场，进行操作系统安装及其之后的过程，而对于部署系统来说，此处部署的是软件包，并不包括OS安装配置，故而也就引出了另一个系统：独立的装机服务，此即为部署系统的其中一个上下文，但并非属于部署系统。但是实际往往也可能没有独立的装机服务，譬如节点如果全是虚拟机，而一般企业往往虚拟机的生命周期管理存在与独立的云管理平台中（物理机的初始化，OS安装，虚拟机发放）。此时云管理平台即可承载此处所需的装机能力。
DevOps模式下的Monitor隶属于Ops范围，涉及内容和上下文很多，其内容包含监控（硬件，OS，业务的性能，调用链，拨测），告警，故障诊断等，上下文涉及变更，事件，报表，通道等后续详细展开论述。
此处需要附加说明的是即使从Dev阶段也是需要Monitor能力的，也就是监控统计Code，Build，Assemble阶段的各个指标
标签：build 生成 dep 业务逻辑 opera 组合 sem 附加 策略
原文地址：https://www.cnblogs.com/hrbeu05/p/9676806.html
