OneConnectProduct TeamQA/Dev QA/DevBranching/Delivery Standards and Work Flow (OnePlan)

Branching/Delivery Standards and Work Flow (OnePlan)


The purpose of this documentation is to describe in detail the layout/standards/guidelines of the Wicresoft Code Branch System as well as the rules set.

Branch Types:

Branch Type Description Branch Name
Master/Production Branch Used for deploying arelease. Branches from, and merges back into, the development branch.
Development Branch/Peer Review Usually the integration branch for feature work and is often the default branch or a named branch.
QA Branch The QA branch is where development checks in their code after peer review is completed and a new QA build is kicked off from this branch. Once build is completed, it is then auto deployed to the QA environment for testing. QA
Emergency QA Branch This branch is created only when there is an approved emergency release to production.  Senior Developer will branch off current EQA branch. Developer assigned to emergency EQA issue will check code into EQA branch. EQA
Personal Developer Branch This branch is the personal developer branch where coding is done by the assigned developer.  This branch serves as a developer’s code work for the product.
Custom Customer Used for developing custom customer code that resides on top of the master branch code.

Bi-Weekly Release Cycle: 2 Week sprint cycle

  1. Enhancement(s)/Task(s)/Bug(s) are entered into VSTS Backlog system.
    1. Product Owner/QA Lead review request(s) every Monday of the new sprint cycle. (Discuss coding/testing time)
      • Approved: Request(s) are assigned to developer(s).  All parties (Product Manager, Developer and QA) must agree to the backlog request list before developer begins coding.  Each request in the approved list will be placed into the current sprint cycle iteration in VSTS.
      • Not Approved: Request(s) is denied and closed in Backlog
      • Code Freeze Date is set.
      • QA reviews all approved request with product owner the technical functionality of request and use case.
      • QA takes information and begin drafting test cases in VSTS for each backlog request.
  2. Developers begin coding in their Personal Dev Branch (PDev).
  3. Once Coding is complete, developer checks code into OnePlan Branch and pushes code into QA environment for testing.
    1. Backlog:
      • Developer must change all approved backlog request (that was approved) state to "Ready For QA".
  4. Code Freeze:
    1. Once code freeze is initiated, no new code is to be checked into branch as this may introduce new issues in the application and extend out testing timeline.
  5. Enhancement(s)/Task(s)/Bug(s) Passed QA Testing:
    1. If testing fails then Developer is notified and backlog status is set back to “Active” and reassign back to developer.
      • Then cycle repeats starting from Step 2.
    2. Once QA test and approves all task(s), development will be notified and QA changes backlog ticket from "Ready For QA" to "Ready for Regression".
    3. New Release build is created and auto deployed to Production Environment.
    4. QA performs quick smoke test to verify validity of build.
    5. Once smoke test completes, go live.

Backlog: Bug/Feature/Task/User Story:

  1. Any Bug/Feature/Task/User Story request MUST be entered in VSTS backlog!
    1. Product Manager(s), Senior Developer and QA will determine if the request is valid or not.  If not valid then the request status can be set to “Abandoned”.
    2. Conditions when entering backlog request:
      • Be as detail as possible with your description.
      • Provide detail reproduction steps. (Step by Step instructions, screenshots, video capture, and/or any other means to help QA reproduce error.)
      • Provide detail system information. (Environments, URL, and etc.)
      • For User Story, provide detail information in the acceptance criteria field of the backlog request ticket. (Screenshots or videos are extremely helpful since this will help QA draft proper and accurate test cases).
    3. QA Engineer must enter comments into backlog request if resolved issue(s)/request(s) has been verified and approved by QA then set the appropriate status.
    4. Statuses of backlog request must be maintained by QA, Developer, and Product Manager in accordance to workflow rules.

Weekly Meetings:

  1. A recurring meeting scheduled to discuss sprint cycle and progress of cycle when cycle is initiated.
    • Impromptu meeting may occur between Developer and QA to discuss issues, user stories, or any concerns related to current sprint cycle.

Procedure For Emergency Product Release:

In the event that an emergency delivery is necessary upon management approval, QA and Dev will follow the same work flow except for one caveat.  Prior to Senior Developer integrating code into QA branch, the Senior Developer will branch off current QA branch and name it "TEQA" (Temporary Emergency QA Branch).  The Senior Developer will then integrate the emergency fixed code into TEQA branch and new build will kick off. The code will auto deployed into QA environment.  Development will notify QA to begin testing.  If testing passes, Senior Developer will integrate to Master branch and deploy into production.