My Introduction to Continuous Integration
My introduction to Continuous Integration came in 2002. The first day of my work for a retail company, I walked in & we immediately discussed tasks. Then we estimated them, paired up, sat down and started working. At the desk was one keyboard, one mouse, one monitor, and a KVM switch. I know what you’re thinking, “how quant”.
If you’re not familiar, a KVM switch looks like this…
A KVM switch allowed you to press a button and switch between video and peripherals of one computer and another. It would audibly “click” when you pressed the button. And those green & purple connectors? Those are called PS/2 connectors – what we used before USB, but enough of the modern history lesson…
Under the desk (and I use that term loosely — it was a table) two computers sat. One computer was for development work and one was for integration. This was state of the art Continuous Integration in 2002. Tools like Cruise Control (the grandfather of tools you use today) weren’t available yet.
When we finished a task, we’d run unit tests on the dev machine. If they passed, we’d commit code to the source code control system (CVS at the time). Then we’d switch to our integration machines and kick off a build. The build script was written in ant. It would go to CVS, pull down code from the mainline of the repository, collect dependencies & resources, build the code, run unit tests and if they passed it would run UI-level acceptance tests. During this time, we’d either start looking at the next task or throw a nerf basketball at a nerf hoop. I’m using the words “throw” and “at” rather than “shoot baskets” intentionally here.
Several other development pairs also worked on the same codebase. Many times, if one of them happened to kick off their build before you, they’d suffer failures in tests because of your change, rather than theirs. They may not know whose change broke a build, because there wasn’t a good interface like there is today that would show which commits were new to a particular build. Further, there was nothing but trust and public shaming ensuring everyone followed the process. If people didn’t follow the process, others would likely suffer from their mistakes.
Today we have great continuous integration systems like CircleCI, Bamboo, Jenkins, Travis CI, Team City and others. We no longer require integration machines for each pair or developer. We have great tools for automating testing and they plug into CI systems.
14 years after my first experience with CI, many teams haven’t adopted CI. More and more I find the adoption rate of techniques like these is shallower than I imagined.
So this month I’ll be getting out monthly webinars started again after a brief December hiatus. I’ll be focusing our monthly webinar on CI and how it affects processes and specifically testers. Join me, January 18 at 1pm EST for “Continuous Integration and How it Affects Testing”. Register here to get your own Introduction to Continuous Integration.
I hope to see you on the 18th!