# Code Development Guidelines

## **Commit Guidelines:**

* Commit messages are forced to have one of the following tags inside brackets:
* FIX
* FEATURE
* ENHANCE
* TEST
* DOC
* REFACTOR
* PERFORMANCE
* SETUP
* MERGE

<br>
Then, are followed by a space and finally, the commit message. This is possible using the regex: `/^[(FIX|FEATURE|ENHANCE|TEST|DOC|REFACTOR|PERFORMANCE|SETUP|MERGE)] .+/`

e.g., `[FIX] This is a 'fix' commit message`
**(Enforced by Gitlab)**

* Commit subject lines must be in the imperative mood, precise and illustrative. - e.g.,` [FEATURE] Add navbar to user's page`
* Never commit directly to master **(Enforced by Gitlab)**
* Branch names should match `(feature|test|setup|fix|enhance|refactor).+ `— the name should start with either feature, test, setup, fix, enhance or refactor and then contain a descriptive name of the issue in hands — e.g., `feature/seeMedicalRecords` **(Enforced by Gitlab)**

## **Merging Guidelines**

* Procedure to do before a MR:

* Checkout to master, `git checkout master`, and pull to have all of the changes made;
* Change to working branch;
* Do command `git rebase master`, this brings to the branch, the master commits that are ahead of the branch (due to other MR that have been accepted);
* Fix possible conflicts one by one and do `git rebase --continue` to move on to the next commit;
* Add files that have been fixed using `git add <file>`;
* After all is clean do `git push --force-with-lease`.
<br>

* A Merge Request (MR) must be approved by 2 people **(Enforced by Gitlab)**
* Merge Requests with UI need to contain screenshots

## **Structure Guidelines**

* **React components** must be structured in the following way:

   ├──components/
   |    ├──ComponentA/
   |    |   ├──ComponentA.js
   |    |   ├──ComponentA.css
   |    |
   |    ├──ComponentB/
   |        ├──ComponentB.js
   |        ├──ComponentB.css
   |
   ├──pages/
   |    ├──component-a.js
   |    ├──component-b.js
   |
   ├──tests/
        ├──ComponentA.test.js
        ├──ComponentB.test.js

* Component’s file name should be in Pascal Case- eg,. `EditButton`
* All components must be inside of the components directory
* The name of a component must be equal to the name of the component folder
* The filename for the Page Component must be in lowercase and each word separated by a hyphen- eg,. `edit-button`
* Keep components shallow so that there are better chances for reusing them

* **Backend components** must be structured in the following way:

  ├──api/
  |  ├──middleware/
  |       ├──validator/
  |       |    ├──validatorA.js
  |       |    ├──validatorB.js
  |                     ├──routes/
  ├──routes/
  |     ├──routeA.js
  |     ├──routeB.js
  |
  ├──controllers/
  |     ├──controllerA.js
  |     ├──controllerB.js
  |
  ├──models/
        ├──modelA.js
        ├──modelB.js

* All validators must be inside of the validators directory
* All routes must be inside of the routes directory
* All controllers must be inside of the controllers directory
* All models must be inside of the models directory
* The filename for the models must be in lowercase
* All controllers, routes and validators related to a model should have the same filename as the model.

## **Linting**

A linter is a tool that checks and analyzes code in order to report programming and stylistic errors, bugs and suspicious constructs. The goal of a linter is to make code more consistent and help to avoid bugs, making it easier to review.

* **ESLint:** Use ESLint, a linter tool for ECMAScript/JavaScript code.
To setup ESLint with VSCode install ESLint extension and on the main directory of the project do:
`cd backend`
`npm install`
`cd ../frontend`
`npm install`

* **Prettier:** Use to maintain consistency in the codebase.

## **Testing**

React components are tested using Enzyme integrated with Jest. Each test must be inside of the tests directory of the frontend folder. To run the tests use the command `npm run test`.

Backend testing is done using SuperTest integrated with Jest. Each test must be insife of the test directory of backend.

## **CI/CD**

The CI is currently divided into 5 stages: **security**, **test**, **quality**, **build** and **deploy**.

* **Security** runs a static analysis and dependency scan. It will eventually be departed from the pipeline into a scheduled job and it will only run automatically for merge requests to assure that the master remains safe. The goal is to keep the CI cost as low as possible.

* The **test** stage runs a script for the backend and one for the frontend. These scripts ensure the linting of the code and runs the tests via docker compose.

* The **build** and **deploy** stages assure the maintenance of staging and deployment of the application to a public host.

* A merge can only be accepted if the pipeline succeeds. **(Enforced by Gitlab)**

## **Branching Strategy**

* `master` is the default branch;
* `feature`, `fix`, `test`, `setup` and`refactor` branch from `master`;
* Merge requests trigger `security`, `test`, `quality` and `deploy` jobs;
* If CI has successfully ran and the merge as been approved during the review, the MR can be merged into `master`;