Skip to content

Development Cycle

James Hibbeard edited this page Nov 1, 2021 · 1 revision

Development work flow

1. Create a branch off main

The name of the branch should be made in the following structure:

  • branch type:
    • Task - T
    • Bug - B
    • Refactor - R
  • Short description separated by _

T-add_login_features

Bildschirmfoto 2021-09-11 um 11.46.27.png

2. Writing code

You can link to other pages in your workspace in a couple ways:

  • Type /link, press enter, and type the name of the page you want. This creates a link below the current text block:

Engineering Wiki

  • To create a link inline, type @ followed by the title of the page, then press enter. The result looks like this: Engineering Guidelines

  • An overview of the code should be added to the notion file once it has been completed, this is to allow review and understanding of the work flow by the engineer and reviewer.

    Bildschirmfoto 2021-09-11 um 12.18.06.png

3. Create a pull request on Github

A pull request should be created early using the provided template, this allows for continuous feedback and review, by doing this it will add it to the TODO page on Git. The side column should also be filled in with the relevant fields. This page should show who the reviewers and assignees are. A label should be assigned that matches the description of the task and added to the correct project.

Screenshot 2021-10-18 at 23.39.59.png

Screenshot 2021-10-18 at 23.40.09.png

4. Submit for review

  • Assign the task in Notion to the appropriate reviewer.

  • You can always tag a person on a Notion page by typing @ followed by their name.

  • Within slack write a message within engineering wiki stating that it is now ready for review and tag the person who is reviewing it in the chat.

  • All merges have to be reviewed by 1 other developer before they are merged into the main branch to be production ready.

    Screenshot 2021-10-18 at 23.40.05.png

5. The reviewer should start dialogue and review the code.

  • The Engineer doing the review should sit and discuss the code with the engineer if there are any confusion, problems or conflicts. This can be done through dialogue or over zoom/face to face

6. The reviewer should merge or close, and delete the branch.

  • The merging or closing of the branch is the end of the process on this branch.
  • Once it is merged and closed notion should be updated and the branch deleted.
  • Once the branch is closed or merged the reviewer should post the status within the pull requests channel in slack tagging the initial developer and all relevant parties.

Clone this wiki locally