Devops系统自动部署技术方案

DevOps系统自动部署项目
技术方案
目录
1项目概述 (3)
1.1项目背景 (3)
1.2项目现状 (4)
1.3项目目标 (6)
1.3.1提高测试和部署的自动化水平 (6)
1.3.2集中管理应用部署包 (6)
1.3.3快速分享提交物 (6)
1.3.4代码管理规范化 (7)
1.3.5自动构建 (7)
2方案设计原则 (8)
3技术方案 (10)
3.1业务架构 (10)
3.2技术架构 (12)
3.3数据架构 (14)
3.4集成架构 (16)
3.5解决方案 (17)
3.5.1总体方案 (17)
3.5.2配置管理 (18)
3.5.3持续集成 (19)
3.5.4持续交付 (20)
3.5.5控制台 (21)
3.6部署方案 (22)
3.7非功能性设计 (24)
3.7.1性能 (24)
3.7.2可靠性 (26)
3.7.3可用性 (27)
3.7.4可扩展性 (27)
3.7.5可维护性 (28)
3.7.6安全性 (29)
1项目概述
企业级的配置管理和自动部署平台，从配置管理，构建管理等角度对软件开发中的各个细节进行改进和能力加强；集中有序管理应用代码和版本，确保资产自主可控，最大限度地保证资产可复用性。

运用自动化工具，从部署包、部署环境、部署流程以及部署执行四个维度，提升应用软件系统部署的自动化水平，降低部署过程中的出错率、返工率，进而提高软件交付的效率和质量。

基于该平台的研究和运用，以尽可能短的周期，高效可靠地构建、测试、发布应用软件。

从而，为业务发展提供强有力的支撑，并从IT发展自身角度建立扎实的基础。

1.1项目背景
谈到企业IT，就没有办法回避两种迥然不同的企业，一种是以传统制造业或者服务业为基础的，对生产资料进行加工的「传统企业」；另一种是以「信息互联」为基础的，对「人与人关系、人与物关系、物与物关系」进行信息加工的「互联网企业」。

这两类，是两类极端的企业，一类企业的日常运行，可以没有信息系统；另一类企业，完全离不开信息系统。

一般的信息系统，对于企业的价值，主要有三类渐进过度的典型类型。

第一类，是将信息系统定位于「辅助和支撑」企业的产品制造以及企业运营部门，因为这类企业的生产资料系、生产力、生产关，都以实体制造为主，不以信息加工和处理作为企业产品核心。

第二类，是将信息系统作为数据加工、传输作为主体，但业务模式来自于传统行业，信息系统主要完成已有业务规则的虚拟化，例如金融、电信行业。

这类企业的信息或者数据，主要来自于业务受理，或者说数据的生产者和使用者是企业自身。

第三类，是将信息系统作为企业唯一生产工具，并将企业的客户（个人或企业）所自发贡献的信息、数据，作为生产资料，形成新兴的业务模式。

这里企业的典型，就是互联网企业。

随着又一轮「互联网+」的概念席卷而来，非互联网企业所面临的更多针对用户和客户的思考和探索，都需要有更快交付能力的信息系统进行支撑，这也是传统企业互联网化，打开企业边界围栏需要迈出的第一步。

随着云计算、容器/Docker、微服务、敏捷等相关概念和实施的成熟发展，DevOps已经基本成为互联网企业的标准配置，在 DevOps 的概念被炒热之前，众多互联网公司其实已经实践了 DevOps 。

其中的原因也正是因为信息系统，是这些公司的生产工具，没有人比互联网公司的人更明白提高自身的办公效率，提高团队、企业的生产力，就是为提高企业产品的生产力进行有效的保障。

DevOps 的核心价值，是能够帮助企业快速交付变更，以便于快速响应企业对于市场的变化、用户的需求。

包括7个主要过程：代码、构建、测试、打包、发布、配置、监控。

相比传统企业尤其是制造业的产品制造工艺和制造流程，软件产品的制造，IT 服务的交付，更多的是交付一些无形的软件产品和知识工作。

正因为这些无形产品受制于不同的人认知所产生的多变，其管理复杂度远比制造业来的复杂，企业软件的设计、开发、发布、上线，缺乏标准化的管理过程。

对于如今的非互联网企业而言，能够快速见效的 DevOps实践，应当从（环境）配置的管理，以及自动化部署。

在实施难度上，配置的管理要低于自动化部署。

因为非互联网企业的技术路线由于供应商的竞争（甚至是恶意竞争），变得极其多样，架构离散化程度也很高。

对比互联网企业，（环境）配置管理和自动化部署，由于IT技术从硬件到虚拟化/容器的自主可控，企业整体技术架构的收敛性就比较理想。

1.2项目现状
目前企业级的配置管理和自动化部署系统还处于建设初期，大部份企业都面临着几大问题，包括缺乏统一的研发管理平台、项目管理有待规范化、配置和版本管理混乱、缺乏应用部署环境资源管理、手工操作导致低效率和高出错率。

缺乏统一的研发管理平台
⏹自主开发和外包开发的项目众多，工具繁杂而不统一，各种工具往往只解决
某一个点上的问题，例如配置管理，缺陷管理，计划任务管理，构建管理等。

⏹部分研发环节使用开源工具或非专业化工具，工具间缺乏集成性，数据无法
连通，不同项目所使用的工具都存在差异，项目资产数据也分散在这些工具当中，无法有效加以利用，并大大增加了管理难度。

⏹现有的RTC，CQ等工具，使用量较少，并且没有整合为一个平台。

例如RTC
只用于个别项目的构建管理，CQ用于需求提出和故障流程管理。

这些环节之间是断裂的，没有连通起来构成清晰的研发生命周期链条。

项目管理有待规范化
⏹目前的研发项目管理处于较为粗放，落后的状态。

⏹既定的项目流程规定在各个项目当中并未很好地落实和执行，往往凭借项目
经理的经验和习惯进行管理。

⏹信息汇总通过会议和文档进行，沟通传达通过邮件和口头等方式。

⏹流程仅仅落在纸面上并由手工监督执行，这种管理方式显然与我行建设先进
高效的研发管理理念不符。

配置和版本管理混乱
⏹现有代码分散在开发商自有的版本管理系统，对代码缺乏集中、有序的管理
和维护。

缺乏应用部署环境资源管理
⏹缺乏集中、规范并易于访问的软件发布包存储库。

⏹当前很多软件包的存储基于简单文件系统，这种存储方式不便于被不同应用
环境的部署人员快速访问。

手工操作导致低效率和高出错率
⏹采用手工操作界面或运行构建脚本形成发布包，手工记录和沟通每个环境所
部署的应用版本，系统测试、用户验收测试、准生产、生产环境的应用部署基于手工操作（包括手工修改参数文件、手工执行部署命令）。

⏹在手工部署，通常手工操作包括把发布包拷贝到目标机器，根据部署环境的
差异对客户化发布包，然后执行部署命令，最后对部署结果进行验证。

⏹部署相关流程基于手工进行沟通，沟通成本高，效率低：比如应用在测试环
境部署完成后，需要通过邮件或电话通知测试人员；在部署生产环境前，需要人工完成审批。

1.3项目目标
配置管理和自动部署平台从配置管理、构建管理等角度对软件开发中的各个细节进行改进和加强，并持续提升应用系统部署的自动化水平和效率，从而快速响应业务需求，本项目的主要目标包括：
1.3.1提高测试和部署的自动化水平
作为发布人员，能制定跨环境、跨版本重用的标准化部署流程；
作为部署人员，查看不同环境下部署的应用组件版本和部署日志，发起特定环境、特定流程和特定版本的部署请求。

1.3.2集中管理应用部署包
作为发布人员，能管理发布包版本和版本文件，定义版本类型（增量或全量）和状态，有效的集中管理应用部署包。

作为部署人员，能管理被部署服务器并关联需要部署的应用组件，获得已部署的应用组件版本信息。

1.3.3快速分享提交物
作为项目成员，能快速获得和分享项目提交物，并能存储和获得修改历史。

1.3.4代码管理规范化
作为开发人员，能获得所承担的工作项，完成相应的代码修改，提交新文件版本并自动关联工作项。

1.3.5自动构建
作为发布人员，能运行自动构建，把发布包自动导入软件部署工具, 并触发测试环境的自动部署。

2方案设计原则
1．实用性原则
在需求分析的基础上设计系统，确保系统满足需求；
努力设计简单、方便、友好的用户界面，使用户易于理解、易学、易操作，保证系统发挥应有功效；
充分考虑已有资源（软硬件设备及数据）的合理利用，与现有系统的兼容性，最大限度的保护现有设备的投资，实现系统操作上的一贯性；
设计时考虑好新旧系统平稳过渡问题，避免出现不必要的浪费；
2．先进性原则
系统构造采用先进的B/S架构，简化客户端的支持工作；
系统实现采用先进的云计算技术、容器技术、微服务架构技术；
应用软件开发采用先进的软件工程方法，确保软件质量，并提供完整的技术文档；
3．可行性原则
采用的先进技术应是成熟的经过实践证明是成功的技术；
设计的方案要科学、正确、严谨、且现实可行；
4．开放可扩充性原则
系统设计要采用结构化和模块化的设计方法，使系统逻辑结构清晰、易读，在功能的划分和设计时，使各模块尽可能相对独立、减少相关性以易于扩充、维护和修改；
系统选型应遵循国际标准，具有一定的设备无关性，使设备配置和系统扩展有更大的自由度和灵活性；
注重系统的设计具有一定的兼容性；
系统设计要考虑到业务未来发展的需要，同时考虑系统建设的阶段性，要尽可能地设计得简明，各个功能模块间的耦合度小，便于系统的扩展，平滑地与其它应用系统自动接口；
5．安全性原则
建立完善的授权机制，主要为不同的用户提供合适的访问权限，使其不越权使用；
保证系统操作的可记录性，以便对操作行为进行监督；
6．可移植性、可延续性原则
采用的开发技术不仅满足现在的应用需求，而且要适应未来的发展趋势，在以后的升级、移植工作方便；
降低用户的二次开发成本，保证用户的投资利益；
3技术方案
3.1业务架构
软件从需求收集到部署上线需要各种角色的人员共同协作，经过一系列专业过程，才能最终实现预期的产品功能，交付目标用户使用。

这些活动可以使用不同的过程模型来描述和规范。

软件过程模型就是一组开发策略，这种策略针对软件工程的各个阶段提供了一套范式，使工程的进展达到预期的目的。

对一个软件的开发无论其大小，我们都需要选择一个合适的软件过程模型，这种选择基于项目和应用的性质、采用的方法、需要的控制，以及要交付的产品的特点。

在整个软件工程的发展历史上，出现过多种软件过程模型。

比较典型的开发模型有线性的瀑布模型、增量的迭代模型等。

在这些模型中有一些共同的基本活动：需求、开发、构建、部署，通过按照时序完成这些活动（迭代模型中是多轮次完成），逐步完善一款软件的各个方面，并最终交付完整系统或者每个增量特性。

现代软件系统规模越来越大，逻辑越来越复杂，开发一款软件需要的工程人员结构越来越复杂，但协作确越来越频繁和至关重要。

由于不同角色的工程人员技术背景和职责不同，往往在协作过程中会产生协作不畅的现象，非常典型的开发团队和运维团队之间的协作问题。

同时，由于软件本身的复杂度不断提高，完全依靠人工的处理就有不够稳定和高效。

软件业界针对那些执行起来比较繁琐或者经常出现问题的活动，有一种方法论来处理：更加频繁、更加自动化地处理这些活动以便更快地得到反馈，尽快发现问题并快速将问题解决在萌芽阶段。

DevOps敏捷软件交付方法就是这种方法论的具体实践。

DevOps（英文Development和Operation的组合）是一组过程、方法与系统的统称，用于促进开发、技术运营和质量保障部门之间的沟通、协作与整合。

可以进
一步划分为持续集成（CI，continuous integration的缩写）和持续交付（CD，continuous delivery）。

DevOps软件过程图
DevOps的工程实践一般采用快速迭代的模型。

每个迭代依然主要由需求、研发、构建、部署四个阶段组成，但是每个阶段都有相应的实践来优化。

需求和研发阶段属于持续集成，而构建和部署则属于持续交付。

需求阶段，方案设计配置项以及工程代码集中管理，并规范配置项与代码之间的关联。

当研发人员实现完工作项并将对应的代码提交进配置仓库时，用户可以关联代码集和相应的工作项，实现需求与实现的跟踪。

研发阶段，设置自动化的代码集成测试，检查代码质量，并及时反馈团队；支持项目团队针对每一个代码修改在线协作改进，以及规范稳定版和研发版代码的组织结构。

项目推荐用户保持一个随时可以用于部署的代码基，一般叫做主分支，没有完成的或者发现有缺陷的代码不能提交合并到该代码基。

开发人员可以为每个工作项
以最新的主分支为基础创建一个代码分支，用于临时保存针对该工作项的代码。

这个临时分支也可以提交到集成配置库保存，防止所做代码修改意外丢失。

更加重要的是，它可以用于开发人员之间随时进行代码评审和协作完善，且多个工作项可以并行处理，互不干扰。

除了可部署代码基和临时特性开发分支，用户还可以创建用于质量保障测试、预发布、正式产品发布等用途的分支。

这些分支会根据应用发布计划从某个时间点的主分支创建，并封闭一段时间，期间不再合并新的工作项代码集。

如果进入下一轮发布或者需要修改封闭测试过程中发现的缺陷，用户仍然需要先使用临时分支开发并合并代码集到主分支，然后从主分支的代码集序列中合并需要的代码集。

用户可以配置一个或者多个分支执行集成任务，一旦有代码集提交到该分支，系统就会执行所配置的集成任务，并将反馈集成结果到代码集。

如果分支配置了集成任务，那么只有集成任务成功的代码集才可以合并到主分支，以保障主分支的质量。

构建阶段，根据需要构建的分支的代码集变动，自动构建发布，并规范成品配置项的管理。

用户可以配置一个或者多个分支执行构建任务，一旦有代码集提交到该分支，系统就会执行所配置的构建任务，并将生成的版本保存到统一的仓库。

部署阶段，规范部署过程，实现复用，支持多套环境部署；与构建阶段对接。

用户可以描述多套环境的部署配置，每个配置相互独立。

可以选择自动或者手动执行部署。

如果选择自动部署，当部署关联的版本有更新时，系统自动触发一个部署任务执行部署操作。

如果选择手动部署，只有用户触发部署时，系统才会创建一个部署作业执行部署。

3.2技术架构
为实现应用系统自动部署的业务目标，系统采用以下技术架构：
该系统主要由四个层次组成，分别是基础设施层、基础服务层、DevOps引擎层和用户门户。

基础设施层由用于部署系统的基础设施资源组成，可以是物理机，也可以是虚拟机。

这些主机需要配置一定的计算能力，足量、可靠的存储空间以及可以实现相互通信的网络连接。

基础服务层主要由集中配置仓库、集中软件仓库、数据库、消息中间件、缓存服务构成，用于支撑上层DevOps各组件的运行和之间的协作。

DevOps层是整个系统的核心，主要由持续集成引擎和持续交付引擎组成，相互协作处理上层用户请求，运用下层基础服务实现应用系统的自动部署功能。

用户门户是用户与系统的交互界面，调整系统参数，管理应用相关的人员、权限、代码、主机等资源。

系统主要由门户Web、API网关、授权管理器、工程管理器、集成管理器、构建管理器、部署管理器以及外部支持组件组成，它们之间的逻辑关系如下图：
组件逻辑架构图
3.3数据架构
应用系统自动部署领域主要包含的数据模型以及它们之间的相互关系，可以用以下图表描述：
应用系统自动部署领域模型
一个应用系统可以包含一个或者多个工程，每个工程单独一个代码配置库。

应用还会分配一个或者多个主机用于部署各个工程的发布版本。

研发过程中，每个工程的需求由一个或者多个工作项组成，团队根据这些工作项进行研发，最终生成一个或者多个代码集并提交到工程对应的配置库。

每个提交可以关联一个或者多个工作项，也可以不关联工作项。

提交之间组织成链式关系，从一个提交可以查看它所基于的整个提交历史。

为了方便团队的协作，一个工程可以创建一个或者多个分支，每个分支引用一个代码集及其上溯的整个提交历史。

每个分支上可以创建不同的集成任务和构建任务，集成任务用于对分支的代码集执行集成测试并反馈结果。

构建任务用于将分支的代码集构建成一个版本。

版本是可以用于部署的组件，与一个代码集关联，并根据代码集关联的工作项得到该版本所实现的需求。

版本一旦生成就不能修改了，并集中在一个版本库里管理。

一个工程可以根据版本的成熟情况部署多次，得到不同的运行实例。

每个部署关联一个版本、可选的多个配置参数以及一个或者多个目标主机。

系统可以启动多
个部署任务来执行部署，将指定版本安装在目标主机上，并使用配置参数启动版本。

数据模型中涉及的实体根据不同特点采用了不同的存储技术，总体的数据存储架构如下图所示：
自动部署系统的组件主要使用代码仓库、消息队列以及关系数据库来存储系统的数据。

系统业务模型的数据大部分通过关系型数据库存储。

代码仓库是由GIT提供服务，存储代码文件到文件系统。

组件之间协作是通过异步消息实现的，这些消息通过消息队列保存和堆积。

其它文件类型的数据，比如文本格式的配置文件、二进制格式的版本包，统一采用文件系统进行存储。

基础层的文件系统可以是在主机的本地磁盘上构建的，也可以是基于SAN存储系统的LUN构建的，或者是其它共享文件系统。

整个系统的所有数据都可能部署到备份系统的存储上。

3.4集成架构
应用自动部署系统需要与第三方开发商的代码仓库、测试管理软件、部署目的主机操作系统进行集成。

系统采用分布式代码管理方式，不同的代码管理系统保存的相同项目的代码可以方便地相互比较和同步。

第三方可以缓存应用的集中库中代码到本地，并在本地离线开发，提高研发效率。

为了提高自动部署系统的自动化水平，代码系统的一些事件需要能够自动触发持续集成系统的处理。

系统所采用的代码管理系统设计有hook机制，在代码集提交、分支合并等事件处设置了集成钩子。

系统通过这些钩子，接收到代码管理系统的特定事件，并相应地启动持续集成任务。

持续集成引擎需要支持不同的集成任务，有些集成任务需要对接测试管理软件执行特定的测试计划。

持续集成引擎采用插件架构，通过专门为测试管理软件开发的插件可以与它实现集成。

持续交付引擎执行部署任务时，需要能够从版本配置库获取应用的特定版本，保存到目标主机上并安装启动版本。

版本配置库提供HTTP协议的API，方便引擎查询、下载版本。

持续部署引擎可以通过目标主机上的代理插件远程执行命令来同步完成一些操作。

3.5解决方案
3.5.1总体方案
应用自动部署平台通过搭建统一的配置管理以及持续集成和持续交付两个功能引擎，整合分布式代码管理系统、统一软件包管理系统、部署作业系统、容器技术以及第三方软件（如HPE ALM），实现包含应用工作项管理、代码管理、自动化代码测试和分析、代码在线评审、自动化构建等持续集成实践，达到集中管理和规范应用系统研发，促进团队协作的目的；同时实现包括应用发布版本包的统一管理、规范部署方案管理、自动化部署多套环境、多个版本的应用等持续交付实践，达到标准化部署流程，提高部署自动化程度，实现应用可靠、快速交付上线，从而，为业务发展提供强有力的支撑，并从IT发展自身角度建立扎实的技术基础。

整个系统的功能按照下图所示划分和组织。

功能结构图
系统核心是配置管理以及持续集成和持续交付核心引擎。

配置管理的主要功能包括工作项管理和代码管理。

持续集成引擎的主要功能包括集成配置、代码评审、自动测试、构建配置、自动构建和集成作业管理。

持续交付引擎的主要功能包括版本管理、部署配置、自动部署和部署作业管理。

系统面向用户提供管理控制台，主要功能包括参数管理、用户管理、权限管理、资源管理、工程管理。

以下将按照功能模块详细说明解决方案。

3.5.2配置管理
配置管理主要功能有工作项管理和代码管理。

工作项管理
作为开发人员，可以创建、编辑和删除工作项，根据实际研发进度更好工作项状态。

作为开发人员，可以在提交一个代码集时，在代码集的描述信息中使用标记关联若干个工作项，对需求和实现进行跟踪。

当一个代码集经过测试和评审，合并到主分支中时，系统会自动关闭代码集关联的工作项。

代码管理
作为项目成员，可以快速获得并存储项目代码，查看修改历史。

系统采用git作为配置管理存储系统，可以按照工程存储代码，支持使用SSH、HTTP/HTTPS协议获取任何一个时间点的项目代码，支持查看任一纳入配置管理的代码文件的修改历史信息。

对于异地进行开发的团队，可以从集中配置库签出代码，操作方式与内部访问一致。

开发人员可以同时添加多个配置管理系统，拉取代码进行评审或者合并。

系统支持创建任意多个分支。

每个工程都默认创建一个主分支。

分支只是一个代码集提交的别名，因此创建分支是非常轻量级的操作，速度很快。

除了分支以外，配置管理支持设置标签来标识一个代码集提交。

标签一般用于标记工程代码的一个特殊状态，可以将版本号与对应的代码关联起来。

3.5.3持续集成
集成配置
作为开发人员，可以设置自动集成相关策略和参数，以便当工程代码发生变更时触发系统的自动集成，快速得到有关所提交代码质量的反馈。

工程创建时，系统会将工程的代码仓库和集成引擎间通过hook创建联系。

一旦代码仓库有修改，集成引擎就会得到通知，如果工程配置了自动集成，系统执行集成作业，并反馈结果到代码集的关联事件列表中。

代码评审
作为项目成员，可以将自动还没有合并的代码集创建一个合并请求，改善给项目评审人员进行评审。

评审人员可以使用对比视图查看需要合并的代码。

如果有评审意见，双方可以直接在线交流修改意见。

合并请求在接受合并前可以多次更新，以便包含更新的修改。

自动测试
作为项目成员，可以添加单元测试代码，以便保证代码逻辑正常和一定的质量标准。

单元测试代码需要用户自己编写。

目前主流编程语言都支持xUnit或者类似的单元测试框架。