• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content

Loading…

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

Like this presentation? Why not share!

Multi-QA Environment, parallel development with Git

on

  • 4,008 views

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.

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.

Statistics

Views

Total Views
4,008
Views on SlideShare
4,008
Embed Views
0

Actions

Likes
3
Downloads
0
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Multi-QA Environment, parallel development with Git Multi-QA Environment, parallel development with Git Presentation Transcript

    • 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.
      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
    • What we need to do – System Wise
      Dev spins off feature branch
      Release branch xyz spun off and staged for release
      QA1
      RTB
      PreProd
      Integration
      QA2
      Dev
      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.
    • Basic Project Branch Life Cycle
      branch merge or create
      In Progress = Development
      Released
      v457
      Master
      Code
      Reviewed
      Verified
      Resolved
      merge to master
      Minor Fix
      REL-457
      Staging/Pre-Prod
      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
    • Integration Testing of Multiple Projects
      Released
      v457
      Master
      Code
      Reviewed
      Verified
      Resolved
      merge to master
      REL-457
      Staging/Pre-Prod
      new release branch
      ensure any changes merge back down
      Integration
      Integration Testing
      new branch
      merge
      PRJ-9232
      In Progress
      QA Testing
      PRJ-9987
      QA Testing
      In Progress
      time
    • 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
      QA Testing
      In Progress
      time
    • 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
      REL-457
      Staging/Pre-Prod
      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
    • Multi-Developer Projects
      For large multi-developer projects a similar technique to the RTB approach is used.
      v457
      Master
      REL-457
      Staging/Pre-Prod
      ensure any changes merge back down
      Integration
      minor fix
      PRJ- {Title}
      QA Testing
      PRJ-1234
      In Progress
      PRJ-4567
      major fix
      In Progress
      time
    • 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
    • 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.