Commit 1b66e80b authored by Rebecca Dodd's avatar Rebecca Dodd 🌴

Copy edits

parent 7eda638f
---
title: "Pre-commit and post-deploy code reviews are dead"
author: Aricka Flowers
author_gitlab: atflowers
author_twitter: arickaflowers
categories: engineering
image_title: '/images/blogimages/pre-commit.jpg'
description: "In a world with git, pre-commit and post-deploy code reviews are relics that can be eliminated from your workflow"
description: "In a world with Git, pre-commit and post-deploy code reviews are relics that can be eliminated from your workflow."
tags: code review, git, workflow
ee_cta: false
twitter_text: "Find out why @GitLab CEO @systes says pre-commit and post-deploy code reviews are dead."
twitter_text: "Find out why @GitLab CEO @sytses says pre-commit and post-deploy code reviews are dead"
postType: content marketing
---
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?
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](/company/team/#sytses) says the step 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](https://docs.gitlab.com/ee/workflow/gitlab_flow.html). 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:
<%= partial "includes/blog/content-newsletter-cta", locals: { variant: "a" } %>
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. GitLab CEO Sid Sijbrandij says the step makes sense because new code is evaluated before it is introduced into the code base. But with distributed version control, he said, 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 SVN.
"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."
Post-deploy reviews are typically done on a periodic basis as a way to check certain areas of the code base and determine whether 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, he added, the idea of occasionally reviewing your code base is not really needed.
### Git branches are more efficient
"If there's technical debt in there, at least it's not affecting other code," Sid explained. "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."
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.'
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, said Sid, who finds the former to be hard to track.
> "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."
"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 an SHA or definite way to refer to that version. And it was hard to know what CI it ran against because there wasn't an 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.' You're not gonna 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."
"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 with your thoughts.
What do you think: Are pre-commit and post-deploy reviews a thing of the past? Tweet us @GitLab!
{: .alert .alert-gitlab-purple.text-center}
[Cover image](https://unsplash.com/photos/Tjbk79TARiE by [Sai Kiran Anagani](https://unsplash.com/@_imkiran)
{: .note}
\ No newline at end of file
[Photo](https://unsplash.com/photos/Tjbk79TARiE) by [Sai Kiran Anagani](https://unsplash.com/@_imkiran) on Unsplash
{: .note}
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment