---
# System prepended metadata

title: Code Development Guidelines

---

# 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:

   ```bash
   ├──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:

```bash
  ├──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`;