版本控制系统又称源代码管理系统,是指一种记录一个或若干文件内容变化,以便将来查阅特定版本修订情况的系统。
——支持浏览、查阅、复刻、归档版本仓库
——为版本仓库指定成员,并根据可访问、可读取、可写入等不同能力将成员划分为管理员、负责人、开发者、协作者等不同角色,并能在不同对象上(如团队、项目等)定义
——支持浏览、查阅、创建和删除分支,可根据分支查看变更历史,并查看分支对应的版本文件
——能够在分支上定义合并策略,限制不同开发人员在分支上的合并权限
——可查看某个变更的当前全部版本文件,并将版本文件拉取到本地
——可将本地修改提交到版本仓库,完成变更
——支持在线对比两个不同变更之间的文件差异,查看变更的历史记录以及变更之间的关联关系。并可将一个或多个变更创建为合并评审,用于合并到待合并分支
——查看合并评审的历史列表,以及每个合并评审引入的变更,可设置经过评审后才可合并
——支持将某个变更标识为Tag,并作为基线管理
——查看基线对应的版本文件,并能将对应的版本文件下载到本地
——查看不同变更间、不同基线间、变更与基线间、分支与基线间的文件差异
——变更被提交时,提供Hooks用于触发自动化集成和检测
——发起代码审查,邀请审查人在不同时间和地点查看版本差异并给出意见
——同一个版本仓库能够支持多份存储写入,当存储故障时可切换备份存储
——提供实时和定时的备份机制,可使用备份还原版本仓库
——应唯一确定访问账号身份,保证无法越权访问
——应能够保留访问记录和危险操作记录,用于审计回溯
——应支持如https / SSH等加密传输方式,保证传输过程的网络包被截获后无法轻易解密
——应为变更、合并和评审提供Hook,用于触发自动化流程
——应提供CI/CD中基本功能的API,用于其他系统调用接入
——建立团队或路径等方式,并在其中指派不同角色的成员,将版本仓库按一定模式归类存放
——更改版本仓库的可见性为全员共享或部分可见
——限制仓库总大小,限制仓库的单文件大小,对限制额度进行缩小或提额
——定义分支创建规则,对分支的创建进行限定,在分支上定义角色,指认分支的管理员,定义读取、写入和合并权限
——针对变更进行讨论
——合并评审可根据代码扫描、持续集成与自动化测试系统反馈情况,阻止有风险的版本合入
——定义基线的命名规则,阻止不符合规则的基线创建
——对代码审查进行数据度量
——审查人能在移动终端查看代码审查、讨论并给出意见
——能与主流的即时通讯服务或团队协同工具集成,提供实时的消息通知
——同一个版本仓库能够提供多地存储,在有多地访问需求时,能提供就近访问
——大量复刻并修改同一版本仓库时,能让存储容量不随复刻数线性增长
——支持使用通用的文件存储系统(如x86平台的存储系统)
——支持OAuth等安全的三方认证能力,保证需求敏捷、持续集成、持续交付、代码检测、自动化测试等工具在访问版本资源时,访问权限受到当前操作人角色权限的限制
——提供研发生命周期中所需功能的API,用于其它系统深度集成
——可提供项目维度和团队维度的动态墙用于汇聚研发过程有关的消息和事件,使用会话的形式聚合研发过程中发生的事件与关键结点,并可使用移动终端查阅。
——会话墙能力可允许需求敏捷、持续集成、持续交付、代码检测、自动化测试等工具调用
构建是指从代码或其它产物构建出指定输出物的过程,构建管理是指管理以上过程涉及的任务、过程、策略和环境等必要因素。
——通过配置模板或脚本初始化构建环境。
——通过配置模板或脚本定义构建任务。
——初始化环境和构建任务的配置模板或脚本的存储有版本管理,可配置标签。
——构建过程的输出可重定向到文件或日志服务,能够持久化存户和查询。
——构建过程可以设定执行时间,针对超时的情况可设定超时策略。
——构建过程的输出物设定输出地点、传输协议,针对输出失败的情况设定失败策略。
——构建过程的触发支持通过 HTTP RESTFUL 、GRPC 等多种方式触发任务执行。
——构建过程的结果可设定多中通知策略,支持 Email、IM 等。
——管理构建资源,针对构建任务设定优先级进行调度。
——能使用分布式系统管理构建任务。
持续集成是指通过源代码构建软件的流程。
持续集成是指通过源代码构建软件的流程。应该包含以下基本功能:
——保存多个构建任务
——设置代码仓库地址,以及拉取源代码的凭据
——设置一个或多个构建命令
——支持多种源代码语言的编译
——支持多种源代码托管软件
——设置自动触发条件:定时触发,源代码变更触发
——构建任务应该含多个执行记录
——构建执行记录展示记录状态,以及结果
——构建执行记录展示构建过程产出的日志
——支持构建命令中执行软件单元测试
——支持执行静态源代码扫描
——支持定义构建执行环境
——可以支持提供执行持续集成依赖的服务,例如:数据库服务,缓存服务等
——构建执行记录中可以保存构建产出物
——构建执行记录中可以保存构建报告,单元测试报告,测试覆盖率报告
——可以保存构建产出物到第三方软件
——可以支持在一个构建任务中多个源代码仓库的
——可以支持定义构建任务超时时间,并在执行过程不允许
——支持构建容器镜像,以及推送构建的容器镜像到第三方软件
——支持源代码缓存
——支持触发其它构建任务,或者其它第三方软件
——支持定义执行超时时间
——建议在高级功能中添加:
——支持源码多分支管理策略的构建场景
——支持动态可伸缩的构建执行环境
——支持构建结果通知(及时消息、邮件等)(10.9)
流水线是将代码提交到部署上线整个过程中的自动化实现。
——支持集成调度代码托管、代码检查、编译构建、部署、测试、发布等任务,应实现提交代码后的端到端的产品自动化交付与发布
——支持业务流程按需定制,可选择要执行的步骤和顺序
——支持级联调度与分层分级(是否增加描述1101)
---增加串行并行能力的描述(1101)
——支持按时间计划或代码提交等多种触发方式
——支持流水线状态可视化,宜清晰呈现价值流动,宜及时准确定位问题
——支持参数配置
++增加质量管理控制,支持多种条件判断
——支持人工审批
专家建议:增加制品版本控制模块;另外是高级功能和基本功能划分的问题。
制品管理是对软件研发过程中生成的产物的管理,一般作为最终交付物完成发布和交付。 制品即构建过程的输出物,包括软件包,测试报告(存疑,招商银行,是否作为元数据),应用配置文件(是否适合作为制品,应当能够作为元数据1101)等。 比如jar包、zip包、rpm包、docker镜像等。
--(缺少制品添加方式的描述(谐云科技)1101)
——支持至少一种制品类型;
——为制品添加版本信息等元数据信息(元数据信息希望能细化,烽火科技1101);
——使用制品的审计日志;
——基本的权限管理;
——代理其他制品库;(不应该作为基本功能,应作为高级功能,一些企业无法实现代理能力,平安银行1101)
——检索制品;
——备份和恢复
——支持多种制品类型;
——制品分发支持大规模并发、全球加速;(应当增加对场景的限制1101)
——与持续交付系统高度集成;(描述有欠缺,是否和API一行合并谈集成能力1101)
——基于元数据信息实现制品的安全管控、晋级
——当特定制品的特定版本由于某种原因需要召回时,具备快速阻断机制,立即禁止被再次引用/访问;
——REST API支持;
——通过关键字、坐标数据、CheckSum等多种方式检索制品
——基于角色的权限管理
——基于自定义策略的访问控制
——制品文件安全扫描
——分析和查看制品依赖关系
——基于CheckSum的制品去重存储;
——自定义制品清理/归档策略(是否应该改为基本功能,平安银行,征求下云产品的建议1101)
--(是否增加配额管理能力作为高级功能1101)
——制品存储不依赖于特定厂商或存储源
专家建议:生产环境的管理还是测试环境?此处是生产管理的,专家建议包含生产环境和测试环境。(增加对测试等各类环境的描述1101)
部署管理是DevOps持续交付中的一个重要环节,它借助自动化工具与统一规范,实现仓库版本到生产环境的自动化部署,提升开发和运维人员快速部署的能力。应该包含以下基本功能:
----是否应该有 权限管理(1101)
——部署工具应具备批量(海量)并发部署的能力;
——支持灰度、全量(是否是发布管理的概念,而不是部署管理1101)等部署方案的实施,实现对生产环境的平滑升级;
——部署前支持备份上一版本的生产环境,在当前版本出现问题后能支持版本快速回退;
——支持业务配置文件的自动生成与下发以及统一管理;
——当业务架构调整后(存在疑问,mark1101),部署方案(范围较大1101)仅需调整布署节点配置项即可(布署节点指的是什么,京东云1101);
——部署工具与业务架构松耦合,无需业务因布署方案或工具做任何改造;
——部署对象服务器支持windows、linux等主流操作系统;
——部署对象服务器在CMDB集中管理,与部署工具联动实现任意组合集群的版本部署;
可以包含以下高级功能:
——部署工具具备调度编排的能力,能同时对不同功能模块版本实现一次性全流程部署;
——支持上下文传输部署,即上一部署节点的输出能作为下一节点的前置条件或输入参数;
(如何描述对业务影响) 发布管理是指一个应用或多个集成应用程序从测试完成开发测试到生产环境用户可见的完整发布流程(定义混淆,如何和部署区分,华为1101)。
——发布计划,规划软件程序的整体发布计划,包含但不限于:谁在何时、何地、怎样、发布了什么。以及对比发布计划和发布状态的能力。
——发布定义,定义发布流程和审批工作流。
——发布策略,通过选择进行发布的目标环境、超时时间、暂停点、灰度发布等发布的具体策略,执行对应的发布动作;发布策略包含并不限于一键式发布,零停机发布、灰度发布、金丝雀发布等
----(与布署管理关联1101)
——发布执行,自动化地执行发布策略,如策略中有暂停点,应验证后继续执行发布
——发布确认,通过发布规划中软件发布的确认点,进行发布确认,如与预期不一致,可快速回滚到发布前的软件版本
可以包含以下高级功能:
——发布决策,实现个角色的协同,评审决策,控制应用版本向后续环境的流动
——风险评估与质量门禁,提供发布影响分析视图,可快速查看发布产品的发布风险,在关键节点控制版本质量,支持自动质量门禁
——发布度量,发布报告视图,提供发布的状态报告与历史发布数据
环境管理是一种配置管理活动,确保应用在多个环境之间达到持续交付的目的。
——可以定义不同的环境类型(开发、测试、预发布及生产环境);
——可以定义不同的环境依赖资源信息及其配置,比如主机、容器集群、DNS、中间件、其他基础设施服务等等;
——可以根据环境的配置快速生成交付(交付一词不妥1101 ) 环境;
——可以让环境的配置信息存储在构件库中,版本化控制配置信息;(构件库的含义不清,应当澄清)
——可以支持应用运行的环境是静态主机集群或者是动态的容器集群;
——可以支持不同的应用有不同的基础设施及服务依赖;
——可以支持不同的对象分块构建,比如说构建基础设施、构建中间件或者操作系统环境等等;
——可以支持不同的环境采用不同的构建技术,比如说虚拟化、容器等等,但测试环境和生产环境必须类似;
——可以支持环境的配置信息与应用或者项目关联;
——对环境提供监控功能;
可以包含以下高级功能:
——提供与不同的配置管理工具对接功能;
——提供与不同制品构件库对接功能,比如说maven仓库和容器仓库artifactory、harbor等等(1101);
——提供开放式的API供外围平台编排调用;
——提供所有环境的变更日志和审计功能;
——提供环境配置信息的权限控制;
——提供测试验证的工具来验证环境的有效性;
数据管理是xxxx。
——xxxx
——xxxx
——xxxx
——xxxx
应用配置是指应用启动或动态运行时影响应用行为的配置项,典型例子如数据库连接串(含用户名密码),本地服务线程池数,RPC连接超时时间设置,三方软件LicenseKey,等。应用配置管理,是对应用配置进行集中式管理的系统和方法。采用应用配置管理,可以让配置发布有效解耦程序开发,程序发布等流程,并让程序能动态响应配置的变更,提高DevOps效率。
——配置的最小粒度应对应单一配置ID,其内容应不限于KV,Json, XML等格式,用户应能自由配置。
——配置内容大小应有限制,但是不宜太小,如应超过100KB以上。
——配置应能基于租户,分组,或其他不同粒度规则进行隔离。
——对配置的访问应有鉴权,以控制账号对相关配置项的读写权限操作。
——应提供相应程序接口供应用程序实现读、写配置的功能。
——应提供相应程序接口供应用程序实现配置订阅的功能,如配置变更,则程序可在短时间内做出响应。
——应用程序应可以基于各类语言如java, go, node, c++等多语言SDK来操作配置。
——应用配置管理应能和各类CI/CD工具集成,如github,等。
可以包含以下高级功能:
——配置发布时应支持灰度发布,如根据某类机器的IP或某类机器的Label。
——应提供配置订阅监控,可查看配置被哪些机器订阅。
——配置应能区分版本,不同版本之间能一键回滚,以降低配置发错的风险。
——配置管理应能充分集成各类加密工具,如AWS KMS,Aliyun KMS,Hashcorp Vault,(不应出现具体产品1101)以保证配置安全性。
——配置管理中心以成为系统单点,如管理中心宕机,应用应能正常运行。(但新配置不能发布)