大厂如何考虑开发环境与部署方案

阅读指南

• 开发环境的追求
• 部署方案的要求
• 大厂环境因素
• 整合环境因素，导出方案
• 展望未来
• QA

首先我们强调一点，任何公司的技术基建都是随时间推移去不断改进和建设的，任何纯技术输出都必然存在它的边界。而业务拓展、组织架构变迁、新兴技术迭代等都是不断发生的，这意味着技术基建必然也是不断改进的。

拿整个互联网来说，也是由“石器时代”不断演变而来。

而一切解决方案都是为了针对某类需求。

开发环境的追求

作为团队中的开发者一员，无疑要追求美好的开发体验，具体可以列举为：

• 高效的编译速度
• 屏蔽环境搭建与配置，专注内容开发
• 团队编码规范的显式约束
• 编码质量的保障
• 各种运行环境的快速切换
• 与对应需求的绑定与关联

部署方案的要求

• 部署成果的质量与稳定性保障
• 部署流程的快捷
• 高时效性的容灾处理

整合环境因素，导出方案

除开以上普遍意义的需求，大厂本身的环境更是决定了解决方案的重要因素。 如阿里：

1. 人员方面: 项目组众多（开发者数量多）、分内勤和外包(开发成员之间代码力差距相对较大)；
2. 技术方面：技术栈相对统一(主要是业务方面: JAVA-SpringCloud,JS-react,veex… )， 技术输出明确划分内网和开源。
3. 资源方面：有钱任性，相对宽松。

结合以上，我们将需求映射成需要解决的问题：

1. 在云IDE之前的年代里(包括现在大多项目组还是使用本地编译器), 如何统一开发者的开发环境和规范?如何统一生产变量？(即如何确保本地打包环境统一，不会出现不同版本依赖或者丢包等打出预期之外的包) 说白了，这个问题可以简化为： 如何抹平不同开发、生产环境的差异。
2. 做部署流程的整合，提效。

来自阿里的答案

拿阿里的DEF工具举例：

1、“研发套件”集成式脚手架

无论哪个项目组的业务开发，他们对于环境本身的配置其实大都是无感知的，以下图为例

阿里的DEF工具，是通过对本地研发过程中进行总结收敛，抽象出初始化、编译预览、构建、测试、发布 这五个本地工具的通用功能节点。将原有的插件能力根据项目研发类型进行分类后，总结沉淀出每一类研发类型的标准本地工具 --研发套件。

借助套件概念的封装，用户在不同项目之间研发的时候直接通过统一的命令，就能完成项目研发对应工具服务的启动使用。

门神

在DEF中集成门神(相当于提交代码前后的钩子，可类比git-hooks的功能)，负责团队开发规范的约束(lint,cr,其他插件任务等)。

云端IDE

而在这两年里，云IDE开始崭露头角，整个开发环境迁移至云端，更是直接从根本上解决了开发环境差异的问题。

2、统一的研发部署平台

说白了就是对于不同的项目，基于它们的技术选型进行宏观的分类，枚举出每一种类型的最佳部署体验，集成到一个平台。

让用户可以体验“一键发布”的功能，而不用关心具体的部署细节配置。

3、DEVOPS平台

比如上图云效平台，打通自产品需求-设计-开发-测试-发布-运维一条链路的流程管理平台，高效提升效率。 关于DEVOPS的介绍这里就不再做其他赘述，不太了解的同学可以自行搜索一下。

4、展望未来

近年来，上云成了一种潮流，以云服务为核心扩展出的解决方案比比皆是。目前来看，云依然面向未来。 而随着对AI领域的不断探索，各大厂也大多有相关建树。

但无论如何，基建方案与规模的决定因素，永远在于业务与环境。

5、QA

Q: 大厂开发时和部署时类库的引用和存放是一致还是不同？

A: 一般而言，我们要保障开发和生产环境的统一，以确保产出与预期一致。当然也有其他情况，这个要看项目本身有没有不同的需求。 一句话，不要脱离业务讲技术，更不要盖棺定论。

Q: 模块是放在项目中还是放在CDN之类的服务器？

A: 这个问题中“模块”这个概念可能不太清晰。这里指的是前端吧，前后端分离的模式下，前端生产出的包都是静态资源包，一般都是扔到CDN里嘛。

Q： 渲染网页用的是nginx还是其他动态web服务器？

A: 还是那句话，不要脱离业务讲技术，更不要盖棺定论。举个例子，某项目纯node服务+SSR输出网页，本身就是一个web服务的项目何必再需要web服务器？

Q: 会选择自己写模块还是在社区里找模块？

A: 理论上来讲，要尽可能的避免重复造轮子。在已有可信任的满足当前需求的轮子的条件下，尽量不要自己造嘛，因为大家的工时都是很珍贵的。在保障不耽误生产并且保障产品质量的情况下，为了能优化项目本身，也可以自己做嘛。

提倡做有意义的事，而不是多做事。

PASS: 对于以上所有问题哈————无论什么技术方案，其本身都不是绝对的，技术是为了服务业务的。

(文中图片取自 阿里淘系技术团队)