Continuous Integration and Code Reviews

rbseaver profile image Rob Seaver Updated on ・2 min read

I'm working on moving my team to a continuous integration process. Right now, we do work in a feature branch and once the feature is complete, we submit it a pull request for code review/merging. However, I'm not a fan of introducing large features all at once, which requires someone to spend part of their day reviewing dozens (and sometimes 100+) changes in a single code review session. Small commits are ideal and make it much easier to identify problematic code, and it obviously lends itself to more frequent releases. I suspect I'm preaching to the choir here, so I'll avoid extolling the virtues of CI/CD.

Most of my team is on board, but one of our team members is a bit resistant to this change. I am completely empathetic to his position, however. His concern is that when we introduce many small commits over time, it becomes difficult to review the feature in its entirety to make sure the code is consistent and works with all of the previous pieces of code that were introduced. My position is that automated testing directly addresses his concern. It will become apparent pretty quickly if new code is incompatible with previous code, based on the automated test results. Bite-sized commits are much easier for a reviewer to digest, and allow the reviewer to focus on style, readability, etc..., instead of whether the code works properly.

Has anyone else transitioned to continuous integration and faced resistance along the way? How have you addressed it with your team? Thanks in advance for any input!

Please forgive any grammatical errors or lack of clarity. It is Friday afternoon and I'm struggling to put my thoughts together after a long week (and it's hard to want to think about work after you've gotten home) :)

Posted on by:

rbseaver profile

Rob Seaver


I'm a software engineer working in the intellectual property space. When I'm not at work, I'm at home with the family which includes a wife, son, two cats, guitars, and a varying number of banjos.


Editor guide

I was in the position of your team member at some point, we had a discussion and wanted to move our codebase to a monorepo, and I was arguing against this decision. I finally accepted to try it with the idea that if it didn't work we could still go back to the previous way. And 1 year later we still have the monorepo and I'm happy with it, so I got convinced by example. This is one way you can convince your teammate :).

About his concerns, there are several stages of CI and levels of testing. You can have feature branches where you push regularly small commits so t hey are easy to review, and have the ci run build jobs and unit test jobs on each commit. Then have integration tests jobs that you run manually when the feature is ready, either on the feature branch or on master branch after the feature is merged.

CI jobs shall be small and fast so they are not a pain to run and can be run repeatedly, this becomes more and more difficult when the codebase grows though. This is where nightly jobs are interesting also, run long tests on the whole codebase.


Awesome tips and advice! Thank you, this really gives me some good ideas!