Skip to content

Repository and code management

Jump to bottom
Alvaro Jesus Bernal Caunedo edited this page Feb 26, 2024 · 4 revisions

Repository and code management

Document containing the branching strategy, commit policy, pull requests strategy, versioning policy and folder structure

1. Commits policy

It is important to establish a commit policy for the project, as clear and descriptive commit messages will help team members to understand the changes made to the commit as well as help track the progress of the project. The template we will use, in line with best practice, will be of the form:

# No more than 50 chars. #### 50 chars is here: #

# Wrap at 72 chars. ################################## which is here: #

type: subject 

body

### type
# feat (new functionality)
# fix (bug fix)
# research (incorporation of experimental code, may be non-functional)
# refactor (refactoring of code)
# docs (documentation update)
# test (incorporation or modification of tests)
# conf (modification of configuration files)

### issue
# Consists of a brief description of the issue that has been addressed and should begin with a verb in the past participle. 
# The corresponding issue (if any) will be referenced such that: `#<ID_issue>`.

### body (optional)
# To be used in case the issue is not sufficiently descriptive.

### Example
# conf : Update docker-compose.yml

2. Repository structure

This Node-RED repository comprises several key components. The 'documents' directory stores example documents, aiding in understanding the implementation. The 'flows' directory, on the other hand, houses all subflows developed within the project, providing segmented functionalities. The 'flows.json' file contains comprehensive examples showcasing the usage of every component within the 'status' project. Alongside these directories, the repository includes essential files such as '.gitignore', 'README.md', 'package.json', and 'settings.js', each contributing to the repository's functionality, documentation, and configuration.

- documents 
- nodes
- .gitignore
- README.md
- package
- flows.json
- settings.js

3. Branching strategy

3.1. Main branches

The main branches of the project will be main and develop where stable functionality and functionality under development will be gathered, respectively.

3.2. Fixing production bugs

In case a bug is found in main, a new branch hotfix will be created to fix the bug with the following structure:

  • hotfix/ID_issue-Branch_name. Then, a new pull request will be created to merge in main and develop.

3.3. Release branches

When all the implementation is done, we will prepare the application for release. This will involve moving all the functionality implemented in our development branch to a new release branch with the structure release/ID_issue-Branch_name

It is in this branch that we will prepare our application for release. To do this, any defects or warnings shall be removed that may arise and clean the code of other minor imperfections that may have been passed through the reviews.

Once the code is ready for release, the final code will be passed to the main branch, which will be used to deploy the application. Finally, a new tag will be created following the versioning policy.

4. Code reviews and pull requests strategy

When there is a functional increment in develop, a pull-request will be created to merge to main, once created, a review of the increment will be performed to avoid introducing errors and it will be merged. The pull requests will follow this template:

||| PULL REQUEST STRATEGY |||

**Pull Requests**
For each new functionality, a Pull Request (PR) will be created to request the integration of the feature branch into the Develop branch. A predefined template for PRs will be followed to ensure consistency in the provided information.

**Pull Request Template**
## Description
[Detailed description of the implemented functionality or correction]

## Related Issue
[Link to the related issue]

## Screenshots
[If applicable, include screenshots]

## Checklist
- [ ] I have tested the changes locally.
- [ ] Documentation has been updated as needed.
- [ ] All necessary reviewers have approved the code.

5. Versioning policy

As versioning policy we will use a semantic versioning with the following structure:

  • [Major].[Minor].[Patch]. In the following cases the version number will be incremented:
  • Major: major changes in the project. For example: An breaking change.
  • Minor: changes in the functionality of the project, either improvements or new functionality compatible with previous versions.
  • Patch: bug fixes from previous versions. Tags can be added for pre-release versions and for metadata compilation, although it may mean that the version is not stable or that it may not satisfy compatibility requirements.

In addition, it must meet the following requirements:

  • When Major is incremented, Minor and Patch must be reset to 0.
  • When Lesser is incremented, Patch must be reset to 0.
  • Precedence is determined by the difference when comparing identifiers from left to right. For example: 1.0.0 < 2.0.0 < 2.1.0.

In our case, the labels will be used mainly in production releases. For example: the first release will be 1.0.0.

Clone this wiki locally