Pre-commit and post-deploy reviews have been the industry standard for ensuring that code is functioning as intended. But with Git around, are these methods still needed?
Let’s take a step back and look at how they work.
Pre-commit reviews require that code is checked for bugs before it is committed
Our CEO Sid Sijbrandij says pre-commit reviews makes sense because new code is evaluated before it is introduced into the code base. But with distributed version control, he says, you can essentially do the same thing on Git branches. Prior to Git, branches were too pricey to use regularly in version control systems like Subversion.
Post-deploy reviews periodically check for areas of improvement in the code base
Post-deploy reviews are typically done on a periodic basis as a way to check certain areas of the code base and decide if improvements can be made. This method doesn’t make sense, according to Sid, because "The code has already proven itself in production ... so you’re reluctant to make changes to it." Additionally, the idea of occasionally reviewing your code base is not really needed:
"If there's technical debt in there, at least it's not affecting other code," Sid explains. "There's a certain interest you pay on technical debt, and it has to do with how much it spreads the technical debt to your code base. Code that is not doing much, meaning it's being executed but it's not changing much, well at least it's not influencing other code. You're always going to have tech debt, and you're always going to have a limited time during which you can review and fix things. Focus on the code that's active, that's probably the best place to focus."
Git branches are more efficient
Using Git branches to ensure that code is safe to introduce into the code base improves efficiencies when compared to pre-commit and post-deploy reviews, says Sid, who finds the former to be hard to track.
"Pre-commit code reviews were a bit awkward because you didn't have a good way to refer to it. It was in the tool, but you didn't have a SHA or definite way to refer to that version. And it was hard to know what CI it ran against because there wasn't a SHA. So by doing it post-commit, you have it in versions and it's much easier to see what you referred to. But with code review after deploy, the mindset was, 'If it works, you move on.'
"If you change it, there's extra risk; if you don't change it, it's extra tech debt – and you always have to choose between the two."
"You're not going to be as vigilant to technical debt building up and it's harder to request that someone change something that’s working. If you change it, there's extra risk; if you don't change it, it's extra tech debt – and you always have to choose between the two. With pre-deploy code reviews, you don't have to make that choice … [With what we have now], I think pre-commit and post-deploy code reviews are dead, and code should be reviewed on a branch before it's deployed to production."
What do you think: Are pre-commit and post-deploy reviews a thing of the past? Tweet us @GitLab!
Photo by Caspar Camille Rubin on Unsplash
