Development

Link to the Kanban board or this link, if you have account in Miro

Entry criteria

TO DO	In progress	In review	Ready to deploy	User testing	DONE
- Discussion problem with team members - Prioritize among issues - A performer has been appointed - A branch has been created in the repository	- Prioritize among issues - Issues are estimated - MR has been created	- Code fully implemented and self-reviewed - Pass all tests - Branch rebased on main - min 2 reviewers assigned	- MR is approved - The documentation is updated - All tasks for this issue are closed	- Test Environment Ready - Customer is informed	- Deployment is done - Documentation is done - Testing is complete

Git workflow

All project code you can find in our Github, however the main backlog is on our Gitlab repository.
Our team has several rules of operation:

Creating issues from the defined templates

• We use the templates when creating
• Try to fill in all the fields in detail and correctly

Labelling issues - Mark tasks with a label based on the size of the task (S, M, L) - Use a label to mark the urgency level of a task and its priority (high, medium, low) - Use type labels such as "Task", "Bug" etc

Assigning issues to team members - Distribute the load evenly (no more than 2-3 L-tasks per person for a sprint) - Assign tasks based on a person's specialization - The assigned executor is responsible for progress and timely status updates.

Creating, naming, merging branches - When creating a branch, name it according to its purpose - Make sure that name does not match the name of any existing (git branch --list) - Merge the branch only after you've tested the code and made sure it works

Commit messages format - Briefly and clearly describe two things: which file/directory has changed, and what changes have occurred.

Gitgraph diagram

Code reviews ( Pay attention to: ) - Code clarity - Code style_ - Tests _(new code should include unit/integration tests, if applicable) - Documentation

Merging pull requests - Minimum 2 approves - All tests pass (CI/CD pipeline must be successful) - Before merging, you must make sure that there are no conflicts with the main branch.

Secrets management

Rules for secrets management: - Do not store secrets in the code, but use environment variables for this purpose when uploading the code somewhere. - When developing locally, store variables in the .env file to avoid accidentally uploading them to the network. - Never commit passwords, API keys, tokens, or other secrets directly to a repository (even a private one).

Resolving issues - Prioritization: Critical bugs and blockers first, then new features. - Time estimation: If a task takes longer than planned, inform the team in advance.