环境管理和配置管理-科普篇

最近在带个新人，关于环境管理和配置管理讲了很久。考虑到在我刚工作的时候也对这两个部分没概念，写个文章记录和总结下吧，如有不足和补充欢迎指出 。

在阅读之前，读者应该具有 Web 开发的相关知识。

环境管理

什么是环境

这里说的环境是一个系统运行的环境。一个系统应该至少有 1 个测试环境和生产环境。

测试环境：开发人员用于测试新功能、排查 bug、分析需求时用的，服务器一般在内网，不直接对客。

生产环境：直接面对客户使用的，所用的服务器配置比较高，数据库里都是真实的客户和业务数据。

举个例子，本人在开发一个电商系统。一开始是本地开发的，需要在本地搭建开发环境，数据库，配置 Tomcat 或 Nginx，造数据测试等；

如果开发完了，准备给客户用了，怎么操作呢？部署到服务器上，并且初始化好数据（清理掉测试数据，配置好业务数据，例如菜单表等），这个服务器是可以在外网访问的，然后配置好域名等，至此，就可以提供客户来使用了。

在这里，你的本地环境就是测试环境，服务器上的环境就是生产环境。

补充的知识点：

• 一般来说，一个 Web 项目会分成前端和后端；前端项目部署到服务器上后，这个服务器可以称为 Web 服务器； 后端项目部署到服务器上后，这个服务器可以称为应用服务器，也叫 APP 服务器。
• 即使不是前后端分离，也可以这样做：web 服务器在外网供客户访问，负责转发请求到内网的应用服务器上，这样提高了 APP 服务器的安全性（因为不在外网，黑客不能直接访问到）。
• 为了高可用，可能会有多个 web 服务器和多个应用服务器，也就是集群。
• 防篡改：由于 web 服务器是比较接近互联网环境的（APP 服务器一般是在内网，接受 web 服务器转发的请求），有可能导致被攻击，前端的静态资源被篡改；因此可以给 web 服务器上一个防篡改的服务，不能直接在 web 服务器上修改、重命名、删除文件，只能通过防篡改服务来修改（例如上传静态资源，防篡改推送到 web 服务器）

环境的分类

很多时候，我们需要不少测试环境，这就有很多专业的术语指示不同的环境，笔者曾接触过下面的环境：

• dev 环境：专门用于开发的环境，测试新功能，一般可以本地开发，那么本地就是 dev 环境
• sit 环境：用于联调测试。有些时候需要和其他系统进行联调接口等
• uat 环境：用于质控测试人员测试新功能
• vad 环境：用于投产前的版本验证
• prod 环境：生产环境
• 其他…………

为什么有这么多环境呢？因为有时候会用到这么多。例如，一个系统几十份需求，几十个开发人员；

有些时候，一些需求还在开发中，需要部署到服务器上测试；但有些功能已经开发完了，需要质控人员进行测试，为了不让未完成的功能影响到已经完成的功能，单独创建一个 uat 环境是很有必要的；

有些时候，一些需求以及质控测试完了，但是有些需求还在测试，此时我们可以将已经测试的需求，单独部署到另一个环境上，在投产前再测试一次，避免其他测试中的需求，影响到本次要上线的功能等。

如果需求比较少，无需这么多套环境也可以，因为这么多环境管理起来也很麻烦。但至少生产和测试都有一套环境比较合理。

环境的管理

有这么多环境，要怎么管理呢？这里列一下笔者知道的吧：

1. 尽量让各个测试环境的配置和生产一致。包括：服务器版本，软件安装位置，项目部署的位置等。
2. 对于测试环境，不建议几个环境共用服务器。例如笔者就遇到过，一个服务器上分了多个 Linux 用户，不同环境用不同的用户。这样，不同环境的中间件安装位置、系统部署的位置，各个环境监听的端口号等等，都不一样（肯定不会一样，会冲突）。由于缺乏文档，时过境迁，已经不知道哪个目录、端口是哪个环境的了，整理起来也颇费功夫。
3. 生产环境可能很多个服务器，服务器配置也很高；大部分测试环境可以不用那么多服务器，配置也可以稍微低一点（毕竟用的人不多，都是开发和测试人员在用）。但 vad 环境的配置最好和生产一致，可以用于压力测试和负载均衡测试等。

一些大型的企业，有专门的环境管理规范，并有专门的环境管理人员（或小组）负责维护环境的增加、删除和修改配置等。

配置管理

这里的配置管理包含几个部分：

1. 源代码的版本管理
2. 构建管理
3. …………

版本管理

这里说的版本是指代码的版本。虽然我们可以用 Git 来管理代码，但还是有一些问题要搞清楚

• 分支怎么管理？例如分支的命名和创建
• 对于各个分支，如何分配权限（例如提交、合并）
• …………

这里说下笔者接触过的管理方法：

1. 统一使用 Git 来管理代码（内网用 GitLab），对于 svn 和 cvs 的统一迁移到 Git（有一些工具可以将 svn 和 cvs 的提交记录也迁移到 Git 上）
2. 有一个主干分支（这里假设以 master 分支命名），是对外发布的唯一版本，不能直接修改该分支上的代码
3. 环境分支：不同环境的版本可能不一样，因此单独建立一个分支，对应测试环境的版本
4. 需求分支（也叫功能分支）：新功能或者改造旧功能的时候，基于 master 分支上创建出来。一般会有一个需求编号，用需求编号创建分支
5. 缺陷分支：当发现生产环境有 bug 的时候新建分支用于修复
6. commit 规范。

怎么使用分支呢？

1. 当有一个新的需求来了，先新建一个需求分支
2. 开发完一个需求后，提交到需求分支上；
3. 然后配置管理员，合并需求分支到环境分支上，并部署到测试环境，用于测试。
4. 当需求正式上线后一天，配置管理员将环境分支合并到主干分支。

GitLab 用户管理

一个系统可能有几十个人维护，不可能谁都可以提交和修改分支，不然容易混乱，得有个规范。

1. 一般会有一个 GitLab 的管理员，先给每个开发人员创建一个账户，命名方式为工号或姓名拼音
2. 如果有多个系统，则每个系统一个 Git 项目
3. 只有负责系统的的开发人员，才有访问该系统的代码的权限
4. 开发人员可以创建分支，创建 label 等，但没有修改主干分支的权限

一些术语

• 提版（打版）：需求开发完后，提交到了需求分支上，告知配置管理员合并分支并打版到测试环境上
• 合版：解决冲突
• 拆版：当某个需求取消或者其他原因不做了后，从环境分支上剥离出来
• 定版：确定上线的最终版本
• 部署包：指本次需求涉及到改动的代码的压缩包，一般是增量的，用于部署到测试环境或生产环境

以上方法可能比较多，繁琐，但对于多人使用的话是可行的。如果是小公司或者个人，可以不用这么多规范。

构建管理

当开发完功能后，需要编译出部署包，然后部署到服务器上，并且重启；这些步骤可以叫构建

其实这些步骤是很固定的，甚至可以说是重复的，无意义的。

因此，出了很多工具，例如 Ant，Maven，Jenkins 等帮我们构建和持续集成。

有了这些工具后，我们只需编写好构建的脚本或者做相关的配置，就可以在编写完代码后一键构建，不用开发人员亲自编译、出包和部署，重启等。节省大量的时间。

笔者的博客就是用 GitHub Action 来完成持续集成的，当笔者提交后，后台就自动编译，然后部署到服务器上。如果失败了会有邮件告知。

这些工具不仅能节省我们时间，还减少了出错的概率。笔者曾经遇到过手工部署的系统，一次投产十几个文件，一个个部署到服务器上，然后换一台服务器继续部署…………一旦有一个文件放错或者漏了，都很难检查。

后来笔者也曾自己写过部署脚本，就是执行 shell 文件，将部署包放到服务器上后，依次部署文件（就是 mv 和 cp 命令），然后重启等，也节省了不少时间；但缺点是每次都要重新编写和检查，较为麻烦。

一些公司会自己内部搭建持续集成的工具。笔者接触过的公司就用过，其内部使用方法和 GitHub Action 差不多。