环境管理和配置管理-科普篇
# 环境管理和配置管理-科普篇
最近在带个新人，关于环境管理和配置管理讲了很久。考虑到在我刚工作的时候也对这两个部分没概念，写个文章记录和总结下吧，如有不足和补充欢迎指出 。
在阅读之前，读者应该具有 Web 开发的相关知识。
# 环境管理
# 什么是环境
这里说的环境是一个系统运行的环境。一个系统应该至少有 1 个测试环境和生产环境。
测试环境：开发人员用于测试新功能、排查 bug、分析需求时用的，服务器一般在内网，不直接对客。
生产环境：直接面对客户使用的，所用的服务器配置比较高，数据库里都是真实的客户和业务数据。
举个例子，本人在开发一个电商系统。一开始是本地开发的，需要在本地搭建开发环境，数据库，配置 Tomcat 或 Nginx，造数据测试等；
如果开发完了，准备给客户用了，怎么操作呢？部署到服务器上，并且初始化好数据（清理掉测试数据，配置好业务数据，例如菜单表等），这个服务器是可以在外网访问的，然后配置好域名等，至此，就可以提供客户来使用了。
在这里，你的本地环境就是测试环境，服务器上的环境就是生产环境。
补充的知识点：
- 一般来说，一个 Web 项目会分成前端和后端；前端项目部署到服务器上后，这个服务器可以称为 Web 服务器； 后端项目部署到服务器上后，这个服务器可以称为应用服务器，也叫 APP 服务器。
- 即使不是前后端分离，也可以这样做：web 服务器在外网供客户访问，负责转发请求到内网的应用服务器上，这样提高了 APP 服务器的安全性（因为不在外网，黑客不能直接访问到）。
- 为了高可用，可能会有多个 web 服务器和多个应用服务器，也就是集群。
- 防篡改：由于 web 服务器是比较接近互联网环境的（APP 服务器一般是在内网，接受 web 服务器转发的请求），有可能导致被攻击，前端的静态资源被篡改；因此可以给 web 服务器上一个防篡改的服务，不能直接在 web 服务器上修改、重命名、删除文件，只能通过防篡改服务来修改（例如上传静态资源，防篡改推送到 web 服务器）
# 环境的分类
很多时候，我们需要不少测试环境，这就有很多专业的术语指示不同的环境，笔者曾接触过下面的环境：
- dev 环境：专门用于开发的环境，测试新功能，一般可以本地开发，那么本地就是 dev 环境
- sit 环境：用于联调测试。有些时候需要和其他系统进行联调接口等
- uat 环境：用于质控测试人员测试新功能
- vad 环境：用于投产前的版本验证
- prod 环境：生产环境
- 其他…………
为什么有这么多环境呢？因为有时候会用到这么多。例如，一个系统几十份需求，几十个开发人员；
有些时候，一些需求还在开发中，需要部署到服务器上测试；但有些功能已经开发完了，需要质控人员进行测试，为了不让未完成的功能影响到已经完成的功能，单独创建一个 uat 环境是很有必要的；
有些时候，一些需求以及质控测试完了，但是有些需求还在测试，此时我们可以将已经测试的需求，单独部署到另一个环境上，在投产前再测试一次，避免其他测试中的需求，影响到本次要上线的功能等。
如果需求比较少，无需这么多套环境也可以，因为这么多环境管理起来也很麻烦。但至少生产和测试都有一套环境比较合理。
# 环境的管理
有这么多环境，要怎么管理呢？这里列一下笔者知道的吧：
- 尽量让各个测试环境的配置和生产一致。包括：服务器版本，软件安装位置，项目部署的位置等。
- 对于测试环境，不建议几个环境共用服务器。例如笔者就遇到过，一个服务器上分了多个 Linux 用户，不同环境用不同的用户。这样，不同环境的中间件安装位置、系统部署的位置，各个环境监听的端口号等等，都不一样（肯定不会一样，会冲突）。由于缺乏文档，时过境迁，已经不知道哪个目录、端口是哪个环境的了，整理起来也颇费功夫。
- 生产环境可能很多个服务器，服务器配置也很高；大部分测试环境可以不用那么多服务器，配置也可以稍微低一点（毕竟用的人不多，都是开发和测试人员在用）。但 vad 环境的配置最好和生产一致，可以用于压力测试和负载均衡测试等。
一些大型的企业，有专门的环境管理规范，并有专门的环境管理人员（或小组）负责维护环境的增加、删除和修改配置等。
# 配置管理
这里的配置管理包含几个部分：
- 源代码的版本管理
- 构建管理
- …………
# 版本管理
这里说的版本是指代码的版本。虽然我们可以用 Git 来管理代码，但还是有一些问题要搞清楚
- 分支怎么管理？例如分支的命名和创建
- 对于各个分支，如何分配权限（例如提交、合并）
- …………
这里说下笔者接触过的管理方法：
- 统一使用 Git 来管理代码（内网用 GitLab），对于 svn 和 cvs 的统一迁移到 Git（有一些工具可以将 svn 和 cvs 的提交记录也迁移到 Git 上）
- 有一个主干分支（这里假设以 master 分支命名），是对外发布的唯一版本，不能直接修改该分支上的代码
- 环境分支：不同环境的版本可能不一样，因此单独建立一个分支，对应测试环境的版本
- 需求分支（也叫功能分支）：新功能或者改造旧功能的时候，基于 master 分支上创建出来。一般会有一个需求编号，用需求编号创建分支
- 缺陷分支：当发现生产环境有 bug 的时候新建分支用于修复
- commit 规范。
怎么使用分支呢？
- 当有一个新的需求来了，先新建一个需求分支
- 开发完一个需求后，提交到需求分支上；
- 然后配置管理员，合并需求分支到环境分支上，并部署到测试环境，用于测试。
- 当需求正式上线后一天，配置管理员将环境分支合并到主干分支。
GitLab 用户管理
一个系统可能有几十个人维护，不可能谁都可以提交和修改分支，不然容易混乱，得有个规范。
- 一般会有一个 GitLab 的管理员，先给每个开发人员创建一个账户，命名方式为工号或姓名拼音
- 如果有多个系统，则每个系统一个 Git 项目
- 只有负责系统的的开发人员，才有访问该系统的代码的权限
- 开发人员可以创建分支，创建 label 等，但没有修改主干分支的权限
一些术语
- 提版（打版）：需求开发完后，提交到了需求分支上，告知配置管理员合并分支并打版到测试环境上
- 合版：解决冲突
- 拆版：当某个需求取消或者其他原因不做了后，从环境分支上剥离出来
- 定版：确定上线的最终版本
- 部署包：指本次需求涉及到改动的代码的压缩包，一般是增量的，用于部署到测试环境或生产环境
以上方法可能比较多，繁琐，但对于多人使用的话是可行的。如果是小公司或者个人，可以不用这么多规范。
# 构建管理
当开发完功能后，需要编译出部署包，然后部署到服务器上，并且重启；这些步骤可以叫构建
其实这些步骤是很固定的，甚至可以说是重复的，无意义的。
因此，出了很多工具，例如 Ant，Maven，Jenkins 等帮我们构建和持续集成。
有了这些工具后，我们只需编写好构建的脚本或者做相关的配置，就可以在编写完代码后一键构建，不用开发人员亲自编译、出包和部署，重启等。节省大量的时间。
笔者的博客就是用 GitHub Action 来完成持续集成的，当笔者提交后，后台就自动编译，然后部署到服务器上。如果失败了会有邮件告知。
这些工具不仅能节省我们时间，还减少了出错的概率。笔者曾经遇到过手工部署的系统，一次投产十几个文件，一个个部署到服务器上，然后换一台服务器继续部署…………一旦有一个文件放错或者漏了，都很难检查。
后来笔者也曾自己写过部署脚本，就是执行 shell 文件，将部署包放到服务器上后，依次部署文件（就是 mv 和 cp 命令），然后重启等，也节省了不少时间；但缺点是每次都要重新编写和检查，较为麻烦。
一些公司会自己内部搭建持续集成的工具。笔者接触过的公司就用过，其内部使用方法和 GitHub Action 差不多。
