SCM:Table of Contents

...

Good practices for development and git flow

• The code reviews are per task;

• Create a feature flag to your feature and create a technical debt to remove the flag posteriorly

• Analyze cicle-ci: https://app.BRANCHScircleci.com/projects/project-dashboard/github/rbilabs/

  • Check if your PR is good at the pipeline workflow

  • After the merge to master, check if all is well and if the job runs till the end

Branchs and commits

• Always create a branch referring to

  story

  sub-task from master branch

• We work in a trunk-based like:

  • Master branch ← sub-task branch

    • We should avoid to create Story branch. Only as last resource and if makes sense

• Branch name using the Jira ID and sub-task name:

  • examples:

    • To features: feat/IBFEC-123-sub-

      story

      task-name OR feat/IBFEC-123

    • To bugs: fix/IBFEC-123-sub-task-name OR fix/IBFEC-123

    • To bugs in prod or fires: hotfix/IBFEC-123-sub-

      story

      task-name OR hotfix/IBFEC-123

• Commit name:

  • Prefix - is the type of your commit. Accepted prefixes are:

    • feat | fix | hotfix | build | docs | ci | perf | refactor | style | test

    • examples:

      • [IBFEC-123] feat: added feature flag on component

      • [IBFEC-123] hotfix: fix to resolve save error

      • [IBFEC-123] test:

        [IBFEC-123] -

        create unit test componentAnalyze each commit on cicle-ci:

  • This is based in Conventional Commits:

    • https://

      app

      dev.

      circleci.com

      to/

      projects/project-dashboard/github/rbilabs

      maxpou/enhance-your-git-log-with-conventional-commits-3ea4

    • https://www.conventionalcommits.org/en/v1.0.0/

Good practices

...

when open a new PR

• If you are changing an existent code, after you finish is good to run the integration tests to validate that nothing was broken and attach the print on your pull request

• Always attach evidence of your job, unless it’s not possible

  • We suggest using the Before and After sections to compare what’s changed. If the repo doesn't have these sections, you should add them manually in the PR description

• Add descriptions that you think are worth mentioning, for example, when you adjust something that is not directly related to your task

...

Important topics to be filled in

...

(based in Whitelabel App template)

• PR name: Always use the Story namesub-task name for the title and the sub-task Jira ID for the “label” [IBFEC-X]

  • [IBFEC-3][Q2] - Optional Secondary Call to Action

• Summary: A summary of what this activity is about, for example:
  In this demand, a new flow was developed to save the user's address.

• Context: Give the context with more details of the development, describe something more detailed

  • Add the Jira link of the story, Figma, Confluence and etc

  • It is important to inform which flags were added, another important detail is to verify the impact of this flag turned on, as a guarantee to leave it turned on only in the needed environment (for example, PLK ES)

  • Adding extra context information, for example:

In this new address saving flow, the user will be able to save his address entered in the delivery flow, the user will be able to add a nickname to your saved address and in the order details it will add a contact phone and that phone will be saved in your address, when the user goes to make a new delivery, he will be presented with a list with all his saved addresses, so he can choose which one
he prefers and his address and telephone data will already be filled in.

• Links to related PRs:
  In this place we must place links that are related to this activity, for example, the Jira link of the story, other activities that can bring impact.
  It is important to inform which flags were added, another important detail is to verify the impact of this flag turned on, as a guarantee to leave it turned on only in DEV environments and for PLK.Screenshots
  

• Screenshots (Before and After)
  Here we can add photos, GIFs or videos of how the flow was and how it turned out, the more details the better

Obs: If the repo that you are working on doesn't have this template for the PR description, you should add this information manually. This is important to help the reviewer.