Multi-QA Environment, parallel development with Git


Published on

Using Git for source code management, this is the process we're using to support developing multiple projects in parallel (same code base), with multiple QA environments.

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Multi-QA Environment, parallel development with Git

  1. 1. MULTI-QA BRANCHED DEVELOPMENT Using Git By Jon Messer & Tariq Ahmed
  2. 2. PROBLEM DEFINITION  Current source code methodology and tooling uses a linear approach.  Big changes can jam up QA for a long time.  QA difficult to know what’s being tested when multiple changes are in QA.  Forced to “leap frog” emergency/hotfix changes, which is high risk.  Solution:  Test changes independently.  Have flexibility to control what is being tested at any given time. Dev QA Staging
  3. 3. WHAT WE NEED TO DO – SYSTEM WISE PreProdIntegration QA1 RTB QA2 QA3 Dev • You develop off your own/team feature branch. • You then move the feature branch into a targeted QA environment as designated by the Release Manager. • When verified, changes would merge into an integration branch for testing changes together as a build. •Testing would be done in the Integration environment. •After integration testing, the build/release is staged and deployed. How it works: Status: QA Testing Set QA Env Dev spins off feature branch Rel Mgr approves & designates QA Env per project Dev merges to integration branch. Status: Integration Testing Prod Release branch xyz spun off and staged for release Release xyz released by Rel Mgr.
  4. 4. BASIC PROJECT BRANCH LIFE CYCLE Master Integration PRJ-9232 In Progress QA Testing QA Env TBD by Rel Mgr new branch merge back in Integration Testing Minor Fix new release branch v457 REL-457 VerifiedResolved Code Reviewed merge to master Released Branch no longer needed Staging/Pre-Prod Minor Fix rare fixes need to merge back down Integration now locked to just planned branches Integration now open to next group of changes time branch merge or create In Progress = Development
  5. 5. INTEGRATION TESTING OF MULTIPLE PROJECTS Master Integration PRJ-9232 In Progress QA Testing new branch Integration Testing new release branch v457 REL-457 VerifiedResolved Code Reviewed merge to master Released Staging/Pre-Prod PRJ-9987 merge QA TestingIn Progress time ensure any changes merge back down
  6. 6. HANDLING MAJOR ISSUES Master Integration PRJ-9232 In Progress QA Testing Issues w/9232 now aiming for next release major fix REL-457Staging/Pre-Prod PRJ-9987 QA TestingIn Progress still issues - back out 9232 so that release can move fwd v457 REL-458 time v458 good to go  Project branch remains open until moved to a staging/release branch.  If a major issue is encountered, changes can be worked on the project branch and merged back into integration.  Or if the release deadline is looming, that project is backed out of integration. project branches stay open until changes are spun off on a release branch
  7. 7. WORKING WITH RTB CHANGES Master Integration RTB REL-457Staging/Pre-Prod RTB-1234 QA Testing In Progress v457 time  Multiple RTB (run the business, point releases) changes will co-exist.  An RTB branch is used to group these together so that they can move as a whole to an QA RTB environment. ensure any changes merge back down RTB-4567 In Progress new one created as soon as the previous RTB branch is released
  8. 8. MULTI-DEVELOPER PROJECTS Master Integration PRJ- {Title} REL-457Staging/Pre-Prod PRJ-1234 QA Testing In Progress v457 time  For large multi-developer projects a similar technique to the RTB approach is used. ensure any changes merge back down PRJ-4567 In Progress major fix minor fix
  9. 9. WORKING WITH HOTFIXES Master Integration HF-9766 v458 time  Emergency changes are branched off master, quickly tested, and then released. In Progress QA Testing Hotfixes
  10. 10. SUMMARY  Using Git, all of these branch operations are cheap (vs. SVN which are expensive).  With Git it’s easy to move in and out which branch is being tested in any given environment.  vs. currently where the (one) QA branch is tied to the (one) QA environment.  We have now 3 QA environments, but can test one branch for a few hours and then test another branch later... easily...  Master and Integration are the only long lived branches. Even though you delete the short lived ones, Git preserves the full history.