Mike continues, “CI is the practice where developers merge code to the main branch frequently, and automated tools build and test the code after every merge.”
Let’s expand on one of the phrases in that sentence.
“Merge code to the main branch frequently” can mean a number of different things. The easiest way to guarantee frequent merging is to have no long lived branches.
I worked in one company with 6 month release schedules. Every team would have a branch and work exclusively off the team branch until a few weeks before the release. We had a month before release filled with merge issues. It was a nightmare and I was glad to move away from it when I changed companies.
How do you live without long lived branches? How do you enforce that? Can I have a GitHub Action which refuses to allow pushes to branches which are older than a day?
6 years ago Kent Beck suggested “test && commit || revert” . On GitHub, we would have no branches except main. You have to create a branch to create a pull request. If the automated build and test fails on the PR, we drop the branch and you have to start again. Keep those PRs small!
The main branch is the only long lived branch, similar to the “Sacred Timeline” from the Loki series.
Everywhere I’ve worked, the approval process took time. If you don’t get approval on a PR right away, it becomes a long lived branch. Approvals would have to be quick to have no long lived branches.
Modifying the PR means keeping the branch around. We would have to block modifying PRs.
For a programmer working alone she would create a new branch with almost identical code. She would make the changes which reviewers requested and create a new PR. That’s essentially a branch of the code on her computer.
Pair programming would be the only way I know where approvals could be quick enough to be worth it.
One programmer at the desk, she’s developing code. Another programmer can see and he can comment as the code develops. PR approvals are instantaneous. As soon as tests pass, she pushes her change and he approves the PR.
What do you think? Could you work in an environment of pair programming?