闲亭信步（KISS）

本文已发表在 InfoQ中文站的《持续集成》专栏，关于“持续集成”和“持续交付”更多的文章、视频资源请访问“持续交付中文站”,http://www.continuousdelivery.info/index.php/resources/。在前文《软件自我识别》中，我们讨论了如果使软件做到自我识别，以促进自动化部署和版本检测等工作。 随着互联网的飞速发展，以及基础设施的改进，越来越多

本文是《Lean Startup》一书的作者Eric 在2009年发表的一篇博文，他是IMVU的创始人之一。文中并没有讨论如何做持续部署，而是讨论了一个更关键的问题：“IMVU为什么要做持续部署？”这也充分地表达了他关于“Learning from production and customer”的观点。在我所倡导的Lean Startup所有实践中，没有哪个实践比持续部署更有争议（持续部署是

过去十年中，一个划时代的改变就是：基于Web的业务模式对传统企业业务模式的冲击。亚马逊就是历史最长，也最明显的例子之一，而越来越多的公司（从航空到金融服务）开始依赖软件打造其竞争优势了。​依靠软件来运行的业务有两个关键组件：一是你想如何改变世界的愿景，二是尽早收集用户的反馈。精益创业运动特别强调反馈的重要性，这不仅仅体现在创业公司。像亚马逊、NetFlix、和脸谱这样的公司也持续不断地对其网站

IMVU是国外一家游戏社交网络公司，《精益创业》作者是其创建者之一。我在2011年由InfoQ组织的QCon大会上分享的《持续交付》相关话题中介绍过该公司的情况。当时该公司只有不到40名工程师，每天部署50次。部署流程是这样的：在部署前需要运行一个很大的单元测试集合，总运行时间为15~20分钟（当然是分布式执行，而不是在一台机器上啦）。一旦通过，即可部署到生产环境中。当然，这么做有一个

很多开发团队通常严重依赖于版本控制系统的分支功能。分布式版本控制系统让分支操作更加方便。然而，在《持续交付》一书中描述的很多非常规言论中，就有一条是：“使用分支，你就无法做持续集成”。根据定义，如果你有代码在某个分支上，那就没有集成。有一种很常见的情况，会让人很自然地想到利用版本控制工具的分支功能：那就是“对应用程序进行大规模改造时”。然而，还有一种替代这种真实分支的做法，技术上叫做“抽象分支（B

《爱丽丝梦游仙境》中有一个场景，兔子说：“你必须跑得非常快，才能一直站着。”这句话简直就是当前商业环境的真实写照。那么，如何才能跑得快呢？自从“互联网＋”被提出来以后，“转型”成了热门词。向哪个方向转，如何“转”呢？

在MacOS下，Docker　images保存在哪个路径下

通过Dockerfile 文件为linux images 添加新用户