Dev Lifecycle with Git

In this presentation Andrew De Ponte covers a few of the various types of workflows he has experienced through out the years as a developer. He, also discusses what his team currently uses and why.

Transcript

1. DEV LIFECYCLE with Git Tuesday, February 28, 12
2. WHO AM I? • Andrew De Ponte - (a.k.a drewgle) • @cyphactor on GitHub & Twitter • Lead Software Engineer @ RealPractice • Dev’d professionally in C/C++, Python, Ruby, JS, PHP, etc. • Rails/Ruby is my life now! Tuesday, February 28, 12
3. NOT A GIT INTRO curl http://a.com/git/intro Tuesday, February 28, 12
4. OUTLINE • The “Free For All” workflow • “No sense makes sense.” ~ whichcharlie.com? • The “git-flow like” workflow • “You can’t process me with a normal brain” ~ whichcharlie.com? • The “GitHub like” workflow • Bi-Winning Tuesday, February 28, 12
5. “FREE FOR ALL” • What is it? • Generally centralized • Modeled after older SVN based workflows • Everyone pushes to central repository at will • Why it fails? • Does not scale, hard to have confidence in code base Tuesday, February 28, 12
6. “GIT-FLOW LIKE” • Details description available at http://andrewdeponte.com under GIT BASED WORKFLOW REVISED. • Roles: Integrator, Newb • Branches: Topic, Development, RCs and RFs Tuesday, February 28, 12
7. INTEGRATOR ITERATION Integrator Central Repository GitHub 1. Makes Changes in Topic Branch 2. Run Full Test Suite 3. Merge Topic into RC Branch 4. Tag & Push RC Tuesday, February 28, 12
8. NEWB ITERATION Fork Central Repository GitHub Newb Integrator 1. Makes Changes in Topic Branch 2. Run Full Test Suite 3. Push Topic Branch to Fork 4. Make Pull Request 5. Reviews Pull Request 6. Run Full Test Suite 7. Merge Topic into RC Branch 8. Tag & Push RC Tuesday, February 28, 12
9. QA/STAGING • 2 Week Iterations (RC and RF branches for each week) • RC (Release Candidate) Branches & Tags • RF (Release Final) Branches & Tags • When RC Branch is ready tag it as RC release and push to QA. • If passes QA testing then push to Staging. If passes Staging tests then tag as RF and push to Production. Tuesday, February 28, 12
10. OVERSEER (FAIL) • Unexpected needed role resulting from this workflow • Oversees general repository state and mucho amazing Git branch management • Tags and Deploys RC branches to QA, Staging • Tags and Deploys RF branches to Production • Make sure shit doesn’t hit the fan & help integrators with state of tree and branches in relation to RCs and RFs. Tuesday, February 28, 12
11. INTEGRATOR (FAIL) Integrator Central Repository GitHub 1. Makes Changes in Topic Branch 2. Run Full Test Suite 3. Merge Topic into RC Branch 4. Tag & Push RC Tuesday, February 28, 12
12. NEWB (FAIL) Fork Central Repository GitHub Newb Integrator 1. Makes Changes in Topic Branch 2. Run Full Test Suite 3. Push Topic Branch to Fork 4. Make Pull Request 5. Reviews Pull Request 6. Run Full Test Suite 7. Merge Topic into RC Branch 8. Tag & Push RC Tuesday, February 28, 12
13. TREE MADNESS Tuesday, February 28, 12
14. GIT TREE BADNESS Tuesday, February 28, 12
15. “GITHUB LIKE” • A better world! • Much Simpler Tree • Peer Review • Simpler Process • Guarantee Test Run (Thanks to Multi-branch CI) • Encourages Shorter Lived Branches Tuesday, February 28, 12
16. “GITHUB LIKE” Central Repository Dev A Dev C Dev B Only ONE Role (Dev) Push Topic Branches to Central Repo Multi-branch CI Server Runs Tests Peer Review before Merge Only ONE Merge Branch (master) Tuesday, February 28, 12
17. LIFECYCLE PHASES • Planning • Design • Development • Stage Deployment • Prod Deployment • Released Tuesday, February 28, 12
18. TICKET STATUSES • Inactive • In Progress • Peer Review • Done • Won’t Fix • Duplicate Tuesday, February 28, 12
19. DEV ITERATION 1. Grab task from Dev Phase (Mark In Progress) 2. Checkout “master” branch 3. Pull the “master” 4. Create Topic Branch task based on “master” 5. Make Changes 6. Push Topic to Central Repo 7. Repeat Steps 5 & 6 until complete 8. Make Pull Request (Mark Peer Review) 9. Wait for Peer Review Results 10. Merge into “master” & Push (Move to Stage Deploy) Central Repository GitHub Redmine Tuesday, February 28, 12
20. PEER REVIEW (PULL REQ?) 1. Grab Pull Request (mark :hammer:) 2. Checkout the Branch you are reviewing 3. Verify Branch test state in Octopusci 4. If Fail (mark :thumbsdown:) 5. Run Tests & Manually Test changes/feature 6. If Fail Provide Feedback (mark :thumbsdown:) 7. Code Review, converse if needed 8. If Fail Provide Feedback (mark: :thumbsdown:) 9. If looks good (mark :thumbsup:) GitHub Central Repository Tuesday, February 28, 12
21. CONTINUOS DELIVERY • More confidence in code base • More confidence in ability to rapidly deploy • Insane amounts of cross-training going on • Forced us to make our test suite maintainable and efficient • Allows us to respond to business needs immediately • Marketing no longer needs a CMS to make language changes Tuesday, February 28, 12
22. “GITHUB LIKE” - TOOLS • Git & GitHub • RSpec 2, Cucumber, Guard, Capybara • Octopusci • One Server Setup Running Octopusci • Three Servers setup to Run Octopusci Remote Jobs Tuesday, February 28, 12