5.1 部署流程的设计原则

小团队小项目的部署

• 将文件传输到指定服务器上
• 交给运维人员发布上线即可
• 但是产品用户量庞大和多分支体系的技术团队，部署工作必须综合考虑协作，速度，安全等因素。不是仅仅上传文件，而是一套完整的流程

部署到测试机

• 开发人员部署，指的是将文件部署到测试机
• 出于安全考虑，发布上线是交给专业的运维人员负责
• 测试机是为了测试和仿真生产，一般只供内网访问

使用FTP工具将文件上传到测试机这种部署方式会出现的问题

• 速度问题：每次修改bug都要打开FTP工具，定位到指定目录后上传修改后的文件
• 协作问题：多人同时修复bug，一个人忘记提交代码，其他人在旧版本上改动
• 安全问题：假如测试机缺乏权限控制，将功能A部署到功能B目录上了

部署流程的三个设计原则

• 速度，协作，安全
• 不同项目和团队会有不同偏重
• 小团队和小项目会侧重速度
• 大团队会侧重协作和安全

速度

• 现有工具的优点

1. 是功能全面，直接使用

• 缺点

1. 无法将配置和项目绑定对应关系
2. 需要一定的人工逻辑操作，比较繁琐
3. 不符合工程化思想

• 要用简单自动化的方式取代繁琐的工具使用
• 两个原则

1. 可以配置：部署的目标服务器，路径信息应该和项目一一对应，部署人员可以配置
2. 操作简单

协作

• 协作常见问题

1. 沟通不及时导致代码不同步
2. 控制不严格导致错误覆盖

• 代码审查是效果最好成本最低的方式

1. 比如，对提交进行审查，及时沟通
2. 人为沟通，非常不可控，还是需要可控的约束

• 部署队列就是绝对可控的解决方式

1. 部署请求按顺序形成一个队列
2. 部署审查人员，审查通过允许部署，否则拒绝部署，之后的部署全部拦截
3. 对小团队来说，专门的审查人员和审查平台，成本太大

• 至于是选代码审查这种不可控但是便宜的，还是部署队列这种贵的可控的，不同团队自行选择

安全

• 严格审查

1. 在代码审查基础上增加了代码层面的约束，比如是否有线上api的非法调用。可以与单元测试结合，由测试工具自动完成

• 权限控制

1. 开发人员不再负责部署，审查人员执行具体部署行为
2. 和部署队列的区别，开发人员需要负责部署，审查人员只负责审查是否允许部署