持续交付实践（一）：基于阿里云的持续交付设计

名词解释:

ecs: 阿里云服务器，虚拟机

oss: 阿里云分布式文件系统

Jenkins: 持续集成工具

ansible: python写的配置管理工具

svn: 代码库

---

version1. 

步骤说明: 

1. 提交代码到svn

2. Jenkins监听svn中production目录变化，触发编译任务

3. 编译通过之后，触发测试集群自动进行测试，测试通过的包package发布至oss上

4. 自动/手动触发部署，发布机从svn/git中checkout下来playbook，执行部署动作

   a. 每个ecs从oss上下载package (ecs & oss在阿里云内网通信，不收流量费。。)

   b. 停服务，及检查

   c. 执行部署动作

   d. 启动服务，及检查

5. 编译&测试通过的包package，可以通过oss提供的api/sdk(sscmd)推送到oss对应的目录上，oss发布目录是需要有规范。

遇到的问题:

1. jenkins及发布机需要搭在云上(ecs)，要控制部署所有的线上ecs；但源码管理所用的svn不(适宜)在云上，云下的svn和云上的Jenkins怎么联动? (前厂完全不会有这个问题啊，都是自己的机器...)
2. 这里说的是持续交付，而不单纯是持续部署，所以开发环境、测试环境怎么做到自动化部署?

=== 2015.06.15 update ===
解决遇到的问题
1. 决定把svn集群搭建在阿里云ecs上，通过外网地址，将代码commit到svn（需要考虑安全性）
2. jenkins集群搭建在阿里云ecs上，人力有限逐级来做，持续部署->自动化测试->持续交付。

=== 2015.06.18 update ===

1. svn集群搭建在内网，编译集群搭建在内网，由内网jenkins编译并推包到oss

2. 手工触发部署，部署时，制定版本号；最新的可以部署的版本，写入文件latest_stable，并上传至OSS

http://blog.chinaunix.net/uid-15790905-id-5086920.html


`2016-01-23整理`
最新架构图如下