前端持续集成
前端持续集成
吴阴天在大型项目的开发中，一个持续集成、持续部署、持续交付的平台是必不可少的。
它不仅可以节约我们花在部署上的心思和时间，将注意力集中在代码上。
同时也是版本管理、测试交付中起到重要作用的工具。甚至可以说，缺少持续集成平台，项目管理也将会一团糟。
那么，一个持续集成的平台要如何设计呢？
交付件
我们从交付产物开始，逆推出整个持续集成的流程。
最好的交付方式一定是docker容器无疑，它包含且仅包含运行应用服务所需的“环境”，保证了最高的资源利用率。客户拿到交付件后，也不需要自己配置对应的环境，避免了多余的“技术支持”。
开发不止一次，交付也不止一次。因此交付件是有版本区分的。
甚至交付客户之前，研发测试阶段也有对应的版本。不同的版本，会在不同阶段部署到指定的服务器上。
因此，我们构建出的产物，是需要根据版本先保存一份的，根据阶段不同，推送至不同的机器进行部署。
版本管理
运行支撑平台
构建出的产物，并不等同于交付件。
至少我们的前后端是分别开发的，构建流程也天差地别。因此，将不同应用容器整合成交付件的能力，我们可以交予对应的部署服务器来完成。
服务器作为有限资源，必然不可能每个项目、每个阶段都有唯一的服务器使用。所以，在一个服务器上区分项目、切换版本是必不可少的。
因此，我们的服务器上还需要有运行支撑平台。
它应该接收我们构建好的不同容器，区分不同项目，还有项目中的不同应用。
运行不同版本的应用以供我们开发和测试。
在测试完毕后，将对应的版本打包成交付件，最终通过一个交付件压缩包交给客户。
推送
我们不能随意地进行构建并一股脑地推送到服务器上，那样一定会导致版本混乱。
在项目规划的初期，我们就应该决定各项目中应用的名称。来保证持续集成平台上与运行支撑平台上的应用一一对应。
建立强对应关系的方式有很多，比如说在持续集成平台上，构建应用首先需要建立一个任务，任务的名称对应应用名称。
在运行支撑平台上，仅能为持续集成平台上已存在的任务创建应用，并且至少需要一个版本的容器来进行最初的创建。
这样就建立起了一一对应关系，每次构建好新版本的容器，都只能推送到指定服务器的相应储存位置，并且在服务器上进行版本切换也是天然进行筛选的。
构建
运行支撑平台的重要职能就这些了，端口开放、挂载、路由设置等按需开发的功能就不再赘述。
回到持续集成平台，我们构建应用容器时，除了版本还有什么需要考虑的呢？
代码库
开发是开发的事，构建是构建的事。所以构建需要的代码，直接从代码库拉取就可以了。
当然代码存在github上是肯定不可能的，就个人和工作室而言，我觉得gitea就足够使用了，占用资源很少，提供的团队权限管理也尚且够用。
对于大公司而言，就非gitlab莫属了。
构建环境
对后端了解得不够广，只说前端。
在我平时开发的过程中，每天是与Node打交道的，所以环境中Node是必不可少的。
但是在使用一些库，比如node-sass时，居然需要python来进行编译，而且不同版本的node-sass需要的python版本还不一样。
因此，我们必须预设一些构建环境以供选择。这些环境中的应用不是有和无的区别，而是用哪个版本的区别。
也就是说，我们需要的版本，都存在于机器上。选择环境，意味着真正执行时所执行的具体文件。
构建代码
构建所需执行的代码一定是可以自定义书写的，比如：
1 | npm config set registry https://registry.npm.XXX.org/ |
执行机
构建是具有一定频率的操做，因此我们不能仅由一台机器来做。
但是，每台机器上搭建一个持续集成平台想来也是不明智的。
那么，通过一台机器上的持续集成平台，来调用不同机器执行相应的构建操作就是一个比较可行的方式。
如同k8s在部署时提供扩缩容能力，我觉得也可以在构建时提供自动选择有空闲资源的执行机，防止阻塞。
最终架构
