Git Branching for Agile Teams

Size: px

Start display at page:

Download "Git Branching for Agile Teams"

Eunice Potter
6 years ago
Views:

1 Git Branching for Agile Teams

2 Why use Git + agile?

3 Git helps agile teams unleash their potential

4 How? Developer

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 big bang launch TESTING FRONT END BACK END DATABASE

8 Agile: something can get released fairly quickly MVP launch TESTING FRONT END BACK END DATABASE

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 Just a few dependencies... Look familiar?

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 Hmm Yes

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 In Subversion branching & merging is hell

28 In Git branching & merging is easy

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 Dev branches are like an isolation chamber Keep the main line clean

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 master feature/dev-30 feature/dev-45 Experiment on your feature branch

47 Creating a branch master feature/dev-30 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 master feature/dev-30 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! master feature/dev-30 feature/dev-45

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 master integration feature/dev-30 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 v 1.1 v 1.2 master 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 bugfix-dev 32 v 1.2 master 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 Zzzz build queue

80 Balance testing rigor and resource conservation with manually triggered builds on dev branches

81 Triggering CI v 1.2 master Automation feature/dev-30 Developer

82 What about code reviews?

83 With Git, use pull requests to integrate peer review into the workflow

84 Using pull requests 1 Create request via UI or git request-pull 2 Review, revise, rinse & repeat 3 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

KTH Royal Institute of Technology SEMINAR 2-29 March Simone Stefani -

KTH Royal Institute of Technology SEMINAR 2-29 March 2017 Simone Stefani - sstefani@kth.se WHAT IS THIS SEMINAR ABOUT Branching Merging and rebasing Git team workflows Pull requests and forks WHAT IS THIS