Dev with github enterprise

1,307 views
1,119 views

Published on

10 min talk at ATP

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

  • Be the first to like this

No Downloads
Views
Total views
1,307
On SlideShare
0
From Embeds
0
Number of Embeds
6
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Dev with github enterprise

  1. 1. Dev with Github Ent. Lesson Learned Hiroshi Wada 10 min talk @ ATP - Jul 9, 2013
  2. 2. Projects and the dev environments Web app: Ajax, REST, Spring, Puppet, AWS, ... 5-6 ppl, 1 yr 3500+ commits Forge (git), Jenkins, JIRA, FishEye, and Crucible Command line app: plain Java, VMware, ... 4 ppl, 4mo 1100+ commits Github Enterprise, and Jenkins
  3. 3. Our bad agile days Push commits to master when you like Add a tag in commit comments to track by JIRA e.g., "YDR-225 New exception in handler" Pick up commits and create a review request Big feature - branch and forget
  4. 4. Problem: hard to review code Pain of using JIRA, Fisheyes and Crucible Individual tools are nice - lack of workflow Heavily depend on manual effort Forget to write "YDR-XXX" No force to create a review We're lazy. This never work.
  5. 5. Problem: commit granularity One JIRA issue => One big commit containing all changes? or series of small commits? Easy to review a series of commit e.g. skip a refactoring making lots changes But series of commits could be "contaminated" YDR-X Refactoring YDR-X Add func Merge Y and X YDR-X Fix a bug YDR-Y Change XXX
  6. 6. Problem: Merge hell
  7. 7. Problem: Merge hell
  8. 8. Problem: Merge hell
  9. 9. Problem: Cherry pick? Hard to find which commits to cherry pick Which commits addressing what issue? Commits could be "contaminated" Cherry pick often did not work Conflict - mostly No conflict - Can I trust?
  10. 10. We need to fix it - but w/ little effort Trunk-based development * No big branch Branch-by-issue Clear isolation of issues Enterprise Github Simple workflow by pull request * paulhammant.com/2013/04/05/what-is-trunk-based-development/
  11. 11. 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
  12. 12. 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
  13. 13. 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
  14. 14. 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
  15. 15. 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
  16. 16. 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
  17. 17. 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
  18. 18. 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
  19. 19. 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 request Rebase 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
  20. 20. 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 merge No *new* conflict to solve
  21. 21. After merging (2/3) If Master diverts largely Merge master to the topic branch, or Create a new issue & branch Do same when master diverts while reviewing (i.e., after a pull request)
  22. 22. After merging (3/3) Delete the branch after few days list of merged branches
  23. 23. Tip: Make commit ids the single truth Puppetize the whole deployment Get a consistent test env in minutes Full stack, monitoring, ... Not the AWS resources yet Don't rely on other versionings Int. tests on CI => test scripts Release workflow => scripts
  24. 24. Other Tips Command line is your best friend Everyday git commands are just ~10 Hipchat ! Aggregate all you need (and not) Nagios Github Nonsense :) Discussion
  25. 25. autosetuprebase = always No merge commits within one branch Show status on console e.g., github.com/olivierverdier/zsh-git-prompt *MUST* for those switching branches often git fetch -p Remove tracking branches no longer exist

×