持续交付加速产品迭代
悦库网盘最早期仅支持window平台部署，现在服务端和客户端都支持多平台，随着支持的功能越来越多，系统的复杂度也大幅增加，每次迭代时间越来越长，导致迭代经常延期，产品交付后问题频发。
面临的问题1: 需求实现后不能立即测试验收
在敏捷开发模式中，产品需求在迭代中开发完成后需要尽早进入测试阶段，而不是等到所有需求都完成才进行测试，这样可以让问题更早被发现和处理，降低集成测试的BUG数量，从而降低迭代延期风险。
在悦库网盘产品的前期迭代过程中，我们就遇到很多问题，举例：
在需求开发阶段，通常是开发人员各自实施自己的任务，将完成任务并提交代码后认为需求开发完毕。但此时做完的需求由于没有集成和打 包，通常处于一种测试人员不可用状态，测试人员只能等待开发人员打包后才能进行测试。
在需求测试阶段，如果发现BUG，开发人员修改后需要重新打包测试人员才能验收。
每次版本发布前问题都特别多，需要不断的 “测试->修复->打包->验收”，对于复杂的多平台兼容系统，打包和部署的时间成本是非常高的，阻碍了整个团队工作进度。
面临的问题2: 产品集成复杂
每一个复杂的软件产品从程序员写完代码到安装包部署到用户生产环境都是一个复杂的过程，仅以悦库网盘windows客户端的构建流程为例：
- 编译32位虚拟盘服务。
- 编译64位虚拟盘服务。
- 编译3个32位explorer扩展dll
- 编译3个64位explorer扩展dll
- 构建electron资源文件。
- 执行打包脚本：包括注册explorer扩展dll、检查并下载安装系统补丁、安装虚拟盘驱动、修复和升级处理等。
- 对安装包签名。
在前期只有windows客户端时，我们通过编写一个批处理文件进行自动打包可以很好的解决问题，随着产品技术栈的复杂度和平台数量的增加打包的复杂度呈指数级增长，目前我们需要分别在windows、linux x64、linux arm64、mac 四个平台上构建客户端和服务端，并将四个平台客户端分别集成到不同平台的服务端中，再考虑后续的手机端，这样的集成复杂度是靠人工是难以实现且非常低效的。
面临的问题3: 产品发布费事费力
产品发布时，需要做的工作：
-
将多个平台的发布包上传到官网
-
发布新版用户手册和开发手册到官网
-
在CDN中刷新URL，使下载链接立即生效
-
归档所有发布包到服务器
-
更新官网下载页面的版本号和发布时间
这些工作重复且无聊~
我们理想中的它是什么样子？
能够在主服务器中对多个目标平台构建发布包，构建完成后自动部署测试环境。
支持多分支，定时检查代码提交行为，如有提交则触发自动打包和部署。
一键发布所有平台安装包并完成归档。
它的存在，是为了让团队能将时间和精力更专注于产品业务实现。
创造它~
通过技术调研，最后我们决定使用Jenkins搭建持续集成环境。
主服务器是一台window service主机，安装了Jenkins，同时可以在其上构建windows平台的客户端和服务端安装包以及部署测试服务端。其他4台主机是平台构建机，实现在非windows平台下构建和部署客户端及服务端，最终构建的所有平台服务端安装包由主服务器收集并完成发布。
持续集成系统主机组成结构?下：
构建过程：
构建过程包括对升级版本号、OEM定制、构建docker镜像、打包、签名、部署等任务。
每一个任务都有对应的任务日志记录，便于失败后排查问题：
它并不完美，但它一直在完美中...
持续交付VS持续集成
持续集成是将产品的各个组件构建并集成，达到一种可部署和可测试的状态。
持续交付是在基于持续集成的工作基础上让集成后的产品可以会直接交付给客户使用，这需要针对主要功能增加自动化测试用例，跑通自动化测试用例的组件或产品认为是可交付状态。
持续交付能力是悦库网盘产品的重要目标愿景之一，我们将为此持续努力。
“我的存在是为了让你们更好的专注于产品业务！”