RELEASE CYCLE - starts with cutting/closing feature, release, hotfix branches

gistfile1.txt

(See notes at bottom of this guide)


______________  STEP 1 OF THE release CYCLE _________________
_____________________( FEATURE BRANCH )_______________________

1.) Pull (update) develop/master first.

    Ex.
     git checkout develop
     git pull --rebase origin develop
     
     git checkout master
     git pull --rebase origin master
     
   
2.) Checkout to the FEATURE branch --> Always check which SDK branch you're on. 
  Ex.
    git checkout feature/tags-index
    
  * Use git flow to "finish" the feature branch when you're done.
    
    git flow feature finish tags-index
    

3.) Commit Message appears...(which is auto populated)
     Use :q to exit VIM.
    
    
4.) If there are conflicts (like merge ones)...fix them, then run --> git flow feature finish tags-index 
    
    This merges all commits from your feature branch onto develop.
    (which was set on 'git flow init' - sets up the repo to use git flow - 
    you can do this even afterwards if it wasn't set by mistake)
    
5.) Now git PUSH origin develop to the develop after.

     
_____________________  STEP 2 OF THE RELEASE CYCLE ______________________
_________________________ ( RELEASE BRANCH ) _____________________________

6.) Now that the feature is on develop, we can "cut" a release branch after 
    we see if there are new bugs. 
     
     git flow release start 20141106
     
     - Git will automatically go to the new release branch based off of develop.
    
 After making all fixes on the RELEASE BRANCH 
  Deploy changes to staging...

    gulp clean
    gulp build -e staging
    gulp deploy -e staging
    
    ** QA - After all the changes are made again and 
      committed/rebased/pushed by everyone.
    
   
7.) Then pull everything branches + SDK

    Then BUMP VERSION FOR BOXXSPRING AND SDK!!!!! (This helps to revert in case of issues)
    THEN...deploy to staging...
    
    gulp clean
    gulp build -e staging
    gulp deploy -e staging
    

8.) Staging => Then QA
    - Bugs will be filed
    
    - All bug fixes are done ON the release branch and then 
      deployed on the staging branch to be QA'd.
    
9.)  git co develop   ('co' is the alias for 'checkout')
     git pull --rebase origin develop
     
     git co master
     git pull --rebase origin master


10.) Once all bugs are fixed...
     Close the release branch - which merges the release branch into master and develop.
    
     Ex.
     git flow release finish 20141106
    
11.) Commit message appears again -> :q out of it.

12.) Another 'tag' message will appear - hit 'i' to insert the date of the 
     release branch as the tag, then hit 'ESC'
     
     Then :wq
  
13.) Do these steps AGAIN....b/c now new updates are in there....
     git co develop
     git push origin develop
     
     git co master
     git push origin master
     
     ****** SDK UPDATE TOO *****
     git co develop (SDK branch) --> Or whatever SDK branch was matched up to your branch
     git pull --rebase origin develop
     
14.) gulp clean
     gulp build -e staging
     gulp deploy -e staging (from master branch)
     
     THEN IF ALL IS WELL... deploy to production....
     
     gulp clean
     gulp build -e production
     gulp deploy -e production (from master branch)
     
     

15.) Most important QA...with bug fixes --> 



____________________  STEP 3 OF THE RELEASE CYCLE ___________________
_________________________ HOT FIX BRANCH _____________________________
****  This is for fixes that are when your updates are on master -> 
      so it merges to develop AND master ******

17.) Bug fixes at this point are "hot fixes" and go on a "hot fix" branch.
    
18.) git flow hotfix start 20151107

19.) Repeat same steps as for release branch...
    pull develop/master
    
    rake deploy:staging
    
     ** After all the changes are made again and committed/rebased/pushed by 
     everyone...you ...
    
    Then deploy to staging...
    rake deploy:staging
     
    Staging => Then QA
    Bugs will be filed
    
    ** All bug fixes are done on the release branch and then deployed 
       on the staging branch to be QA'd.
     
     git checkout develop
     git pull --rebase origin develop
     
     git checkout master
     git pull --rebase origin master
     
     ****** SDK UPDATE TOO *****
     git checkout develop (SDK branch)
     git pull --rebase origin develop
     
     Once all bugs are fixed...
     Close the hotfix branch - which merges the hotfix branch into master & develop.
    
     git flow hotfix finish 20141106
     
     Commit message appears again -> :q out of it.
     
     Another 'tag' message will appear 
     - hit 'i' to insert the date of the release branch as the tag, 
     - then hit 'ESC'
     - then :wq
     
     **  Do these steps AGAIN....b/c now new updates are in there....

     git checkout develop
     git push origin develop
     
     git checkout master
     git push origin master
     *** SDK update too ***
     

20.) NOW you're back on MASTER 
     - deploy to staging again...for FINAL QA

21.) If all is good...
     rake deploy:production...(and also again to staging, so the latest is on there)


  __________________________________________________________________
  For BEDROCKET ADMINISTRATION & ANGULARJS SDK

________ TIPS:  READ ME  _________
** RENAMING BRANCHES --> Do not "finish" any git flow branches if you just need to 'rename' it or 'create' another one b/c it will merge into master.

if (you didn't push - it's ok then you can delete and then fetch the branches again) {
  git branch -D <branch_name>
} else { 
  fix with hotfix/release
}


** If you had MERGE conflicts - it won't delete the branch afterwards even if it closed 
    - so after resolving merge conflicts you have to finish the branch again.
      git flow release finish 20150206 --> AGAIN to delete the branch!


_____  TO KEEP UPDATED on feature branches with MAIN/DEVELOP branch _____
We can go about this 2 ways:
a) Continually rebase develop/master (whichever you need) from your feature/release branch
b) Create small incremental feature branches that would add small sets of a 
   feature without breaking the feature or other functionality

 We can do both of these depending on the feature, for example 
 a feature that cannot be built incrementally would just need to be continually rebased.