Objective:
1. To solve issue of merge conflict of migrations. When deploying if developer has forgot to check in their migrations.
2. To solve Settings.xlsx conflict to remove duplicate entries and over written values.
3. To not block any new release.
4. Solve merge conflict of hot fix if any database changes is there.
High level idea is we will have two main branch
Two Long lived branches 1. Master 2. Develop (staging for us)
PROD
Master which is always what is deployed on production.
Feature Development 1. Develop is the latest the development code (which is verified) 2. For any new feature we need to branch off from develop only. Example : feature-account-fee, feature-auth-system 3. All developers must do git rebase on their local with develop branch regularly, it would ensure that you have the latest code of develop, and if any hotfix or release happened, it would get fetched into your code, Make sure its git rebase not merge (check FAQ1)
4. To make a release of features,
5. Branch off **release-1.1.0 (RC-1.1.0)** from develop. (check FAQ2)
6. Merge all feature branches in that release. Here git merge would be enough as all feature branch would be upto date with develop.
7. Put that release on staging (one env to test the release, all regression and feature testing)
8. All the merge conflict will be solved on release branch (RC-1.1.0)
When QA gives green signal we need to merge RC branch to develop and master
HOT FIX
1. Hotfix would come from master directly.
example : hotfix-fix-prod-bug
2. We Can deploy hotfix to QA test it and merge this with master and develop.
3. Now developer would do git rebase in their feature branch to make the code unto date.
Signals and Practice
1. Anytime production branch can be compared to QA branch to identify which features are in QA and not in production. If there are too many features or changes., it’s a signal that QA is becoming a bottleneck.
2. As a practice keep the changes smaller so that incremental releases are possible. Also it’s easier to do code review and analyse the release impact.
Current Issue
1. When code is merged to staging and any developer is working on any feature, even code is not released and pulls the code he gets the code which is not tested by QA, so it’s better to have a develop branch where the code is tested and which similar to what is deployed on master with hot fix also.
PROS of this branching strategies and git rebase 1. Feature branch has just production + this feature related commits 2. If some other feature got released while this feature is still in development, developer need to rebase with production. Else he won’t be able to merge it to production. 3. Developer is forced to handle how his feature behaves with other newly released features. This is handled at feature branch level itself rather than environment branch. 4. Maintain history in development and master branches only. We can preserve the ReleaseCandidate branches as versions of our software. 5. We can delete all the local feature and fix branches as we don’t need them.
CONS of Git Rebase 1. Rebase is actually difficult to do by developers. 2. It is usually more difficult to solve conflicts. If you have multiple commits in a feature, you probably changed the same code multiple times. If a conflict happens, you’ll have to fix it multiple times. With a merge you’d it just once.
FAQ 1. Why git release on merge on local? Find some blog to understand the difference.
2. Why we are creating a new branch named release-1.1.0?
a. Creating a new branch from develop named release-1.1.0, here we will merge the new features, feature-1, feature-2, here we can test the code in QA, and if everything goes fine, we will merge it with develop and when deployed to master.
b. Advantage of this approach is, while developing the feature-1 and feature-2 if any hot-fix came it would be available in develop, so we can directly merge the feature-1 and feature-2 and resolve conflict there.
And if any development changes are required for those two feature they can change the code and merge it in release, or they can create a new branch directly from release-1.1.0 fix the issue and merge back.
c. Having a separate release branch would help us in releasing a feature if other feature has some bug,
Current scenario: if we merge everything with staging and found out if there is any big blocker everything gets stop, we can’t release the other features too.
Here we can release feature-2, just branch it out from develop test it and merge it to develop (staging).
When feature-1 is ready we can branch it out with develop, say release-1.2.0 and merge feature-1 test and deploy it.
Master Development
Prod-deployment. — 10 June 2020 New feature release - 20 June
Developer 2 features started working on 8th june Daily they make one migration file Dev 1 - 8_june_1.py Dev 2 - 8_june_1.py
Dev 1 - 9_june_1.py Dev 2 - 9_june_1.py . . . . .
Dev 1 - 17_june_1.py Dev 2 - 17_june_1.py
U got bug on prod on 12 June U had to change data base. U created a branch from prod— new branch hotfix-db-change
It got deployed on prod same day. 12 June Now in prod database in migration table there is one entry on this migration.
FOR QA
Now on 20th u have to release it. U created one more branch from development — release-candidate-1.1.0 and merged all feature branches in here. (And solved all the merge conflict) Now QA is going on — for any bug of that feature they can directly cut a branch from release candidate branch and fix issue and merge it to RC
Now RC is complete BY QA.
Development is now merged
Development or Master.
RC+f1 : A,b,c,d, f1-e,
f2: A, b, c, d, 1,2,3
A, b, c, d, 1, 2, 3, e, mc (hot fix was merged to this ), deleted
A,b,c,d, (rebase) e, (solve conflict between e and 1 , rebase continue), (solve conflict between e and 2 , rebase continue) , (solve conflict between e and 3 , rebase continue),
Cons: new history gets changed. You should do rebase locally that has not been pushed to remote. Conflict might be slightly difficult to solve.
Never rebase- master and development.
So it is advised to do the rebase by the developer who had done the commit, 4, 5, 6.
A,b,c,d — staging, hotfix-e e
Feature1 - 1,2,3,4,5,6 Feature2 - f1,f2,f3
Developer- in ur branch u do, rebase, staging, (1,2,3), A,b,c,d, e, (1,2,3,4)
release_branch — A,b,c,d e, feature1 (1,2,3,4,5,6), f1,f2,f3 — TEST this
Rebase is difficult to use.