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.

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.

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.

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.

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.