1 / 10

Multi-QA Branched Development

Multi-QA Branched Development. Using Git By Jon Messer & Tariq Ahmed. http://www.amcomtech.net. Problem definition. Current source code methodology and tooling uses a linear approach. Big changes can jam up QA for a long time.

lang
Download Presentation

Multi-QA Branched Development

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Multi-QA Branched Development Using Git By Jon Messer & Tariq Ahmed http://www.amcomtech.net

  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. What we need to do – System Wise Dev spins off feature branch Release branch xyz spun off and staged for release QA1 RTB Dev QA2 Integration PreProd Prod QA3 Release xyz released by Rel Mgr. Rel Mgr approves & designates QA Env per project Dev merges to integration branch. Status: Integration Testing Status: QA Testing Set QA Env How it works: • 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.

  4. Basic Project Branch Life Cycle branch merge or create In Progress = Development Released v457 Master Code Reviewed Resolved Verified merge to master Minor Fix Staging/Pre-Prod REL-457 Integration now locked to just planned branches rare fixes need to merge back down new release branch Minor Fix Integration merge back in Integration Testing Integration now open to next group of changes new branch PRJ-9232 Branch no longer needed QA Testing QA Env TBD by Rel Mgr In Progress time

  5. Integration Testing of Multiple Projects Released v457 Master Code Reviewed Resolved Verified merge to master Staging/Pre-Prod REL-457 new release branch ensure any changes merge back down Integration Integration Testing new branch merge PRJ-9232 In Progress QA Testing PRJ-9987 In Progress QA Testing time

  6. Handling Major Issues • 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. v457 v458 Master still issues - back out 9232 so that release can move fwd Staging/Pre-Prod REL-457 REL-458 good to go Integration now aiming for next release Issues w/9232 PRJ-9232 major fix In Progress QA Testing project branches stay open until changes are spun off on a release branch PRJ-9987 In Progress QA Testing time

  7. Working with RTB changes • 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. v457 Master Staging/Pre-Prod REL-457 ensure any changes merge back down Integration new one created as soon as the previous RTB branch is released RTB QA Testing RTB-1234 In Progress RTB-4567 In Progress time

  8. Multi-Developer Projects • For large multi-developer projects a similar technique to the RTB approach is used. v457 Master Staging/Pre-Prod REL-457 ensure any changes merge back down Integration minor fix PRJ- {Title} QA Testing PRJ-1234 In Progress PRJ-4567 major fix In Progress time

  9. Working with Hotfixes • Emergency changes are branched off master, quickly tested, and then released. v458 Master HF-9766 Hotfixes QA Testing In Progress Integration time

  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.

More Related