持续部署，并不简单！
【感谢 @常新居士 投递此文 】
这几年，持续集成随着敏捷在国内的推广而持续走热，与之相伴的持续部署也一直备受关注。自前两年，持续交付这个延续性概念又闯进了国内IT圈，慢慢开始在社区和会议中展露头角。许多不明真相的群众跟风哭着喊着要“上”，而许多前CI的半吊子玩家换件衣服就接着干，有的甚至衣服都来不及换……。国内的这些土财主如果不巧请了某些所谓的战略家，除了建了一堆持续集成环境，以及每天嚷嚷着要这个要那个，混乱的状况在根本上没有得到改善。本文无意费力探讨持续集成和持续交付的概念，而是打算谈谈对于大型软件企业，以持续集成为基础实现持续部署（交付）时，所要面对的问题以及可行的解决方案。地主老财们，夜黑风正猛，山高路又远，注意脚下……
And God Said, Let there be light: and there wa— GENSIS, Charpter 1, King James
一、起步
先来讲个故事……
几年前，一对留美的夫妇通过朋友找到我，让我帮忙在国内组建一个开发团队，该团队负责为其开发一款基于社交网络的客户关系管理软件,（暂且称之为项目A）。这个项目除了尚不清晰的需求范围和很紧的期限外，作为业内人士的老公Richard根据眼下流行的软件开发过程还提了诸多额外的要求：
- 功能要及早交付（以便拿去和潜在的投资人洽谈）
- 功能在部署到生产环境前要先部署的一个测试环境（Richard要试用后给予反馈）
- 功能必须经过测试（长期作为软件外包的甲方，对质量要求严格）
- 要减少后期维护的工作（美国人精贵，少雇一个是一个）
- 支持协同开发（以便维护人员及早介入）
- ……
这正是持续集成所要解决的典型场景。针对Richard的要求，我们只要建立一个基于Hudson（现在叫Jenkins）+Maven +SVN 的持续集成环境（再加上持续集成所要求的测试和过程）就可以很好地满足上述要要求，此方案的结构如下：
(27 人打了分，平均分： 4.15 )
Loading...