您还未登录! 登录 | 注册 | 帮助  

您的位置: 首页 > 软件测试管理 > 配置管理 > 正文

配置管理之构建管理

发表于:2018-10-10 作者:laofo 来源:简书
  变更管理很多都是流程、授权相关的事,配置管理从中可以做一些事情,但是我个人觉得构建管理才是最有意思的。
配置管理怎么才能体现出价值?做研发人员、测试人员和项目经理最头疼的事。
 
  头疼的构建管理
  什么事最头疼?就是构建管理。很多配置管理的问题都是构建管理的问题。
  这个产品怎编译?(这是新加入项目的成员最头疼的事)
  为什么同样的代码,在我这不工作了?
  7.2.1 的安装包在哪里?
  为啥这个产品的两个包大小不一?
  怎么构建这么慢?我都吃饭回来了,还没编译好?
  为啥对构建管理大家出的问题最多呢?因为这部分涉及的人、涉及的流程、涉及的配置项也是最多的。很多很多的细节需要去关注,忘了关注哪一环,哪一环就会通过一个个的问题补偿回来。
  构建管理的原则
  那么怎么才能做好构建管理呢?
  受控、可靠、一致性的构建环境
  易理解的构建脚本
  可重现的构建过程
  急速的构建速度
  迅速解决构建问题
  受控、可靠、一致的构建环境
  如果配置管理员对构建环境都无法掌控,还谈什么构建管理。
 
  构建管理第一要务,就是可以快速搭建出构建产品的构建环境。如果配置管理工程师无法在短期内搭建出构建环境,研发人员一般就会选择在自己的机器上编译出产品,然后直接丢给测试人员或者技术支持人员。同时,对配置管理工程师的信任度降到最低。
  构建管理交给配置管理工程师去做的价值在哪里?首先就是研发人员都搞不定的构建环境,我能搞定,而且是能快速搞定。简单的构建环境,装好个 IDE,点个按钮就能编译产品,这样做调试代码还可以,但是当项目变大,人员变多这样做就不合适了。终归,我们需要一套干净的构建环境来构建产品。所有要发布的产品都以从这套环境构建出来的产品为准,包括测试、打包、上线等。绝对不能让研发人员在构建环境上调试代码,也不能让测试人员在上面直接部署服务,进行测试。
  构建环境要受控
  构建环境受控这里是指受配置管理团队的控制。配置管理团队负责的产品构建环境是用来编译出产品,用来发布或者上线的环境,不是用来调试编译过程、不是用来验证产品功能的环境(配置管理团队专门为研发人员搭建的个人开发环境不在此列)。
  配置管理团队负责的构建环境,除了配置管理团队和相关运维人员外,其他人都不得访问。访问受控。
  构建环境上除非经过配置管理团队授权,运维人员等不得更新构建环境上的软件、更改配置。配置受控。
  除非特殊需要,否则不得安装杀毒软件。配置管理员也不得把不相关的文件下载到构建环境中。
  除非特殊需要,否则构建环境不开启磁盘加密、安全扫描等功能。
  构建环境要可靠
  可靠指的是什么?是指机器可靠、网络可靠、环境可靠。
  把一些过保的机器丢给配置管理做构建环境,还谈什么机器可靠?说不定什么机器硬盘就挂了。
  现在很多构建过程都要去下载一些包到本地。网络时好时坏,总是丢包重传,一会影响构建速度,二会破坏构建过程。代码本身没问题,结果因为无法下载某些包从而构建失败就悲催了。(后面会讲搭建内部各种源)。
  禁止非授权人员访问构建环境,避免意外更改对构建环境的影响。
  构建环境要一致
  构建环境一致是指所有同类型的构建服务器的硬件、软件都一致。包括:
  硬件配置、驱动版本
  软件版本、安装路径、系统变量、软件配置
  举个例子:两台构建 java 的机器,一个安装了 JDK1.7,一个安装了 JDK1.8;一个yum 直接安装,一个源码编译。这样的两台机器构建同一个项目,很容易造成找不到JDK,编译不过去,编译出来的产品不能部署或者无法正确运行。
  一个比较好的做法就是把构建环境固化到文档,同时固化成一个模板。同类型的构建服务器只需要使用模板再部署一套即可。省去了手工一步步去搭建的烦恼,且搭建时间短、过程可靠。文档也是必不可少的,当需要对模板进行变更的时候,也有据可查,不至于让环境搭建出来,因为缺少必要的文档或者知识传承,最后大家都不敢对模板进行修改。
 
 
  小结
  使用在保的高性能计算型服务器作为构建服务器
  配置管理团队负责构建环境的搭建,且每类环境都有文档记录(环境最好是文档化、模板化、自动化)
  只保留运维和配置管理团队对构建环境的访问权限,且运维每次对环境进行操作都需要经过配置管理团队的确认。
  使用虚拟化、容器等技术来快速搭建出一致的构建环境。