Ce diaporama a bien été signalé.
Nous utilisons votre profil LinkedIn et vos données d’activité pour vous proposer des publicités personnalisées et pertinentes. Vous pouvez changer vos préférences de publicités à tout moment.

Git Branching for Agile Teams

Git helps agile teams unleash their potential.
https://www.atlassian.com/

  • Identifiez-vous pour voir les commentaires

Git Branching for Agile Teams

  1. Git Branching for Agile Teams
  2. Why use Git + agile?
  3. Git helps agile teams unleash their potential
  4. Developer How?
  5. First, let’s review two pillars of agile
  6. 1 Build in narrow vertical slices
  7. Waterfall: can’t release anything until everything is ready to release DATABASE BACK END FRONT END TESTING “big bang” launch
  8. DATABASE BACK END FRONT END TESTING MVP launch Agile: something can get released fairly quickly
  9. Modularity for the win!
  10. Or to put it another way… Potentially shippable, even without this piece I have a roof!
  11. The modular house may not have all its components, but it’ll be move-in ready first
  12. Modularity enables teams to have something testable —and potentially shippable— much sooner
  13. 2 Make releases a non-event
  14. A big bang style release (everything at once) means dependencies up the wazoo
  15. Look familiar? Just a few dependencies...
  16. Do you hold everything in a local workspace until the entire user story is implemented?
  17. Nope
  18. That would mean an important practice for agile teams wasn’t followed: continuous integration
  19. Continuous integration, noun: Testing changes against the existing code base and in-progress changes from the team throughout the development cycle.
  20. Sure CI is important, but…
  21. Will frequent, incremental changes to the repo introduce more risk?
  22. YesHmm
  23. But only if all those changes are piled on the primary code line
  24. The idea is to push changes to the repo without de-stabilizing the primary code line
  25. That’s where Git comes in
  26. Tell me more! Developer
  27. branching & merging is hell In Subversion
  28. branching & merging is easy In Git
  29. It’s all in the way data and histories are tracked
  30. Git stores data as a series of snapshots (rather than changesets)
  31. If SVN is a hand-drawn map, Git comes with built-in GPS
  32. Git uses triangulation to figure out what the merged version should look like on its own
  33. But enough about the technical underpinnings
  34. Git enables a dev to fully exploit the power of branch-and-merge workflows
  35. Why use a branching workflow?
  36. Branching protects the main code line, and supports an individual developer’s workflow
  37. Atlassian devs create a branch for each issue they work on
  38. And it’s helping us deliver faster than ever before
  39. Keep the main line clean Dev branches are like an isolation chamber
  40. No half-baked code on the main line
  41. There are other benefits, too…
  42. Clarity & traceability If it’s been merged up, it’s ready to release. Easy!
  43. The branch-per-issue model is the synthesis of: “build in narrow vertical slices” + “make releases a non-event”
  44. Branch-per-Issue Workflow for SaaS teams
  45. The basic idea: a master code line with several development branches running alongside it
  46. A branch for every issue Keep master green feature/DEV-30 feature/DEV-45 master Experiment on your feature branch
  47. Creating a branch feature/DEV-30 master Check your CI system to make sure you’re creating your dev branch from a clean commit!
  48. Break all the tests on a branch without disrupting teammates
  49. Merge up when work is done feature/DEV-30 master With implementation complete, and CI passing, merge upstream! On some teams, the product owner acts as a “gatekeeper,” selecting branches for merge based on what they want to release.
  50. The beauty of this branching model:
  51. Code changes that are breaking tests on a dev branch aren’t affecting master or impeding the team’s ability to release from master
  52. It’s easy to control what is released to users and what is held back
  53. Now, a variation on that model:
  54. Using an Integration Branch
  55. The basic idea: a shared integration branch running between feature branches and the master branch
  56. But what if teammates merge incompatible changes upstream?
  57. Surprise! feature/DEV-30 feature/DEV-45 master
  58. Now master is broken
  59. And that’s sad
  60. Some teams avoid this by using a shared branch to integrate changes during development
  61. Builds fail on the integration branch, not the release branch
  62. Using an integration branch integration feature/DEV-30 master feature/DEV-45
  63. Merge all clean CI runs on the dev branch to the integration branch and run CI
  64. If changes don’t play well with changes made by teammates, go back and fix the branch
  65. When implementation is done and CI on the integration branch is clean, it’s ready to merge to master
  66. Branch-per-Issue Workflow for installed app teams
  67. Multiple-version support master v 1.2 v 1.1 feature/DEV-30
  68. In this model, master acts as an “alpha” branch
  69. Devs make branches off of master for new development
  70. And run CI, maybe use an integration branch, etc.
  71. Then a stable version branch is cut just before release time
  72. Create a bugfix branch off the release branch and fix the problem there
  73. Multiple-version support master v 1.2 bugfix-DEV 32 feature/DEV-30
  74. Then cascade the fix back to the stable version branch and master
  75. Incorporating Agile Best Practices
  76. Continuous Integration & Peer Review
  77. Running CI on dev branches All active branches are under test
  78. Yes: all active branches
  79. But that can clog the build queue Zzzz
  80. Balance testing rigor and resource conservation with manually triggered builds on dev branches
  81. Triggering CI master v 1.2 feature/DEV-30 Developer Automation
  82. What about code reviews?
  83. With Git, use pull requests to integrate peer review into the workflow
  84. Using pull requests 1 2 3 Create request via UI or git request-pull Review, revise, rinse & repeat Approve & merge
  85. Additional Considerations
  86. Is “pure” continuous integration in a branch-per-issue model possible?
  87. Nope
  88. For a CI purist, that matters ! For a CI pragmatist, it doesn’t
  89. But shared integration branches and pulling updates from master down to dev branches comes close to “pure”
  90. And this workflow is so powerful for agile teams, it’s wise to be practical
  91. Here’s to easy releases, happy developers, and getting Git right!
  92. More info 1 http://atlassian.com/git 2 @Atlassian

×