<aside> 💡 Use this template to create guidelines for all of the engineers on your team. Add a table of contents by typing /table of and pressing enter.

</aside>

Branching Policy

We utilize a branching policy that consists of a main branch, a testing branch, and a develop branch:

The main branch is the master branch, which is the main and stable branch of the codebase. It should only contain code that has been thoroughly tested and is ready for production.
The test branch is used for testing purposes. When a developer wants to test a new feature or bug fix, they should create a new branch from the develop branch and name it according to the feature or bug fix they are working on. Once the testing is complete, the developer should merge the testing branch back into the develop branch.
The develop branch is used for ongoing development and integration of new features. When a developer finishes implementing a new feature or bug fix, they should merge their feature or bug fix branch into the develop branch. This allows other developers to test and review the code before it is merged into the main branch.
Feature branches are used for the development of new features. They should be created from the develop branch and named according to the feature being developed. Once the feature is complete and has been tested and reviewed, it should be merged into the develop branch.
Hotfix branches are used to quickly fix critical issues in the main branch. They should be created from the main branch and named according to the issue being fixed. Once the hotfix is complete and has been tested, it should be merged into the main branch and the develop branch.
Bugfix branches are used to fix non-critical issues in the codebase. They should be created from the develop branch and named according to the issue being fixed. Once the bug fix is complete and has been tested and reviewed, it should be merged into the develop branch.

By using this branching policy, developers can work on new features and bug fixes in isolation, while still being able to collaborate with their team and ensure that the codebase remains stable and reliable.

CI/CD strategy

CI/CD (Continuous Integration/Continuous Deployment) is a software engineering practice that aims to minimize the time between writing code and releasing it to production. It involves setting up a pipeline that automatically builds, tests, and deploys code changes.

Overall, the goal of CI/CD is to streamline the software development process and reduce the time and effort required to release new features and updates. It helps to ensure that code is of high quality and can be deployed quickly and reliably.

Automated testing: Automated testing involves setting up a suite of tests that are run automatically every time code is changed. This helps to catch issues early in the development process and ensures that the code is of high quality.
Continuous integration: Continuous integration involves automatically building and testing code changes every time they are committed to the version control repository. This helps to catch issues early in the development process and ensures that the code is ready for deployment.
Continuous delivery: Continuous delivery involves automatically building and testing code changes, but unlike continuous deployment, it does not automatically deploy them to production. Instead, it makes the code changes available for manual deployment.
Continuous deployment: Continuous deployment takes continuous delivery a step further by automatically deploying code changes to production as soon as they pass testing. This allows for rapid release cycles and ensures that code changes are released to users as quickly as possible.

Our CI/CD strategy can be split into two phases.

O - First code

In this phase we will utilizes Automated testing and Continuous integration