持续集成实践之_CruiseControl

OpenDoc Series’  持续集成实践 之 CruiseControl  V1.0  作者：张辰雪 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  2  文档说明 参与人员： 作者 联络 张辰雪  (at) 为 email @ 符号 发布 版本 日期 作者 说明  1.0  2005.05.1  张辰雪 原创  1.0  2005.06.1  夏昕 文档格式编排  OpenDoc版权说明 本文档版权归原作者所有。 在免费、且无任何附加条件的前提下，可在网络媒体中自由传播。 如需部分或者全文引用，请事先征求作者意见。 如果本文对您有些许帮助，达谢意的最好方式，是将您发现的问题和文档改进意见及时反馈给 作者。当然，倘若有时间和能力，能为技术群体无偿贡献自己的所学为最好的回馈。  Open Doc Series目前包括以下几份文档： n  Spring 开发指南 n  Hibernate开发指南 n  ibatis2开发指南 n  Webwork2开发指南 n 持续集成实践之 CruiseControl  以上文档可从 http://www.redsaga.com获取最新更新信息 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  3  持续集成实践之 CruiseControl 篇 目录 目录...................................................................................................................................................3  前言...................................................................................................................................................5  读者...................................................................................................................................................5  约定...................................................................................................................................................5  持续集成的概念................................................................................................................................5  剖析 CRUISECONTROL ................................................................................................................7  CC框架  8  Build Loop..................................................................................................................................9  CC 插件（Plugin） .................................................................................................................10  CC的配置文件  12  ......................................................................................................................13  ....................................................................................................................14  ..............................................................................................................................14  ......................................................................................................................................17  ...........................................................................................................................17  ..........................................................................................................................17  .................................................................................................................................17  CRUISECONTROL应用举例.......................................................................................................17  基础知识： 18  准备工作： 18  安装和准备项目持续集成的环境  18  准备 workspace........................................................................................................................18  下载 CC 并创建 cruisecontrol.jar ............................................................................................19  创建 cruisecontrol.war .............................................................................................................21  例子 HELLOWORLD!  22  将 helloworld 导入 CVS ...........................................................................................................22  准备配置文件..........................................................................................................................24  启动 CC...................................................................................................................................26  结束语 .............................................................................................................................................30  附录一  HELLO WORLD!与 VSS .................................................................................................30  将 HELLOWORLD导入 VSS  30  准备配置文件  31 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  4  附录二  OUT OFMEMORYERROR的解决

方案

气瓶 现场处置方案 .pdf气瓶 现场处置方案 .doc见习基地管理方案.doc关于群访事件的化解方案建筑工地扬尘治理专项方案下载

........................................................................33  参考资料 .........................................................................................................................................34 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  5  前言 持续集成（Continuous  Integration）这个术语源自  XP（极限编程）的一个最佳实践，随着  XP 社区在近几年的壮大，XP 的很多实践得到了广泛的推广，持续集成就是其中之一，但 是持续集成并非 XP 的专利，持续集成完全可以应用在采取非 XP 

方法

快递客服问题件处理详细方法山木方法pdf计算方法pdf华与华方法下载八字理论方法下载

（例如 RUP）的项目 里面。持续集成也不是一个新的概念，在这个术语出现之前，日创建（daily  build）提供同 样的含义，他们的主要区别就在于实施的频率上，随着 XP 社区的大师级人物 Martin Fowler  的一篇《Continuous  Integration》正式为其正名，持续集成这个术语就越来越多地出现在原 来日创建出现的位置。同时，Martin Fowler 所在的公司 ThoughtWorks 开放了其持续集成的 工具  CruiseControl 的源代码，持续集成对于大部分开发人员来说就不再只是停留在口头上 的漂亮的术语，任何人在掌握了持续集成的基础理论后，都可以使用  CruiseControl 来体会 持续集成在项目开发中的巨大威力。 本文将简单地介绍持续集成的一些基本概念， 持续集成到底是做什么的？持续集成的关键点 在什么地方？怎么结合工具进行实践？最后一步步地演示怎么使用  CruiseControl 这个目前 最热门的持续集成工具。 读者 项目主管，开发人员，测试人员，要求熟悉 Apache Ant，CVS 或者 Visual SourceSafe。 约定 l 本文的例子以 Windows 2000 作为操作系统平台。 l 本文以 Java 项目为例，对于.net 的持续集成请参考 CruiseControl.NET的官方文档。 l 本文不是 CruiseControl 官方文档的中文版，本文注重讲解 CruiseControl 的应用，关于  CruiseControl 的配置文件的各参数的详细信息请参考官方文档。 l 本文中的创建均指 build。 l 本文的源码控制系统指版本控制系统，源码库就是资料库（Repository），主要是因为本 文重点针对的是源码。 持续集成的概念 在没有应用持续集成之前，传统的开发模式是项目一开始就划分模块，然后等所有的代码都 开发完成之后再集成到一起进行测试，随着软件技术的发展，各种软件方法百花齐放，软件 规模也在扩大，软件需求越来越复杂，软件已经不能简单地通过划分模块的方式来开发，需 要项目内部互相合作， 划分模块这种传统的模式的弊端也越来越明显，由于很多 bug在项目 的早期就存在，到最后集成的时候才发现问题，开发者需要在集成阶段花费大量的时间来寻 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  6  找 bug的根源，加上软件的复杂性，问题的根源很难定位，甚至出现不得不调整底层架构的 情况，在这个阶段的除虫会议（bug  meetings）特别多，会议的内容基本上都是讨论 bug是 怎么产生的，最后往往发展成为不同模块的负责人互相推诿责任。 持续集成最大的优点是可以避免这种传统模式在集成阶段的除虫会议。 持续集成主张项目的 开发人员频繁的将他们对源码的修改提交(check in)到一个单一的源码库， 并验证这些改变是 否对项目带来了破坏，持续集成包括以下几大要点： u 访问单一源码库，将所有的源代码保存在单一的地点（源码控制系统） ，让所有人都能 从这里获取最新的源代码（以及以前的版本）。 u 支持自动化创建脚本， 使创建过程完全自动化，让任何人都可以只输入一条命令就完成 系统的创建。 u 测试完全自动化，要求开发人员提供自测试的代码， 让任何人都可以只输入一条命令就 运行一套完整的系统测试。 u 提供主创建，让任何人都可以只输入一条命令就可以开始主创建。 u 提倡开发人员频繁的提交（check in）修改过的代码。 持续集成的关键是完全的自动化，读取源代码、编译、连接、测试，整个创建过程都应该自 动完成。对于一次成功的创建，要求在这个自动化过程中的每一步都不能出错，而最重要的 一步是测试，只有最后通过测试的创建才是成功的创建。 在持续集成里面创建不再只是传统的编译和连接那么简单，创建还应该包括自测试，自测试 的代码是开发人员提交源码的时候同时提交的，是针对源码的单元测试（源自 XP 的实践）， 将所有的这些自测试代码整合到一起形成测试集， 在所有的最新的源码通过编译和连接之后 还必须通过这个测试集的测试才算是成功的创建。 这种测试的主要目的是为了验证创建的正 确性， McConnell称之为“冒烟测试”， 在持续集成里面， 这叫做集成验收测试Build Verify Test， 简称 BVT。BVT测试是质量的基础，QA小组不会感受到 BVT的存在，他们只针对成功的 创建进行测试（如功能测试）。  BVT 测试应该尽量的详尽，详尽的测试才能发现更多的问题，而由此得到的反馈结果也更 有参考意义，测试应该全部执行完毕，这样得到的反馈结果才是完整的，而不是遇到错误就 放弃测试过程。 持续集成和日创建相比还有以下特点： u 持续集成强调了集成频率，和日创建相比，持续集成显得更加频繁，目前推荐的最佳实 践是每一个小时就集成一次。 u 持续集成强调及时反馈，日创建的目的是得到一个可以使用的稳定的发布版本，而持续 集成强调的是集成失败之后向开发人员提供快速的反馈， 当然成功创建的结果也是得到 稳定的版本。 u 日创建并没有强调开发人员提交（check  in）源码的频率，而持续集成鼓励并支持开发 人员尽快的提交对源码的修改并得到尽快的反馈。 从上面列出的续集成和日创建相比的特点来看，很明显， “频率”和“反馈”这两个词出现 的特别多， 持续集成有一个与直觉相悖的基本要点， 那就是 “经常性的集成比偶尔集成要好” 。  Martin  Fowler 认为对于持续集成来说，集成越频繁，效果越好 ，如果你的集成不是经常进 行的（少于每天一次），那么集成就是一件痛苦的事情，如果集成偶尔才进行一次（一周甚 至一个月） ，等到集成阶段发现 bug，然后找原因解决 bug，会耗费你大量的时间与精力，而 且这种方式有点象传统的集成模式，这违背了持续集成的初衷。 根据 Martin Fowler 的观点，项目 bug 的增加和时间并不是线性增长的关系，而是和时间的 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  7  平方成正比，两次集成间隔的时间越长，bug增加的数量越超过你的预期，解决 bug付出的 工作量也越大，而你越觉得付出的工作量越大，你就越想推迟到以后去集成，企图到最后一 次性解决问题，结果 bug产生的就更多，导致下一次集成的工作量更大，你越感觉到集成的 痛苦，就越将集成的时间推后，最后形成恶性循环。 因此如果集成的结果是让你感到痛苦，也许就说明你应该更频繁地进行集成。频繁的集成和 及时的反馈鞭策着项目小组积极的面对问题， 而不是将问题推到最后来解决， 如果方法正确， 更频繁的集成应该能减少你的痛苦，让你节约大量时间。 因为持续集成最终是通过测试来验证创建，所以你会发现对于持续集成的频率的要求跟  Kent Beck提出的测试驱动的开发方法里面测试第一的理念完全一致。 需要注意的是从项目的一开始就引入持续集成可以尽早的发现 bug，但是并不代表持续集成 可以帮你你抓到所有的 bug。持续集成的排错能力取决于测试技术，众所周知，无法证明已 经经过测试的代码就已经找到了所有的错误。 前面列举了持续集成这么多优点，但是创建一个持续集成的环境技术上是比较复杂的，也需 要一定的时间，关键是在于持续集成可以“及时”抓到足够多的 bug，从根本上消除传统模 式的弊端，这就已经值回它的开销了。 对于持续集成的概念简单介绍到这里，下面开始持续集成的实践之旅。目前支持持续集成的 工具已经越来越多，主流的包括 AntHill（商业化工具），CruiseControl，Apache  Dump。本 文将以 CruiseControl 为例来体会持续集成实践。 剖析 CruiseControl  CruiseControl 是一种持续集成过程的框架，包括了邮件通知，ant 和各种源码控制工具的插 件。并提供了  web  接口，用于查看当前和以前的创建的结果。下面将用  CC  来代表  CruiseControl。 首先让我们看看下面的 CC 部署图，这个图描述了持续集成的硬件环境，图中包括了一台独 立的源码库服务器，以及开发人员的终端（同时也是源码库服务器的客户端），我们注意到  CC 在一台独立的服务器上运行，这是推荐的一种结构，出自对性能和不影响原有的开发环 境的考虑。当然你可以将 CC 放在源码库的同一台服务器上甚至某个开发人员的终端上，从 这个图可以看出可以很容易的将 CC 引入到现有的开发模式中， 只需要增加一台独立的服务 器就可以了。 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  8  CC 框架 在学习使用 CC 之前， 我们有必要研究一下 CC 的框架， 这对我们了解 CC 的设计原理和 CC  对持续集成的支持程度很有帮助。通过前面对持续集成的一些概念的讲解， 我们已经知道持 续集成的几个要素，下面我们从工具的角度来看 CC对这几个要素的支持。 持续集成的要点  CC的支持 单一代码源  CC 通过相应的插件支持对 CVS,VSS （Visual SourceSafe） ,ClearCase  等各类版本控制软件的源码库的访问。 自动化创建脚本  CC 通过 Build  Loop 支持自动化创建，并通过 CC 插件支持 ant，  maven  等创建工具。CC  对创建的支持实际上是通过一个代理 （proxy）来完成的，你可以选择 Ant,Maven这些流行的创建工具 自测试的代码 间接通过 ant 等自动化创建工具来支持对自测试的调用，但是这取 决于项目自身是否提供自测试代码，CC 只是通过  ant 等工具激活 对测试代码的调用。 主创建 间接通过 ant 等自动化创建工具支持，要求相应的 ant 或者 maven  脚本提供了主创建任务。 检入代码 属于版本控制的范畴，要求开发人员自己检入代码。 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  9  Build Loop  前面在讨论持续集成的时候讲到其最重要的特征之一是自动化， 而 CC 的 Build Loop就是为 支持自动化而设计的，Build Loop也是 CC 的核心。  Build Loop 从字面上理解就是循环创建的意思，CC 提供了一个  daemon 进程，该进程自动 根据配置的时间间隔（也可以指定某个具体时间）读取  CC  配置文件并进行循环创建 （build cycle），每次 CC 都会重新加载配置文件（修改了配置文件不用重新启动 CC）。  Build Loop过程中所做的工作如下：访问源码源码控制系统，查看是否有代码被修改，如果 有，获取源码的新版本，并根据配置对源码进行一次 Build，创建一个日志文件，最后向开 发人员通知 build的结果，活动图如下： 访问源码控制系统 Build（创建） 等待创建 发布Build（创建）结果 没有检查到变化 检查到变化 创建时间到 未到创建时间 Build Loop 中断 因为 Build Loop是根据配置文件的内容来进行的，根据上面 BuildLoop所做的工作，我们大 概可以猜出配置信息主要应该包括：定时创建的时间和源码库的访问信息（定义检查源码变 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  10  化情况），创建任务信息（如指定 Ant 文件） ，记录日志（创建结果），通知（通知的内容可 以定制）。现在对配置文件有个初步印象，在下面学习配置文件的配置项的时候就会轻松很 多。 补充说明，CC 的 Build Loop刚开始只支持单个项目，现在 CC 的 Build Loop已经支持多项 目(multiproject)。  CC 插件（Plugin）  CC设计思想是one­size­fits­all， 也就是CC是由一个很精小 （但是很强大） 的核心 （Build Loop） 以及一些外部插件组成，这给使用者提供了很大的扩展空间，使用者可以根据需要扩展 CC  的功能（提供新的插件），而且 CC 是开源项目，你还可以查看源码并修改 CC 提供的插件。  CC 提供了六种不同类型的插件：Bootstrapper，SouceControl，Builder，LabelIncrementer，  Publisher 以及  Listener，CC 的配置是围绕这些插件展开的，下面对这些插件进行一个简单 的介绍： l  Bootstrapper：在 CC 进行创建之前运行，是创建前的准备工作 l  SourceControl：访问源码源码控制系统（如 CVS，VSS，ClearCase等等），查看源码自 上一次 Build之后是否被修改过，并据此决定是否需要进行下一次 Build。 l  Builder：对项目进行创建，熟悉 ANT的使用者应该很清楚创建的含义，这里简单提一 下，一次典型的创建包括了对项目源码的编译，测试，打包 l  LabelIncrementer：用于对源码打标签，自动增加标签的编号 l  Publisher：用于发布创建的结果，可以通过 email 的方式通知开发人员。 l  Listener：用于处理一些项目有关的事件（CC 2.2 之后提供的新的功能）。 下面说说 CC 插件相关的配置，在早期的 CC，插件是需要注册的，在元素下面， 添加就可以了， 其中 name对应到你在 config.xml 使用到的插 件功能的名字，而 classname则是实际的插件的 Java类名，有点类似 ANT的。 最新的 CC 的新的特征是保持配置文件的精小，所以 CC 自带的插件会自动注册，不再需要 显示地在配置文件里面添加注册信息了， 如果你有第三方插件要使用，可以按照前面所讲到 的方法进行注册。 由于版本的向下兼容性，如果你很早以前就使用 CC，一直保留了插件注册的习惯，那么现 在还可以继续象原来那样使用。 下面给出一个插件注册的例子，里面配置的详细信息都省略了，只给出 XML文件中相应的 元素的层次结构：           持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  11                                            在这个配置文件里面，我们可以看到每使用到某个插件的功能，就会添加相应的注册信息， 例如： 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  12            就会对应到         至于该配置文件的细节，后面会有专门的章节来讲解，我们这里举这个例子主要是为了说明 插件使用和注册之间的关系。记住，新版 CC 对于 CC 自带的插件已经不需要手工配置注册 了。  CC 的配置文件  CC 的配置文件用于 build loop，默认文件名为 config.xml（如果使用其他的文件名，启动 CC  的时候需要手工指定该文件名，类似  ant 对  build.xml 文件的处理方式），该文件的 Builder  插件部分会引用相应的 build文件，如 ant，maven的 build文件。 关于 CC 配置文件的各配置项参数的详细资料，请参考官方文档：  http://cruisecontrol.sourceforge.net/main/configxml.html  这里只讨论配置文件中常用的各元素之间的关系。 主配置文件  config.xml 的根元素是，该元素很简单，没有什么需要配置的属 性。下支持三种元素，如下：         本文只讨论元素，其他两个元素在常规的场合可以不用，目前  CC 支持多个项目 （multiproject） ，因此可以有多个并行的元素。在元素下面都是跟 CC 插件 有关的配置项，结构如下：         持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  13                下面对其中几个常用的元素的意义和用法进行详细的讲解    的子元素就是Bootstrapper插件的配置信息， 在创建之前运行， 这个前面我们已经讲过了，下面的每一个子元素都是相互独立的，因此可以 同时配置有多个 bootstrapper。  CC 提供的  bootstrapper 包括了两个种类，一种用于向其他插件提供项目当前创建的状态， 还有一种是从某个源码控制系统更新本地文件，其中最常用到的  bootstrapper  是  和 （本文使用 CVS源码控制系统作为例子， 如果读者使用 Visual  SourceSafe或者 ClearCase，那么这里应该分别使用  或）。 前者指定了状态文件的位置，主要是用来访问项目当前创建 的状态，CC 的会将创建的状态写入这个文件，CC 的 web 用户 接口要向用户提供最近一次创建的信息， 其 web 组件会访问该文件来获得当前项目进行创 建 的 状 态 。 顺 带 讲 一 下    ， 其 作 用 跟  完全一样，不同的是状态文件保存在一个 FTP 上。 后者的作用有点难理解， 因为我们每次项目的创建都应该基于最新的代码， 因此在创建之前就要获得最新的项目文件， 如果你使用的是 ant， 这个工作是由 ant的 buildfile  来完成的，如果这个 buildfile本身在创建开始之前发生了变化，我们是不是应该先更新这个  buildfile，然后才通过 buildfile来对项目进行创建呢？就是为从源码控制系 统更新 buildfile文件而设计的 （还有一种替代方法是使用 wrapper buildfile， 这样就不用使用  了，wrapper buildfile也是推荐的方法，部分会进行详细的 讨论）。  应用举例：       关于和其他 bootstrapper 插件（如）的配置参数请参考官方 参考手册。 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  14    包括了 SourceControl 插件的配置信息，用于检查各个源码控制系统中是否 发生变化，会用到这里面的配置信息，如果检测到变化，会触发创建过程。  的属性 quietperiod （单位为秒） 定义了一个时间值。 如果 CC 检查到了变化， 会自检查到变化的源码控制系统的最后一次  check in  的时间开始等待，等待的时间由  quietperiod决定，等待结束之后才触发创建（build）过程，主要是防止有人在 check in的过 程当中就触发创建过程（可能 check in只做了一半, 这个时候触发创建显然是不正确的） 。 下面给一个 cvs 的例子：     下面是一个  vss 的例子（记得要在里面配置相应的），熟悉  ant 的读者可以看出，其实很多参数跟 ant 里面对应的任务是一致的：     还有对其他的源码控制系统如 pvcs,svn,clearcase的访问的配置都差不多， 请查看官方的参考 手册。    指定了创建的时间间隔，新的版本已经支持定义某个具体时间触发创建，这个新 的特征是为了满足 Nightly build的需要。  定时驱动，如果检测到变化，就执行所指定的 builder 的任务。 例子：       目前 CC 支持的 builder 插件包括了 apache的 ant 和 maven， 本文以 ant 为例讲解 builder 插 件的用法。 当 CC 启动 ant build时，ant 是作为独立的 java 进程被调用的，CC 提供了两种调用 ant 的方 式，第一种是使用 antscript 方式，第二种是使用和 CC 一起发布的 ant 。其中第一种是推荐 的方式，我们也将采用第一种方式，本文后面凡是使用到的地方，均指通过  antscript 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  15  方式来调用 ant。  Antsciprt 方式要求提供两个重要的参数， 一个是 antscript， 一个是 antWorkingDir， antscript  指定了一个独立的  ant 可运行的脚本文件，在  windows 下是％ANT_HOME%\bin\ant.bat，  antWorkingDir 指定了 ant 要运行的 build.xml所在的目录，例如：    关于 ant 的 build.xml 文件有两个访问的模式，第一个是前面我们讨论的时候 讲到了的插件，在 build loop运行前得到 build.xml 文件， 并保存在指定的位置，而我们的 ant builder 插件会在 build loop 过程中去访问这个文件，其 过程如下图： :CC Build Loop :CVS Repository :build.xml 更新build.xml() 创建或更新() cvsbootstrapper() ant build() build() 更新所有项目有关文件() build() 这种访问模式的特点是对于现有的项目的  build.xml 要进行修改，增加新的  target 对源码控 制系统的访问， 同时增加一个和 CC 创建有关的 target， CC 自带的例子采取的就是这种方式， 配置文件结构如下：         我们可以看出这种访问模式的缺点是对项目的 build.xml 有侵入性，除了项目原有的创建任 务之外，还要为  CC 添加新的创建任务。而且这种模式在创建逻辑上是很难接受的，首先 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  16  build.xml 保存在源码控制系统里面，需要 CC 通过更新 build.xml，然后在 创建阶段又通过这个 build.xml 的 checkout 更新整个项目的文件，同时也更新了自己，对于 刚接触 CC 的新手来说很难理解。 第二个模式是 wrapper buildfile文件模式， 我们不在下使用， 而是在文件系统的某个位置提供一个 wrapper buildfile文件，这其实也是个 ant 的 build.xml， 让 CC 直接去访问这个文件，然后通过这个文件再访问源码控制系统，获得新的源码和相应 的 build.xml，然后将创建目标转发到新的 build.xml，如下图： :CC Build Loop :wrapper buildfile :CVS Repository :build.xml build() build() 更新所有项目文件() 创建或更新() build() build() :项目文件 创建或更新()  wrapper  buildfile 模式的特点是需要增加一个独立的 build.xml，实际上是将第一种模式里面 对原有项目的 build.xml 增加的部分独立出来放到一个新的 build.xml 里面，并将创建转发到 项目的 build.xml，配置文件结构如下：           这种模式的优点是保持了原有项目的 build.xml 的完整性，对于原有的项目不需要做修改， 而是通过添加新的文件的方式来完成。 在 CC 应用举例的部分我们就会体会到一个完整的 wrapper buildfile例子。 持续集成实践之 CruiseControl篇  Version 1.0  June 2, 2005  So many open source projects. Why not Open your Documents?  17    指定项目日志保存的地点，主要是合并项目创建过程 junit 测试结果的

报表

企业所得税申报表下载财务会计报表下载斯维尔报表下载外贸周报表下载关联申报表下载

文件(xml)。  的用法很简单，通常是指定 CC 的合并日志的目录就可以了，例如：         的子元素包括了 Publisher 插件的配置信息 在 build loop结束之后将运行 Publishers，无论 build 是成功还是失败，都会运行 publisher， 发布 build的结果。  下面最常用的  publisher  插件是 ， 和