Jenkins 大型系统持续迭代实践

概要：

1. 持续发布版本所面临的问题
2. 版本快速迭代流程设计
3. 集成部署环境构建

 

一、持续发布版本所面临的问题

 

提问：

1. 现在所在的公司是如何发布版本的?多久发布一次？
2. 已什么样的形式进行发布？
3. 有没有出现过发布事故？

 

增量发布?

修改的 Class 直接丢给甲方 工程师

 

产品迭代过程

一般情况下产品迭代发布过程分为以下几个阶段：

编码 -> 构建 -> 集成 -> 测试 -> 交付 -> 部署 ，但随着敏捷开发模式与微服务架构的盛行，导致整个链路实施过程变得越来越复杂沉重，迭代周期脱长。 为了解决这一问题大牛们分别提出了,持续集成、技术交互、技术部署的概念，经证实这是一个行之有效的方式，但同时也对团队的技能水平提出了过分的要求，所以说现在并没有完全运用起来，未来的技术发展趋势整体是朝这个方向走的。现在我们就先来认识一下，持续集成、交互、部署的概念很有必要。

 

 

 

持续集成（continuous INTEGRATE）：

持续集成是指软件个人研发的部分向软件整体部分交付，频繁进行集成以便更快地发现其中的错误。

 

持续交付（continuous DELIVER）

持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的,预演境。

 

持续部署 (continuous deployment )

持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。

 

 

 

企业如何做到持续集成、交互、部署呢？正如网络流行语：“这个问题充钱就能解决”，大量的私有云厂商通过容器化技术已经打通整条链路：无论是自动化测试、持续集成、持续交付、自动化部署都有较成熟的解决方案。

如果企业不愿意购买现成的解决方案，那就只能自己动来实践，当然这个摸索过程会长一些，但也会更贴近企业的实际环境。接下来我们要讲的是一个真实的企业产品集成部署解决方案。（注：不一定完全适合你们企业，但借鉴下总是可以的）