CI Saves My Bacon

One production pattern I've found indispensable is Continuous Integration. CI saves my bacon.

Recently I've found continuous delivery used on top of CI is a production pattern that helps me and my teammates produce working software.

Continuous Integration

Continuous integration or CI is

The practice of running tests on a non-developer server every time a developer pushes potential change sets to a shared source code repository

Florian Motlik, CTO of the CI/CD cloud service CodeShip wrote in Quora:

"This has the tremendous advantage of always knowing if all tests work and getting fast feedback. The fast feedback is important so you always know right after you broke the build (introduced changes that made either the compile/build cycle or the tests fail) what you did that failed and how to revert it."

Pushing code to a remote repository which in turn awakens the CI server to grab your new code and run your test suite, enables you to continue working without waiting for the test suite to complete on your local machine. When tests are run every time a developer pushes code, red flags might pop up, but tend to get fixed in short order. That feedback is reassuring.

One observable behavioral pattern is that many developers, including me, fail to consistently run the test-suite before pushing code. This is particularly true as the code base grows larger, the corresponding test suite grows proportionally larger, and the act of running the test suite exceeds a 5 minute threshold. I've worked gigs where running backend unit tests, front-end UI unit tests, and headless browser integration tests, took over 30 minutes to complete.

Yesterday I made a Rails schema migration to change a column name and to subsequently make it non-nullable. I fixed a controller test because I knew the schema update would have caused it to fail. I generally tend to make frequent commits following small changes. I committed and pushed the new code to our GitHub repository and continued working on the subsequent non-nullable migration. A few minutes later, the CI server reported back red-colored cackage (see below).

CodeShip's CI server indicating bobmacneal pushed code with broken tests

Drilling into the failure notification, I was given a handle to four other tests my schema change broke. I fixed the failing tests, committed, and re-pushed.

Test-driven developers, and their purist brethren test-first developers, would protest that if I was doing things right, I wouldn't be pushing code with failing tests. They're right. Sometimes I cut corners. Like many developers, I'm frequently not the perfect craftsman.

Knowing I'm flawed, I like having a safety net so I can continue the uninterrupted flow of my task knowing the CI server has my back.

I prefer the convenience of hosted continuous integration over standalone continuous integration (see a comparison of continuous integration software).

Continuous Deployment

Built on top of continuous integration is CD (continuous delivery or continuous deployment). Continuous delivery is

The practice of releasing the latest version of your code to a production, or production-like environment, every time new code is merged to a designated branch after a successful run through the CI gauntlet.

Once configured, a cloud-based continuous delivery service makes deployment to any environment frictionless. Continuous delivery supports the agile principle of producing working software.

I like CodeShip. CodeShip is a well-executed, visually attractive, easy-to-configure, cloud-hosted service that provides seamless continuous integration and continuous delivery.


REFERENCES

• Comparison of continuous integration software, Wikipedia.
• Tools and Services I Like, Florian Motlik, 29 November 2014.

Asked or Ignored?

Esther Derby enumerates helpful considerations when Hiring for a Collaborative Team.

I particularly like Esther’s advice to

Involve the team in the hiring process.

Many hiring managers in organizations of all sizes and shapes don't conceive of people working in teams, so it simply doesn't occur to them to ask for input from the team when hiring.

As someone working day-to-day on software teams, I appreciate inclusion in team hiring rituals. A team lunch with a potential hire often smokes out valuable intrapersonal impressions.

Most people would rather be asked than ignored.

Sadly, I've also worked on teams where the morale is so low that team members have a "whatever" attitude vis-à-vis adding new members to the team.

Still, I suspect most would rather be solicited for input.

I value behavior over technology.

A teammate's sense of humor, and professional modesty, is more an indicator of collaborative success than outstanding programming chops.