When a developer writes code for hours without a break, unnoticed mistakes will appear that can ruin the program in the end. Because of this, development without a proper ongoing review process can hardly be imagined.
One of the most useful and efficient ways to organize the review process is to use cross-review. While this review method might be unfamiliar to some people, it is popular among development teams around the world.
Here we’ll explain how this model helps development and why it has become so well-known.
What is it?
To put it simply, cross-review is a technique where all the members of the team check each other’s code before it passes on to testing and then to release. Organizing the review process in this way helps the team speed up their development and helps them communicate with each other more comfortably.
One of the best features of cross-review is that it’s not necessarily conducted only between developers at different levels, like junior and senior, but also between peers. For example, a developer might write a bit of code, but due to tiredness, headache, or a bad mood they could miss out on something important or not consider alternative ways of implementation. In this situation, there’s no need to bother a senior developer. A simple side view from a colleague would be enough. A combination of reviews between peers and tech leads provides the best result, creating a final version of the product with as few bugs as possible.
GitFlow
GitFlow is a branching model that is focused on project release. It was created by Vincent Driessen and has attracted a lot of attention because of its collaborative and scaling capabilities. This review model provides a strong framework for managing product development.
GitFlow consists of several branches in the Git versioning system.
- Master (or Release) — This is the stable, reviewed, tested, and released version of a product, so basically, it is the app itself. There can be only one Master branch, which is shown to the end-user.
- Develop — This branch is a version for inside use. Here all the changes are collected and tested in order to be merged with the Master branch. During the day developers make a lot of changes in the Develop branch, so it can be unstable. That’s why for some products it’s necessary to create another intermediate branch — Staging. This would be a stable version of the app that is shown to the client before release, allowing them to make corrections if needed.
- Feature — A Feature branch is a separate unit created by a developer as they work on a particular part of the code. The number of such branches can be truly enormous, since many developers can work on the codebase simultaneously.
Why is this branching needed? Well, let’s imagine a situation: The client decides to change the color of the “Try again” button in their trivia game from purple to green. A developer creates a Feature branch, where they implement the requested changes. They then review the code, making sure that the new version won’t break anything in the rest of the app, merge this Feature branch with the Develop branch, and when all the changes have been reviewed one more time, the new version appears on the Master branch.
At the very same time, another developer changes the app’s background or the number of answers in another Feature branch. This piece of code goes through the same process of merging and review, so that no code excludes another. All the possible Feature branches — one for each particular change in the code — form the Develop branch of a product, which, in turn, creates a version ready for release.
How the review is organized
A long time ago things worked like this: Developers would work together on the same piece of code at the same time. One person would change it one way, and the second another way. This created conflicts in the code that crashed the program. In this environment, each developer had to shout across the whole office for their colleagues not to touch the same file that they were working on.
With GitFlow everything has changed. Merging and reviewing in this system are organized with the help of pull requests. A pull request is a request from a developer to merge changes into a superior branch (Feature to Develop or Develop to Master).
Now it looks like this: A developer writes 100 lines of code and sends them to the senior developer. They review it, and if everything is okay, the changes are merged in the upper branch. If the code has bugs or there are lines that must be rewritten, the reviewer explains what’s wrong and asks the developer to make the needed fixes. When the corrections are done, another pull request is sent, and if there are no new mistakes and the code works properly, the changes are merged into the Develop or Master branch.
Every team has its own unique way of implementing GitFlow, since it depends on many factors, from the team’s size to the product’s specifications. Nevertheless, if the team sticks to this way of code review, it helps them avoid a lot of misunderstandings and conflicts.
Why use it?
To organize the review process and to bring order to development!
With the help of cross-review and GitFlow, development becomes much more coordinated. Everyone on the team knows what’s happening on the project at the moment, what their tasks are, and what are the deadlines for each one of them.
GitFlow also helps with implementation of other important features:
- Continuous deployment and continuous delivery. These processes are impossible to apply without order and GitFlow helps with ordering development.
- Platform-agnostic products. Cross-review makes the creation of platform-agnostic apps and implementation of containers — abstractions that package code and isolate it from the system — a lot easier. With their help, the apps become easily transferable to other platforms.
- Easy work. This model doesn’t require extra money or extra time. Instead, cross-review optimizes teamwork.
Final thoughts
Development is a complex process that is not immune to mistakes. A proper review process is the best way to minimize the number of mistakes, and GitFlow helps the team accomplish that.
Originally published at https://yellow.systems.
