年后buildc开始逐渐在产品线的项目里应用了，随之而来的是大家反馈的各种意见和bug。尤其是bug，我都会很认真地应对，也会及时发布相应的版本修复这些bug。buildc 0.1.4版本就是一个bugfix版本，其修复的bug源于今天上午的一次持续集成的失败。 上午收到Jenkins发送的一个"build failed"的mail，一个安装包项目的CI job执行失败了，于是到Jenkins web页面上检查错误原因。这个Job会在两个slave node上执行集成，一个在x86 linux上，一个在x86 solaris上。这次失败是因为x86 linux上的一个配置问题导致的，页面显示x86 solaris那个节点的集成是成功的。我无意间查看了x86 solaris节点集成过程的命令行输出，发现如下内容： ...
在"也谈C应用安装包制作与部署“一文中，我提到了为每一个源码工程建立单独的安装包制作工程(setup project)的想法，这两天我就一直在折腾这件事儿^_^。 最初我并没有想去搞一个通用的安装包制作工具，只是为一个现有的源码工程建立了一个试验性质的安装包工程，并实现了其构建脚本(build.py)。但之后考虑到各个项目都要建立一个对应的安装包工程，安装包工程的构建脚本build.py势必会沦落成被copy来copy去的下场，这显然不是一个很好的解决问题的办法。那是否需要再单独设计和实现一个安装包制作工具呢？工具多了，大家用起来肯定会很烦，不能自找没趣^_^。要知道为程序员编写工具可是一件很困难、很头疼，需要你很谨慎的事情。现在我们已经有了源码工程构建工具buildc，我前几天还为buildc添加了安装脚本，并用之改造了一个真实的工程，并给大家做了讲解，可以说大家对buildc算是接受了。 ...
buildc在发布0.1.0版时并没有做好安装脚本，当时的建议是直接下载0.1.0的源码包或svn export/checkout源码包，并手工将buildc目录位置加入到用户的PATH环境变量中。近期buildc计划正式投入到项目中使用，为了方便大家安装以及以后的统一升级维护，我花了些时间给buildc加上了setup脚本。 Python有标准的程序分发方案，不过我对这些了解不多。buildc本身很简单，我觉得没有必要把安装做得很复杂，所以就自己动手编写了一个setup.py，不到100行，用于安装buildc。 Python的标准安装脚本也叫setup.py，我这里也借鉴了这个名字。有了setup.py，buildc的安装就简单多了： * 下载buildc Release包(当前最新是buildc-0.1.1) * 解压发布包，在发布包路径下，执行setup.py install [–prefix=YOUR_INSTALL_PATH] ...
这几年我一直从事C语言项目的开发。这些项目的规模都不算小，少则十几万代码，多则几十万行代码，至少也都算得上是中型项目吧。项目构建工具使用的是传统的Make工具，构建脚本都是自行编写的，构建时直接在顶层目录下敲入make即可。 这种传统的构建方式其实是很耗时费力的。比如执行make之前你需要根据项目代码的实际路径重新设定一些环境变量或修改Makefile中的某些标识路径的变量；你还要将项目依赖的各种内部公共库、第三方开源库悉数找到，并安装在指定目录下，修改Makefile中这些第三方库的路径配置。只有做完这些后，你才能顺利地执行Make。以后每当你更换一个环境，你就要将上面的步骤重复执行一遍。有的项目第三方依赖较多，要完整地搭建一个项目构建环境所耗费的时间也是很惊人的，特别是对一些不熟悉项目构建的新人更是如此。另外随着产品被要求具备在多个平台上运行的能力，你的构建脚本还要支持在多个平台上的构建，你要为项目所依赖的第三方库准备多个平台的版本；当某个依赖库版本进行了升级，你还要手工在多个环境下进行更新。 ...
多数公司不会仅有一个项目，当你为一个项目引入持续集成实践后，其他项目就会接踵而来。这时你会重新考量BuildBot，考虑如何让BuildBot可以服务于多个项目。 如果你有足够的主机资源和人力资源，那为每个项目单独搭建一套CI环境是再好不过的了，每个项目都有专人维护CI环境，各个项目的配置互不干扰。不过对于一些公司来说，这显然有些浪费，BuildBot Master的资源消耗是不大的，我们完全可以使用一套BuildBot Master来服务于多个项目，至少BuildBot是可以支持这样做的。 ...
在“使用BuildBot搭建持续集成环境”一文中我曾经说到：公司使用的mail服务器只支持SSL连接，而BuildBot似乎对SSL连接的支持有些问题，导致构建结果mail无法发送“。BuildBot实际上使用的是Twisted的mail库来发送邮件的，我下载了Twisted的一些mail发送的例子程序，并使用我的公司mail账户配置，但依旧发送失败。看来这个问题与Twisted的实现有关了。 这个问题已经折腾我许久了，难道非得让我去debug Twisted库？还好，今天我想到了另外一种方法：使用stunnel。原理是这样的：通过stunnel将非SSL连接转换为到公司mail服务器的SSL连接，通过stunnel建立的这条转化通道，mail发送的问题就应该可以解决了。想法归想法，实际上能否达到我的目标，还得通过试验验证。 首先我们需要在BuildBot的master服务器上安装stunnel。 ...
部门的持续集成一直做的不太好，我们开发部这边甚至一直没能做起来，这其中有各种原因：工具、意识、执行力、沟通等等。将持续集成引入到我们的开发过程中也一直是我的一个目标。去年末启动的一个项目让我感到时机变得成熟了。 新项目的代码是完全重写的，这样的机会甚是难得。因为大多数情况下大家都是在维护现有系统：做些添添补补、修正Bug以及优化之类的事情。项目初期，我特别向大家强调了要严格遵守统一代码风格并将astyle代码格式化工具介绍给大家，手把手地教大家如何利用类似LCUT这样的单元测试框架编写单元测试，讲解什么是Mock测试。前些时间我又将代码风格检查 脚本加入到工程的构建过程中，并将代码风格检查作为最终构建目标的关键依赖，强制大家编写出统一风格的代码。 ...
本文翻译自"The Boy Scout Rule"，来自于《程序员应该知道的97件事》一书中的某个章节。 童子军有一条规则：“永远保持离开时的露营地比你发现它时更整洁”。如果你在地面上发现了脏东西，那么无论是否是你留下的，你都要将它清理干净。你有意地为下一组露营者改善环境。（实际上，由童子军之父罗伯特·斯蒂芬森·史密斯·贝登堡编写的原版规则是这样的：“尝试让这个世界在你离开时比你发现它时变得更美好。”） ...
代码风格（style）一直是一个见仁见智的问题，但是对于一个团队而言，如果能在代码风格上达成一致，显然无论对团队还是对个人来讲都是大有裨益的。 ...
近期产品线研发体系正式将Review Board这款优秀的基于Web的代码评审开源工具引入到开发过程中，作为产品线内各项目组进行代码评审的辅助工具。我对Review Board近两年多的关注总算没有白费，算是有了一个还算不错的结果。不过Review Board的正式使用并不代表一种结束，反而恰恰是一个新的开始。我们下一步要关注的是如何用好Review Board，让它真真正正地为改善产品质量和开发效率出力。 ...