40 square's git workflow

3,917 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,917
On SlideShare
0
From Embeds
0
Number of Embeds
103
Actions
Shares
0
Downloads
42
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • 40 square's git workflow

    1. 1. 40 Square’s GIT Workflow Who Am I?Lead developer in 40 square softwareFirst Love: 6 years in Java (omfg what was I thinking)Ex-GF: PHP hobbyist turned full time engineerWife: Node.JS, and Javascript in generalTwitter: @roguejs This will be a warp speed presentation!
    2. 2. Mercurial vs GitWe used fogbugz + kiln initiallyStarted off with feature branchesMerging conflicts took foreverREAL REASON: Bad practicesHIDDEN REASON: Fogbugz is expensive...
    3. 3. Other annoyancesNo dry runsDifficult to do code reviewNo cherry-pickingBad planning and structureBranching is expensive?
    4. 4. Our Deployment Process LDC Dev C1 LDC B1 push hg pull CDCDev repo B Branches CDC Dev - qa C - master
    5. 5. Deployment ProblemsAccidentally merge into master? RED ALERTQA testing on old codeDev: “Is my feature merged yet?”Lead: “Hold on, I’m fixing conflict #13285582309583” live dev1 invalidates previous test dev2
    6. 6. Why Git?Because github is sexyActually, because it’s cheaper than KilnWhy not bitbucket?Because github is sexy, and because I said soActually, because github still is cheaper (repo vs users)Git has more options for branching and merging
    7. 7. Our GoalsHave a staging server that is a clone of live serverAbstract devs from live serverNo more “it’s just one line of code, can I push to livedirectly?”Rapid deployment and lesser merge conflictsBuild better practices
    8. 8. Vincent Driessen Model 40 square styleLong Running Branches: master - live servers staging - last line of defense devel - weekly deploymentsDistributed blessed repo model Blessed repo managed by integrators Each dev gets own fork
    9. 9. Forking Model & PolicyYour own fork is your own responsibilityFeel free to force update your own forkRebase before sending pull requests
    10. 10. Typical Workflow (dev)Dev starts work on an issue in PivotalDetermine what kind of issue: P1- branch off from staging Bugs & Features - branch off from develPull upstream often and rebase on upstreamRebase again before sending pull request
    11. 11. Typical Workflow (dev)git fetch --all (git version 1.7.x)git branch --track up-devel upstream/develgit branch P1-1305 up-develgit fetch upstream develgit checkout up-develgit merge upstream/develgit checkout P1-1305git rebase up-devel
    12. 12. Typical Workflow (integrator)Integrator receives pull requestCreate a new branch in blessed repoPull update into that branchReview codeMerge into staging/devel
    13. 13. Typical Workflow (Integrator)git branch soggie-P1-1305 develgit checkout soggie-P1-1305git pull soggie P1-1305git rebase develgit checkout develgit merge soggie-P1-1305git push origin devel:devel
    14. 14. Overall Workflow LDC Dev C1 LDC git B1 repo push git git pull CDCDev repo integrate repo B git CDC repo Dev C
    15. 15. Timeline ViewBlack line = masterBlue line = stagingGreen line = dev
    16. 16. Devel branch deploymentEvery MONDAY, merge to stagingOnce testing completes, tag and merge to masterIf testing fails, all bug fixes are designated as P1Bug fixes for release candidate is merged into staging master fail staging fix devel
    17. 17. Staging branch deploymentMerge to staging and testOnce QA approves it, merge to master AND develPolicy: Only one commit allowed to dangle master never!!! staging devel
    18. 18. PoliciesDo NOT force update blessed repo I will hunt you down, and kill youAlways rebase before sending pull requestIf P1, branch off staging. Otherwise, branch off develManage pull requests NOWNo dangling commits on staging
    19. 19. BenefitsEstablished workflow = peaceful work environmentPredictable integration & deploymentConflicts = dev responsibility instead of integrator’sCan dick around with own repo without killing blessedrepoNo more unpredictable testing environment
    20. 20. More InformationA successful branching modelhttp://nvie.com/posts/a-successful-git-branching-model/Githttp://git-scm.com/Githubhttp://github.com/Git video tutorialshttp://gitcasts.com/

    ×