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.
Our workflow is composed by 3 main branches :
The develop branch can be seen as the Truth : every line of code has been tested and validated by the client.
The staging branch corresponds to the validation environment.
The release branch contains the last version of your website in production.
The feature branches are temporary.
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.
[code]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[/code]
In the meantime, Bob wants to help Alice and starts coding the address deletion.
[code]// 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[/code]