You don't do Continuous Integration!

Today I am going to talk about one misconception made by developers: Continuous Integration is about running automated integration pipelines…

What is Continuous Integration (CI)?

Continuous Integration is a process of integrating changes in the continuous way. What does it mean?

Imagine a team, 6 people — 3 developers and 3 testers. They work on a project with the quarterly releases. They use a “quasi” scrum with 2-3 weeks sprint. Product Owners split stories to fit them into a single sprint. The team is following the Github branching schema: 

• a development branch — where all stories are merged after they are finished, and separate branches for stories (pull requests).
• Every developer works on a their own story. Before they merge a pull request into the development branch they ask other developers for a code review, and tester for testing. They have an automated integration pipeline running on every commit. The pipeline includes linters, tests, and bundling (creating a shippable package).

In their case, the 2-3 weeks sprint leads to the following schema: 

• developer “A” has 6-7 days for implementation,
• developer “B” has one day for code review, 
• developer "A" has one day to apply changes after code review,
• and tester has about 3-7 days for testing. 

Right?

Let’s focus on the following the branch tree:

The pipelines are running for every of the commits That means they are continuously integrate their changes into the codebase, right?

No! The most up-to-date state of the development branch is distributed across 3 different branches (pull requests). It means the pipelines confirmed integration of every pull request separately, and the development branch is sort of “stale”…

Nobody works on the up-to-date version!

So… How do we do Continuous Integration?

Let’s assume this team understood what they are doing wrong. And they want to develop their software in the Continuous Integration way. How the development process must change?

Each developer needs to merge their changes down at least once per day. When they often merge stuff they work on the most up-to-date codebase.

But we can’t skip code reviews and testing!?

Yes, you can’t, and you shouldn’t. Every pull request should be reviewed by other developer. If all feedback has been resolved, sanity check of the feature has been done, and the integration pipeline is green you are good to go...

...and yes, you should merge the pull request before you handover your story to testing.

Why? 

1. Linters passed, tests passed, and the package has been built. The point of automated integration pipelines is about running tests in the automated way. If you still need testers the automation is sort of pointless…
2. Manual testing makes branches stale! The development branch doesn’t contain the changes from your pull request, so that the branch is stale. Your pull request wasn’t merge down within one day, so that the pull request is stale.

What if my pull request broke the codebase?

Well… Your change is blocking others from merging, you must fix it ASAP. But no worries…. Probably your buddies will help you to find the problem, and fix it.

But it brings lots of stress!? In the end it doesn’t. Every incident makes you a better programmer, and creates emotional bound to other team members. You learn to pay more attention during the code review, trying out stuff before you actually merge it. Those situations teach you to care about the others, and show you can trust your team. 

What if i didn’t finish a story on time? 

No worries. It is very hard to finish everything within one day. If the software isn’t shipped to the production yet and your story isn’t 100% finished. It is fine. Ask for the review.

One rule: the pipeline must be green before merging it!

Ideally, you should never merge untested code, because it is really hard to change it later on. I encourage you to do test-driven-development (TDD) while doing Continuous Integration.

If your company ships the software into production, then you might need a feature toggle. The feature toggle is a switch that allows to disable features on the production. 

Sounds hard? Depends on your needs, you can trivialize it to the simple if statement:

if (process.env.NODE_ENV !== 'production') {
  // your unfinished code.
}

You might want to read more on the Martin Fowler’s blog.

What about testers in the modern world

Airbnb and Netflix do not hire them. Their developers write all automated tests. If something is too expensive to automate — they skip it. How they confirm that something is broken? They have Site Reliability Engineers (SREs) that are responsible for the site monitoring. When SREs identify an anomaly in the system they are investigating what change introduced it. Afterwards they decide what to do with it — revert or fix it. 

Monitoring is the new testing

Have in mind: Airbnb runs one of the best software houses in the world. Implementing their processes will be expensive, and hard to mirror into the company you work for.

More information how Airbnb develops their products here:

I guess, your company hires testers already, and doesn’t want to get rid of them. In this case testers can focus on things that are hard to automate — performing manual exploratory tests, and verifying visual elements. 

If you testers are eager to learn coding they can be involved into writing automated tests. How to do it? Every pull request is developed by two people — a tester, and a developer. The developer exposes interfaces (classes, functions, methods), so that the tester can start writing tests.

The result is: the pair programming on steroids.

Disclaimer: the last paragraph is empirical. While working for one of my former employers. Two oh my colleagues and I were writing automated test suites. We were delivering test cases marked as skipped, and developers were fixing them within their pull requests. In result we delivered better quality, no bugs, and we improved communication within the team. Everybody understood what this feature is about, and how the code works.

Summary

If your codebase is modified by small amount of contributors, you might no see many benefits of doing Continuous Integration. When your team grows the processes start to slow you down. You do more code reviews than programming, and afterwards you solve merge conflicts… Lovely… Shipping to production takes ages — all stuff needs to be tested together, and always you need to patch bugs quickly… If you are at this point talk with your team about the transitioning.

If you have any problems or suggestions, please write a comment.

You can contact or follow me on Medium and Twitter.

Source: Futurama