Skip to main content

Backend Development Flow

This page decribes the standard development flow we follow in the Rails project's repository.

From a higher point of view, we follow a sort of trunk based development in which a branch is needed for each feature/fix/enhancement/etc. For each branch, a Pull Request allow bringing the branch commits to the main branch, using "Squash & Merge" method. Once the branch has been merged and the main CI/CD build successfully passed, a draft release is ready to be pushed to production environment.

1. THEORETICAL PART​

1. JIRA:​

  1. a task describing the requirements must be present in Jira and linked to the PR (as explained in GITHUB Pull Request Creation dot 3)
  2. any edit to the task logic/requirements must be reported on Jira task, no matter the reason
  3. if some doubts are present during code writing or before starting it, you have to report them
  4. if doubts change requirements, they must be reported on Jira task
  5. after the GitHub PR merge, the Jira task must be updated in Status (Approved) field

2. PRACTICAL PART​

1. GITHUB:​

1. Branch initialisation​

  1. for any changes, a new branch from main must be opened
  2. a merged/deleted branch must not be used
  3. the convention on branch naming is: fix/..., feature/..., enhancement/..., update/..., then Jira task identifier (PROJECT-ID) just after the /, a dash - after it and then the branch name as words spaced by dashes - (not underscore). For example feature/TWPRO-10-new-billing-logics a. fix is used for bug fixing b. feature is used for a new behaviour of the application c. enhancement is used for an improvement invisible for the outside (ex: refactoring or better performance) d. update is used for gems/Ruby version update

2. Pull Request Creation​

  1. PR can be opened (in draft state) with the first commits, in order to have CI feedback and to obtain incremental reviews
  2. for PR code reviews see dedicated section
  3. the convention on PR naming is to add a prefix [core][admin][main][graph][etc] to specify with sub-project would be intentionally modified (modifying [core] it's implied that other parts of the projects would change)
  4. apart from the Jira task link, no description is needed in the GitHub PR, a comprehensible title would be ok (and good looking, so no Fix/venue_model 😬)

3. Development​

  1. do not push commits too frequently, in order to keep CI/CD server alive
  2. see CODE
  3. see TESTING

4. Code review flow​

  1. let your code be ready for another developer's review
  2. see CODE REVIEW

5. Merge​

  1. each PR must pass CI-tests and must be approved by another backend developer
  2. assign the proper GitHub label
  3. if the branch is a lot of commits behind main or there are conflicts, update the branch from main
  4. all PR must be merged using "Squash & Merge" method, using #{PR title} (##{PR number}) as commit title and empty description
  5. remember to delete the branch (if not automatically done by GitHub)

6. Release​

  1. when main build sucessfully pass, a release is ready to be deployed
  2. following the trunk based development strategy, the less PRs we include in each release, the better.
    PLEASE try to release your changes as soon as possible to keep that number to 1
    !!!info Non-code changes If non-code changes PR are merged (documentation, comments), it's up to the author to choose between releasing it immediately or waiting for the next merge to happen. !!!
  3. to release changes on production, follow this

2. TESTING:​

  1. everything must be properly tested
  2. everything must be properly tested
  3. EVERYTHING MUST BE PROPERLY TESTED

1. unit testing:​

  1. add unit tests to the new feature or changes on the code using rspec
  2. check that the tests coverage for the new feature is sufficient using undercover

2. manual testing:​

  1. manual tests have to be done for each PR, with a local production database, with Postman client or similar
  2. also response timing has to be tested, query and EPs have to be as fast as possible and preload data

3. active admin:​

  1. view/edit/index/create methods must be created
  2. pages have to be fast on loading and processing
  3. pages have to be usable and administration-friendly

3. testing environments:​

  1. if deep testing are required, a test environments are available
  2. main commits' deploy is automatically done after CI build passing
  3. main branch can be used to test the whole app, from B2C and B2B clients