什么是持续集成?

什么是持续集成,它有什么好处?

这是迄今为止我读到的最好的解释。

简单来说,只要一个检入进入一些版本控制系统(CVS等)就可以重build你的项目。 这可以扩展到包括运行testing,一直到生成一个CD镜像,安装在虚拟机,安装产品和运行完整的testing。

它具有简单的优点,即在代码更改时尽可能早地突破系统。 它不仅在代码中检测到中断,还突出显示谁造成了中断。 这种心理效应是非常有效的,以鼓励在检查之前良好的testing!

确保您的软件开发过程的各个方面都是排队的,以允许每天创build您的产品的工作版本。 这是极限编程的一部分。

这涉及到构build自动化,自动化testing,日常检查,使用源代码库等方面的事情。但最终目标是帮助整个项目按照核心敏捷原则运行,以便您提前和经常交付。 这反过来又可以帮助您充分利用用户的反馈意见等

+1链接到福勒的页面。

就个人而言,我发现只要有东西没有编译就知道“很好”,因为我们有一个单一的构build(是的,我们开发的生产版本,我们真棒)的做法很差。 我离开之前还没有完成综合testing阶段。

不过,过了一段时间,它减less了大量的编码变化(与“检查和祈祷我的变化不冲突”是相当猖獗的)。 最终,大多数开发人员为了从CC.Net托盘图标得到确认,开始经常进行小的更改。

总的来说,如果我们必须知道我们可以立即发送一个构build,我感到非常欣慰。 如果我们已经集成了几个烟雾testing,我认为压力水平会大大降低。

只是为了刷新。 此时,持续集成(CI)和持续交付(CD)之间存在巨大差异。 虽然大多数post上面描述的CD我会尝试展示CI如何扩展现在的CD定义。 拥有构build软件包并自动部署新版本应用程序所需的所有工具是CD的重要组成部分。 除了这个testing自动化(基于三级validation:一般健康检查,详细统计和历史条目)和一个适当的pipe理,您正在创build一个非常好的CI。 仅仅因为这样一个扩展的定义才能build立非凡的云工具。 想想muleESB或esbeetle.com。 对于他们来说,CI是自然的,尽pipe只有第二个支持ESB和ETL组件。

我希望这是有帮助的。