<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Jenkins on Tony Bai</title><link>https://tonybai.com/tags/jenkins/</link><description>Recent content in Jenkins on Tony Bai</description><generator>Hugo</generator><language>zh-cn</language><copyright>2004-2026 Tony Bai. 版权所有.</copyright><lastBuildDate>Thu, 26 Dec 2013 00:00:00 +0800</lastBuildDate><atom:link href="https://tonybai.com/tags/jenkins/index.xml" rel="self" type="application/rss+xml"/><item><title>只为那一抹释然</title><link>https://tonybai.com/2013/12/26/just-for-being-relieved/</link><pubDate>Thu, 26 Dec 2013 00:00:00 +0800</pubDate><guid>https://tonybai.com/2013/12/26/just-for-being-relieved/</guid><description>_一切没有目标的努力，都是瞎忙活儿。_                                                     _\- Tony Bai_ 刚实施回来，就又投入到新工作中，到今天才有那么一点点时间写写这件事儿。 **\* 缘起** 我们的遗留系统性能一直不高，导致这一局面的因素有很多，比如最初设计和实现的“考虑不足”、后续维护人员的“随波逐流”甚至缺少勇气对影响性能...</description></item><item><title>做正确的事要趁早</title><link>https://tonybai.com/2012/08/02/do-right-things-early/</link><pubDate>Thu, 02 Aug 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/08/02/do-right-things-early/</guid><description>最近闲暇时间在策划实施两件事儿：一是产品的自动化回归测试；二是尝试在项目中使用一些静态代码语义分析工具。我觉得这两件事是应该做的正确的事，对提升产品质量，提前发现产品中潜在的缺陷都大有裨益。但在做的过程中才感觉到：现在做有些晚，正确的事要趁早做。 去年自动化测试组发布了自动化测试框架的第一个版本，我们的产品参加了试点。但经过自动化测试组大半年的投入，效果十分有限，根本没有达到我的预期。最主 要的问...</description></item><item><title>buildc 0.1.9版本发布</title><link>https://tonybai.com/2012/07/19/buildc-0-1-9-release/</link><pubDate>Thu, 19 Jul 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/07/19/buildc-0-1-9-release/</guid><description>随着buildc使用的深入，越来越多的新需求暴露了出来。为了满足这些需求，我们组的小兄弟又对buildc进行了一些改造，这些变化如下： 1、支持将多个子工程打包到一个安装包中 最初buildc的设计思想是为每个子工程单独制作安装包，这样具有很强的灵活性。但在对现有N个工程进行构建脚本改造的过程中发现，有些工程间存在严重 依赖，比如工程A是一个业务级公共库工程，工程B和工程C都依赖工程A构建后生成的...</description></item><item><title>buildc 0.1.8版本发布</title><link>https://tonybai.com/2012/07/02/buildc-0-1-8-release/</link><pubDate>Mon, 02 Jul 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/07/02/buildc-0-1-8-release/</guid><description>buildc这个小工具逐渐在项目组内部扩大了使用范围，还有一名专门的同事负责为每个项目制作安装包工程，这样也可以在使用中发现buildc的问题。 本次buildc 0.1.8的相关修正以及新增的feature就是我的这位年轻同事一手操刀完成的，他也是一个python新手，同样也是边翻手册边进行编码的。这次改动主要集中在templates目录下的几个文件，这里的文件多为因工程的不同而异的。 这次bu...</description></item><item><title>buildc 0.1.5版本发布</title><link>https://tonybai.com/2012/04/13/buildc-0-1-5-release/</link><pubDate>Fri, 13 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/13/buildc-0-1-5-release/</guid><description>这两天对buildc的改动比较频繁，今天又修正了一些问题，也增加了一些小功能。主要包括这么几点： 1、在Make.rules.in中增加了STATIC\_LIBS和DYNAMIC\_LIBS 项目源代码和项目中单元测试代码使用同一个Make.rules，也此编译时也就共享同一个LIBS变量。对于静态共享库还好说，但对于动态共享库，诸如Oracle的instantclient库，单元测试代码中即使没...</description></item><item><title>buildc 0.1.4版本发布</title><link>https://tonybai.com/2012/04/12/buildc-0-1-4-release/</link><pubDate>Thu, 12 Apr 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/04/12/buildc-0-1-4-release/</guid><description>年后buildc开始逐渐在产品线的项目里应用了，随之而来的是大家反馈的各种意见和bug。尤其是bug，我都会很认真地应对，也会及时发布相应的版本修复这些bug。buildc 0.1.4版本就是一个bugfix版本，其修复的bug源于今天上午的一次持续集成的失败。 上午收到Jenkins发送的一个&amp;#34;build failed&amp;#34;的mail，一个安装包项目的CI job执行失败了，于是到Jenkins w...</description></item><item><title>使用Jenkins实现多平台并行集成</title><link>https://tonybai.com/2012/02/15/intergating-on-multiple-platforms-simultaneously-using-jenkins/</link><pubDate>Wed, 15 Feb 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/02/15/intergating-on-multiple-platforms-simultaneously-using-jenkins/</guid><description>我们的后端C应用都是支持跨平台的，至少目前在Linux和Solaris上运行是没有问题的，这样一来我们在配置持续集成环境时就要考虑如何实现在代码Commit后触发多平台并行(同时)集成这个需求。 之前使用Buildbot时是通过为一个Scheduler配置多个Builder满足这个需求的。但现在要换成Jenkins，我们如何来实现呢？昨天在折腾Jenkins时我把问题想简单了，今天细致查看了一下B...</description></item><item><title>折腾Jenkins</title><link>https://tonybai.com/2012/02/14/install-and-configure-jenkins/</link><pubDate>Tue, 14 Feb 2012 00:00:00 +0800</pubDate><guid>https://tonybai.com/2012/02/14/install-and-configure-jenkins/</guid><description>Buildbot是产品线C应用项目中采用的唯一持续集成工具，一直以来用得还不错。但前些日子部门负责过程改善的同事找到我，说今年部门计划统一各个项目组所使用的Continuous Integration工具，Buildbot有些小众，没有入大家的法眼，部门期望使用的是Jenkins(即原来的Hudson)。既然组织有统一规划，那我自然积极支持。但首先要做的就是评估Jenkins是否能满足我们的需求，...</description></item></channel></rss>