Continuous Integration, or What doesn’t kill us makes us stronger /cc @ewolff

By Greg Turnquist

Greg L. Turnquist worked on the Spring team for over thirteen years and is a senior staff technical content engineer at Cockroach Labs. He was the lead for Spring Data JPA and Spring Web Services. He wrote Packt's best-selling title, Learning Spring Boot 2.0 2nd Edition, and its 3rd Edition follow-up along many others.

April 30, 2015

I have gotten onboard with using Travis CI for several projects. It is really cool. You can see some badges listed here:

  • Spring Social Ecobee Build Status
  • Issue Aggregator Build Status
  • Drone Aggregator Build Status

(You can go ahead and click the icons to see more)

Having a constant indicator of something passing or failing is incredibly handy. But upon reflection, I remembered having built just such a system over fifteen years ago.

A long time ago, in a cubicle far, far away

Back in the dawn of my career, I wasn’t granted the privilege of coding features. Instead, I wrote tests for other people’s features. This was a time that predated automated testing and developers being on the hook for their own stuff. Instead, test teams were employed to attack the code with a battery of written procedures. To warm me up to the system, I unit tested other people’s stuff. I had cute test cases that would print out the code’s outputs and my own expected outputs. (Why I didn’t make the final link and simply assert those two values being same I’ll never know). But my tactics of having visualize printouts where these two values would appear right next to each other on the console inspired others to do the same. I spotted another tester quickly adopt my technique. First instance of professional flattery I can remember. It goes to show that when you have to do testing all day, you come up with ways to check off the box faster when values match. (Again, no idea why I didn’t let the test compare the values. Newbieness?)

I shared a cubicle with another junior developer. His job was to run handle the CM process. At the time, our application took ten HOURS to build. You heard that right. Thank you ADA. We also used an ancient form of version control. I call it “one dimensional” version control, because there was no such thing as branching off of master. There was a single, monotonic set of version numbers. When people needed to check out a copy of the system, they came to my cube mate to clone the baseline, which was really what people today might call a version snapshot. That’s because copy the entire baseline from a version snapshot and doing a first, clean build, took ten hours. No senior developer’s time was worth it to do that process themselves. (Incidentally, this is the reason features were HUGE and took weeks or months to complete. If it was going to take ten hours to cut a new workspace, might as well cram as much functionality as possible into it, ehh?)

That which you support you may one day take over

The side effect of sharing this cubicle was that i became his backup. So, I learned how to do his job. Perhaps you can see where this is going? I ended up taking over his job. He moved on. Granted, he had graduated from college with a degree in English and truly sought a career as an author. This was just his daytime job. So he took the path of least resistance. I had a different thought process. I strove to speed up everything possible.

One of our processes involved moving up the “stable” version of things. We had a weekly meeting where my manager would review completed features, and essentially give the green light for to move the “master” position of things. FileX.ada would move from version 4 to version 8. FileY.ada would move from version 15 to version 19. You get the idea. Very expensive and subject to MANY errors. I hated this process. So I sought to fix.

My first Continuous Integration system

Being the script junky that I was (still a bit premature for “test-bitten”), I used that spare time of watching ten hour builds spin their wheels to craft some PERL scripts. I knew how the current batch of scripts operated. What if I kicked off the same build process, only automatically at midnight against the “master” snapshot? What if I captured the outputs in a log file? That way, everyday at 10 a.m., I could review the latest build and spot any errors. After a little chat with a sys admin (I was using a SUN box at the time), I crafted my first CRON job.

It took a few iterations of coming in and seeing if my job launched. Translation: I wrote a CRON job and came in the next morning to see if it ran. At all. Failure? Tweak the job and wait until tomorrow. Several days later, I had the job working great. I could peruse the results and alter the format of the output. Now that i was reviewing this daily report, I started to alter its format. There were key things i skimmed through to spot. To make the reading easier, I prefixed them with “!!!!!”. After a few weeks of this fine tuning, I started to filter the report to ONLY look for this tag. Finally, I added the feature that if there were no “!!!!”, then the build was a success.

By the way, this wasn’t running my test suite and verifying the code. I was too green to see that. Instead, this was simply COMPILING the code and seeing if it passed. But once I had this report in place, I crafted some queries to look at who had submitted what today we might call a “pull request”. My scripts would look at the newer versions of the files, create a snapshot copy with those changes, and do the build job. I would see the outcome at 10 a.m. If it passed, my new copy became the new “master” snapshot. If not, I chucked it and instead focused on what broke. I would take this feedback to the relevant parties and let them sort it out.

Manager’s delight

When I presented all of this to my manager, she was delighted! Pretty soon, those weekly integration meeting vanished. I had figured out a way to continuously build the system with the latest changes and upgrade things. I could start the day with running my test suite against a newer version of things. Yee-hah!

The management team extended my time on this project twice. I was clearly kicking butt and taking names in the land of integrating completed features. But I wanted to build the systems myself, not simply maintain what other had done. So the third time they asked for an extension, I turned them down. I moved on to other projects my company was hosting. But I had cut my teeth on what today everyone knows as continuous integration. Picking up skills in CRON jobs, understanding the core mechanics and ramifications of version control and change management, and seeing the benefit of automating the heck out of things had paid me back with dividends throughout my career. Nevertheless, it’s essential to acknowledge potential challenges, including the importance of knowing your rights and making a claim of unfair job loss if ever faced with an unjust professional situation. Have you been fired unjustly in Boston, MA? A wrongful termination lawyer from Sweeney&Merrigan can help!

Seeing tools arise that make it easier and easier to seek higher quality in software warms my heart. Create your repo on GitHub,. Link it up to Travis CI and fiddle with a few settings. Have it deploy automatically to production on Cloud Foundry. Plugin a Chat Channel (gitter). It feels like ten years ago, we were working in the stone ages. I just wonder what things will be like ten years from now.


Submit a Comment

Your email address will not be published. Required fields are marked *