Watch Discussion Lead Sean McGivern demonstrate our typical code review process.
Whatever your team’s workflow, we expect you face immense pressure to quickly ship new features. In our 2016 Developer Survey, 81 percent of developers admit to releasing code before it’s ready, citing the pressure of tight or unrealistic deadlines as the reason they release prematurely. To combat this pressure, engineering teams need a process they can repeat every time, so there are no steps skipped during a time crunch. Our code review tools were built with the aim of enhancing your review process, taking you from idea to production while setting new personal records for code delivery speed and quality.
Demo
Typical flow
Excellent code depends on rigorous review. At GitLab, every change is reviewed using this flow:
- A developer makes a change in their feature branch and tests it. When they’re happy they push, and make a merge request.
- The developer assigns the merge request to a reviewer, who looks at it and makes line and design level comments as appropriate. When the reviewer is finished, they assign it back to the author.
- The author addresses the comments. This stage can go around for a while, but once both are happy, one assigns to a final reviewer who can merge.
- The final reviewer follows the same process again. The author again addresses any comments, either by changing the code or by responding with their own comments.
- Once the final reviewer is happy and the build is green, they will merge.
To find out more about the importance of code quality, considerations for teams of different sizes and stages, and details on how we develop at GitLab while using GitLab, watch our webcast, "Code Review: A Business Imperative" on demand.
Interested in GitLab Enterprise Edition? Check out the features exclusive to
EE.
