Browsed by
标签:部署

持续部署,并不简单!

持续部署,并不简单!

感谢 @常新居士 投递此文 】

这几年,持续集成随着敏捷在国内的推广而持续走热,与之相伴的持续部署也一直备受关注。自前两年,持续交付这个延续性概念又闯进了国内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 的持续集成环境(再加上持续集成所要求的测试和过程)就可以很好地满足上述要要求,此方案的结构如下:

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (22 人打了分,平均分: 4.55 )
Loading...
预发布环境,Tag发布机制和可重复的部署过程

预发布环境,Tag发布机制和可重复的部署过程

下面文章由网友吕毅投递,源文是:http://blog.lvscar.info/?p=427

—————————————————————————————————————————————

周末聚会,无意间聊起建筑行业。自己是搞软件开发的,我们的行业从建筑设计/施工过程中借鉴了大量的概念,隐喻,名词。可以说软件就是现实中伴随整个人类历史发展的“建筑”在虚拟空间中的投影。有个两年前问过其他朋友的问题,这次友人又再次提起,“为什么建筑设计过程中没有普遍性的采用版本控制呢?” 瞎扯了一干各种原因后,我们几乎同时想到一个名字”Joel”,建筑设计行业或许缺乏像Joel Spolsky一样十数年如一日,把自己丰富的经验和深入的思考转化成一篇篇文章以向新人传授软件开发过程中那些容易被忽略的概念。高傲的黑客们会对CMMI之类的认证抱以鄙夷之情,但对Joel整理出的12条写出更好软件的”最佳实践”,大家甚至把此称为审视其他团队开发过程的“Joel TEST”以推崇

这12条测试如下:

1. 是否启用版本控制?

2. 是否可以一步构建?

3. 是否进行每日构建?

4. 是否有bug跟踪列表?

5. 是否在修改bug后,才开始写新代码?

6. 是否及时更新工作计划?

7. 是否在开发前编写了大家一致认可的功能文档?

8. 是否有安静的工作环境?

9. 是否在使用最好的软件开发工具?

10.是否有专职测试人员?

11.是否在面试时以实际编写代码来检查求职者?

12.是否利用陌生人进行可用性测试?

你所在的团队符合其中的几条呢? 觉得这些条目太一般,软件开发原本就该如此? Joel Test写于十年前,一个Windows XP,Mac OS X,Ubuntu都还没有面世的年代。 如果你觉得这些条目有些过时了,Google中搜索“Joel Test”,你可以看到这十年内很多对此进行更新的尝试, 比如这两个页面“The Joel Test Update for 2010″,“Joel Test for web dev”.

阅读全文 Read More

好烂啊有点差凑合看看还不错很精彩 (6 人打了分,平均分: 4.17 )
Loading...