Skip to content

Home

Jump to bottom
Paulo Martins edited this page May 6, 2022 · 5 revisions

Summary work diagram

Untitled Diagram

Introduction:

  • There are 2 fixed branches: Staging and Production
  • There is, ideally, 1 or 2 branches for each person
    • In this branch, you will work on a isolated issue (ex: fixing a specific bug)
  • If you're working on a big change, such as a new feature, workflow will change a little*
  • There are 3 people in this story: You, The Tester, and the Staging Manager
    • The Staging Manager: the one who is responsible for managing the Staging and Production process. No one else is allowed.

Starting Process:

  1. You will create a local branch with the name or number of the issue you will solve

    • Pattern: "issue[number]"

  2. This branch is created based on Staging branch

  3. You will work on your changes in this branch as normal

  4. If, along the way, you find other issues related to the one you're working, you:

    4.1. Create issues on the board for all of them, but start the issue name with the branch number that these relate to

    • Example:
    • Issue #108 has 2 other issues related to them. So, the other two's names are "#108 Issue Description"
    • That means that all these 3 issues should be worked on in a single branch: the #108 branch

Recurring Process:

  1. Everyday, at the beggining of the shift, you will go to the Staging branch and Pull changes
    • If there are no changes, skip the next step
  2. If there are changes, merge locally the Staging branch into your issue[number] branch
  3. Continue working on your branch as normal

When the Issue is Done:

  1. You will open the Github Boards, move your card to the "Test Queue" section and assign a tester

  2. You will, then, repeat the "Starting Process" with another issue, creating a new branch (but not deleting the previous one)

  3. In the meantime the Staging Manager will see the "Test Queue" section and do the following:

    3.1. He will go into the AWS, and checkout from Staging branch to your issue[number] branch

  • Yes, the Staging Server (backtest) will have your branch in it, not the Staging branch

    3.2. He will pass your issue card from the "Test Queue" to the "Ready to Test" section

  • The "Ready to Test" section should have only ONE issue, because the AWS is using a branch with only that issue

Testing:

  1. The tester will, everyday, see the "Ready to Test" section, and access the Staging Server (backtest) to test the issue

  2. If the issue didn't pass the test:

    2.1. The tester puts the issue back in the "To Do" section, with a label "Declined" added to it

     2.1.1. The label is necessary for the programmer to know with more clarity that his issue came back and has new

    2.2. The tester then makes a post in the issue's chat explaining what went wrong

    2.2. Meanwhile, the Staging Manager checks that the "Ready to Test" section is empty, and repeats the process:

     2.2.1. He will get the upmost issue in the "Test Queue" and pass it to "Ready to Test"

 2.2.2. He will checkout from your issue[number] branch to the one of the issue currently in "Ready to Test"

     - If there are no issues left in "Test Queue", he will checkout to Staging branch

  3. If the issue did pass the test:

    3.1. The tester puts the issue in the "Ready for Staging" section

    3.2. Whenever the Staging Manager sees an issue in "Ready for Staging" section, he will merge the issue[number] branch into ## the Staging branch

    3.3. Then, he will put it in the "Ready for Production" section, where it will stack across the week with other issues

  4. Every monday, then, the Staging Manager will merge the Staging branch into the Production branch

  5. Then, he will get all issue cards that are in "Ready for Production" and close them

-- 𝒯𝒽𝑒 𝑒𝓃𝒹 --

Observations:

  • Yes, you will not merge with development anymore. Much less update AWS
  • You will, for every new issue, create a new branch with the code of the issue
    • Ideally you won't have more than 2 issue branches (1 is in testing phase and 1 you're working on at the moment)
  • Yes, for really small bugs or fixes, this seems like too much burocracy, but it's important to be consistent

*About Big Tasks

  • Big tasks, such as new features or code refactoring, still lack a proper process
  • We need to discuss better about this case
Clone this wiki locally