<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Continuous Integration on ilikeorangutans</title><link>https://kuelzer.ca/tags/continuous-integration/</link><description>Recent content in Continuous Integration on ilikeorangutans</description><generator>Hugo</generator><language>en</language><copyright>© 2026 Jakob Külzer</copyright><lastBuildDate>Sun, 12 Apr 2026 14:27:24 -0400</lastBuildDate><atom:link href="https://kuelzer.ca/tags/continuous-integration/index.xml" rel="self" type="application/rss+xml"/><item><title>The Case for Continuous Integration</title><link>https://kuelzer.ca/posts/2013/06/01/the-case-for-continuous-integration/</link><pubDate>Sat, 01 Jun 2013 13:59:40 -0400</pubDate><guid>https://kuelzer.ca/posts/2013/06/01/the-case-for-continuous-integration/</guid><description>&lt;p&gt;In my career as a software developer, I&amp;rsquo;ve come to appreciate the principles of Continuous Integration (CI). It forces you to do the hard things early and often and thus helps you reduce risk during development. It forces you to write tests, and be responsible about what you check in. All in all, good qualities and something that every development team should aspire to. Or so I thought. Reality is different, and so far almost every development team I have interacted with is deadly afraid of doing CI. So much, that there&amp;rsquo;s been near-mutinies because CI and what it means for team, causes so many problems. This is something that puzzles me, and I realize it might be because the teams in question don&amp;rsquo;t fully understand what CI is or only realize a subset of what it means. This is my attempt to demystify and explain CI.&lt;/p&gt;</description></item></channel></rss>