Dev with Github Ent.Lesson Learned

Hiroshi Wada10 min talk @ ATP - Jul 9, 2013

Projects and the dev environments

Web app: Ajax, REST, Spring, Puppet, AWS, ...5-6 ppl, 1 yr 3500+ commitsForge (git), Jenkins, JIRA, FishEye, and Crucible

Command line app: plain Java, VMware, ...4 ppl, 4mo1100+ commitsGithub Enterprise, and Jenkins

Our bad agile days

Push commits to master when you like

Add a tag in commit comments to track by JIRAe.g., "YDR-225 New exception in handler"

Pick up commits and create a review request

Big feature - branch and forget

Problem: hard to review code

Pain of using JIRA, Fisheyes and CrucibleIndividual tools are nice - lack of workflow

Heavily depend on manual effortForget to write "YDR-XXX"No force to create a review

We're lazy. This never work.

Problem: commit granularity

One JIRA issue =>One big commit containing all changes?or series of small commits?

Easy to review a series of commite.g. skip a refactoring making lots changes

But series of commits could be "contaminated"

YDR-XRefactoring

YDR-XAdd func

Merge Y and X

YDR-XFix a bug

YDR-YChange XXX

Problem: Merge hell

Problem: Merge hell

Problem: Merge hell

Problem: Cherry pick?

Hard to find which commits to cherry pickWhich commits addressing what issue?Commits could be "contaminated"

Cherry pick often did not workConflict - mostlyNo conflict - Can I trust?

We need to fix it - but w/ little effort

Trunk-based development *No big branch

Branch-by-issueClear isolation of issues

Enterprise GithubSimple workflow by pull request

* paulhammant.com/2013/04/05/what-is-trunk-based-development/

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

3. Create a branch and push commits

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

3. Create a branch and push commits

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

3. Create a branch and push commits

4. Send a pull request to initiate the review

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

3. Create a branch and push commits

4. Send a pull request

Our current workflow

1. Identify an issue small enough to finish in minutes to few days by one person

2. Record it and get the issue number

3. Create a branch and push commits

4. Send a pull request to initiate the review

5. Merge

Who resolve conflicts?

Mostly no conflict thanks to short turn-around

Branch owner resolve conflicts by rebase before sending a pull request

Reviewer can just hit the "merge" button

Reviewer's job Branch owner's job

merge commit w/ conflicts merge commit w/o conflicts

Rewrite the history

Ok to rewrite the history in remote (`push -f`) until sending a pull request - if you work alone

Allow us for working at night/weekend :)

Only adding commits after a pull requestRebase alters commit ids -> bad

commit id = SHA1(parent commit id, content)Commits get unreachable so as comments

i.e., no comment before a pull request

After merging (1/3)

Fix issues (if raised) in the topic branch then merge (pull request) into master again

Mostly happen right after the first mergeNo *new* conflict to solve

After merging (2/3)

If Master diverts largelyMerge master to the topic branch, orCreate a new issue & branch

Do same when master diverts while reviewing (i.e., after a pull request)

After merging (3/3)

Delete the branch after few days

list of merged branches

Tip: Make commit ids the single truth

Puppetize the whole deploymentGet a consistent test env in minutesFull stack, monitoring, ...Not the AWS resources yet

Don't rely on other versioningsInt. tests on CI => test scriptsRelease workflow => scripts

Other Tips

Command line is your best friendEveryday git commands are just ~10

Hipchat !Aggregate all youneed (and not)

Nagios

Github

Nonsense :)

Discussion

autosetuprebase = alwaysNo merge commits within one branch

Show status on consolee.g., github.com/olivierverdier/zsh-git-prompt*MUST* for those switching branches often

git fetch -pRemove tracking branches no longer exist