持续集成之六部代码提交

上一篇 / 下一篇  2012-07-30 15:37:46 / 个人分类：持续集成

查看( 1517 ) / 评论( 0 ) / 评分( 0 / 0 )
六步代码开发习惯如下：
基于最小工作单元的6步代码修改流程：
1) 从目标分支同步到本地拷贝
2) 在本地拷贝中修改代码并添加测试
3) 在本地自动化地验证本地修改
4) 从目标分支做一次同步。
5) 做本地验证，确保合并后能构建通过，之后同步到目标分支。
6) 在集成计算机上对目标分支做自动化验证，通过后修改才算完成。
  1. 一开始，我将已集成的SVN上的源代码复制一份到本地计算机。这可以通过从源码管理系统SVN的trunk上check out一份源代码做到。
  2. 现在我拿到了工作拷贝，接下来需要做一些事情来完成任务。这包括修改产品代码和添加修改自动化测试。
  3. 一旦完成了修改，我就会在自己的计算机上启动一个自动化build---(参照代码组织规范，会提供localBuild脚本来辅助这个过程)。
  4. 当我build成功后，我就可以考虑将改动提交到源码仓库。但麻烦的情况在于别人可能已经在我之前修改过trunk。这时我需要首先把别人的修改更新到我的工作拷贝中，再重新做build。如果别人的代码和我的有冲突，就会在编译或测试的过程中引起错误。我有责任改正这些问题，build并和trunk的代码同步。
  5. 一旦我本地的代码能通过build，并和trunk同步，我就可以把我的修改提交到源码仓库。
  6. 然而，提交完代码不表示就完事大吉了。我们还要做一遍集成build，这次在持续集成服务器上并要基于trunk的代码。只有这次build成功了，我的修改才算告一段落。持续集成服务器上可能有多个阶段的构建，我也会关注我的提交是否会通过后面阶段的构建。
在代码提交的频率上，目标是大家每日进行至少1次的有效代码提交，并保证主干上代码是可编译运行的。这样QA可以随时跟进项目的进展,尽快进行测试
 

收藏 举报

TAG:

 

评分：0

我来说两句

Open Toolbar