每日构建与持续集成联系与区别


		每日构建与持续集成联系与区别
 
1）持续集成（Continuous Integration）贵在速度，强调一个快速反馈。 
     比如我一签入代码，就立刻集成，给我一个反馈，我要知道我的代码是否破坏掉了构建。 
     持续集成是和单元测试结合在一起的，也就是说一般持续集成的时候都要做单元测试。但持续集成中不能加入更多影响“快速反馈”这条宗旨的东西，比如不能加入大量的集成测试，冒烟测试的代码，尤其是当这些代码严重影响到集成时间的时候。
     持续集成一般由每次签入代码触发。我先签入代码我就要先看到构建结果，你后签入，你就要排在后面。这就要求构建时间不能太长。否则在构建的时候有很多人签入代码了，就很难知道到底是谁的代码破坏了集成,很难定位问题，反映签入代码的问题，不能给签入代码的人快速提供明确的信息。因为一般由后签入代码的人来保证集成的成功。
     持续集成可以是增量构建，也可以是完全构建。当完全构建时间很长的时候， 一般采用增量构建。 
     我记得Martin Flower关于持续集成写过两篇文章，如果我没记错的话，好像是第一篇比较鼓励放入很多的测试到持续集成中，但是后来他对自己的说法进行了修正，说不能把很多影响集成的东西都加入进去，要保持快速集成，快速反馈，否则很难做到持续集成。
      
     刚查了下最新版的《Continuous Integration》。上面对持续集成的实践是这样概括的，更说明了持续集成要快速反馈的重要性。 
  
     # Practices of Continuous Integration 
         * Maintain a Single Source Repository. 
         * Automate the Build 
         * Make Your Build Self-Testing 
         * Everyone Commits To the Mainline Every Day 
         * Every Commit Should Build the Mainline on an Integration Machine 
         * Keep the Build Fast 
         * Test in a Clone of the Production Environment 
         * Make it Easy for Anyone to Get the Latest Executable 
         * Everyone can see what's happening 
         * Automate Deployment 
  
     
  
     2）每日构建（daily build），这个提法最早的出处，我也不知道在哪里，不过看过《微软的秘密》这本书，微软很早就做每日构建了，忘记看过Steve-McConnell啥文章，还是书了，他也提到了每日构建。
  
     我自己感觉每日构建在快速反应上没有持续集成那么强，但是他更强调的是质量更能衡量项目的进度。         
     --- 由于持续集成的宗旨，决定了他不可能加入很多的测试，而每日构建则不然我们知道每日构建一般都会安排在夜里进行构建，这个时候我们有充足的时间来做构建，那么这个时候我们就可以做更多的事情，比如代码质量检查，命名规范单元测试，测试覆盖率，集成测试，冒烟测试，代码安全性检查.....等等都可以这里来做。对代码，对构建的要求更高。许多在持续集成中没能发现的问题，在这里都能发现。
     --- 每日构建，因为是在晚上执行，会把当天所有的变化的代码都一起做集成，而不像持续集成是每次仅仅把自己的代码和以前的代码做集成那样。持续集成可以是增量构建的，但是每日构建却总是一个完全构建。
     --- 每日构建是项目的心跳线。一般来讲，通过每日构建我们就能看到项目的进度。比如今天有5 个bug的代码都提交了，第二天我们发现每日构建成功了，那么项目就又往前迈了一大步，项目又有所进展了。

补充：软件开发 , C++ ,