• Save

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,179 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,179
Views on SlideShare
4,179
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.