Rancher

玩腻了Jenkins,也来玩玩Drone CI

一般一提起持续集成,很多人都会说“我们也在实施持续集成,有个Jenkins集群”之类的。这里面隐含着两个信息:持续集成与持续集成系统好像是一件事,这个是我个人最不同意的点,后面我会专门写一篇文章来分析持续集成最核心的“秘密”;另外一个信息就是持续集成系统主流就是使用Jenkins,其它的选择不太多。其实选择还真不少,比如,从早期的CruiseControl到TeamCity、Jenkins、Bamboo,以及TW的Go pipeline,再到最近流行的CI服务Travis CI、CodeShip、Circle CI,甚至GitLab 也集成了pipeline的功能。这些工具不少我使用过和研究对比过,有些是收费服务,有些是收费产品,有些是开源项目。最后我在自己产品上选择了相对金钱和精力投入相对较低的Drone CI。 我选择Drone

Team

走捷径的系统思考

这里的走捷径指的是在软件开发过程中,团队为了应对超出他们实际能力的工作量时会采取的方式。往往公司由于业务压力,要求团队做更多的时候,团队的能力所能交付的工作与实际的工作量产生了落差,团队为了能按时交付,只好使用一些秘密武器(比如,复制粘贴,在一个方法里堆代码等等),这样就降低了他们的实际工作量。 用系统思考里的因果环路图来表示,就是下图中红色区域的环路 这是一个平衡回路。因为走捷径确实解决了当下团队工作过载的问题。但是,它还隐藏着另一个增强回路, 如下图 走捷径带来了代码可维护性降低,使得将来的工作量增加了,这就形成了恶性循环,团队将持续通过走捷径来应付工作量的持续增加。这是一个常见的基模:饮鸩止渴。 这个简单的道理其实大家都明白,为什么很多团队还是这样呢?我分析有几个原因:首先这个反馈是延迟的,成本增加不会立刻看到;其次是侥幸心理,比如,觉得将来不会再改这个代码了;第三,