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.

Founders as Programmers?

A founder asked

While outsourcing my startup, should I learn programming or just focus on customers and scaling?

Founders don't need to learn programming.

Outsourcing is a good call, but never if the intent is to outsource on the cheap.

Don't skimp on developers if your product is software.

Founders need to find the most talented software producers money can buy. A software producer is steeped in:

• Minimum Viable Product;
• Interaction Design;
• Continuous Integration, and
• Continuous Delivery;

Software developers need cash on the barrelhead. Never insult them with equity propositions. If you do, they'll sniff you out as an amateur.

Founders are on the hook to provide the developers with a clear picture of what the product should be at any given time as the production team iterates to a sustainable business model.

Scaling?

You wish. First things first.

Focus on customer discovery.

Prepare for the realization that your original idea sucked.

• Let the discovery process guide and inform the search for a viable model;
• Don't rely on notions and opinions about customers;
• Humbly and diligently acquire the hard facts about customers and the market.

Founders are detectives. They pursue intel on customer pains & gains. Then they fit an offering to address them. The Business Model Canvas helps organize the detective work.

Pursue reality over wishful thinking.

A founder needs to attract the best software producers, then trust them to deliver the product vision.

The more relentless founders are in pursuing actionable, the more the production team will trust the founder's vision of the offering.


REFERENCES

• Business Model Canvas.
• The Startup Owner's Manual by Steve Blank and Bob Dorf.

Ten Outsourcing Considerations

Software developer testing with JUnit

Ten outsourcing considerations when choosing a software development team:

1. Are they local?
2. Are they recommended by someone you trust?
3. Are they demonstrably adept in DevOps (Continuous integration, Continuous delivery, Product stewardship*)?
4. Are they tech-stack agnostic?
5. Do they have collaboration chops (Pair programming, Pull requests, Distributed version control system)?
6. Are they hip to quality considerations (Interaction design, Test-driven development, Test automation)?
7. Are they a learning organization?
8. Do they have soft skills?
9. Are they product-centric rather than project-centric?
10. Do they feature a high producer (team lead developer, developers) to non-producer ratio (i.e., architects, business analysts, scrum masters, account managers, reporting jockeys)?

^*Product stewardship is an emerging topic for a future post. Subscribe or check back.