Skip to content

Push to production three times faster with the right git workflow

Aurore Malherbes5 min read

On the project I work, we needed to deploy in production several times a day, for business purposes, but the deployments took one and half hours. Indeed, we are several teams working along with the Scrum methodology, so our product owners are validating all our work. Thus we spent two thirds of our time to identify and isolate what has actually been validated and is ready to go in production.

We created a new git workflow, inspired by the article A successful Git branching model, and adapted to the Scrum methodology. It helped us to organise our deployment process and to reduce our deployment time to 30 minutes.

macro-workflow
Our workflow is composed by 3 main branches :

The Git journey of a simple feature

Let’s assume Alice and Bob develop an e-commerce website and she needs to register the shipping address of her customers. This feature could be splitting into 3 user-stories : adding a shipping address, editing it and removing it. All the three tickets are in the Sprint Backlog.

She starts with the first user story, adding an address. The corresponding ticket is now in the Doing Column.

git checkout develop && git pull origin/develop
// She creates a new feature branch and a new user story one
git checkout -b feature/shipping-address
git checkout -b add-address
// She codes and commits

git-start

In the meantime, Bob wants to help Alice and starts coding the address deletion.

// He pulls the last version of the shared branch
git checkout feature/shipping-address
git pull origin/feature/shipping-address
// He creates a new branch for the user story
git checkout -b delete-address
// He codes and commits

several-feature-branch
Alice finally finishes her feature locally, she puts the ticket into Code Review.

// She pushes her code to the staging branch
git push origin add-address
// She opens a pull request with the staging environment
git request-pull staging add-address

Once Bob has reviewed her code, she can merge her branch into staging. The ticket is now in the Validation column, waiting for the Product Owner validation.

// She gets the last version of the staging branch
git checkout staging && git pull origin/staging
git merge add-address && git push origin staging
// She builds the validation environment 
// and asks the product owner to validate

push-to-staging

The product owner has validated Alice’s work, the ticket finally in the Done column. She merge her work into the feature branch and starts another user story.

// She pulls the last version of the feature branch
git checkout feature/shipping-address 
git pull origin feature/shipping-address
git merge add-address && git push origin feature/shipping-address

When the whole feature has been validated by the client, Alice merges the feature branch into develop, as it’s ready to go into production.

// She gets the last version of the develop branch
git checkout develop && git pull origin/develop
git merge feature/shipping-address && git push origin develop

push-to-develop

At the end of the day, when they want to deploy into production, Bob merges develop into release and launches the deployment without any concern. Indeed he knows that all the code on develop is correct. He tags the commit of the release to get the history of each version.

// He gets the last version of the develop and release branches
git checkout develop && git pull origin/develop
git checkout release && git pull origin/release
git merge develop && git tag 2.1 
git push origin release --tags

push-to-production

The four rules of this workflow

This workflow can seem to be heavy but after few days you become use to it.
Nevertheless, you have to remember four rules: