Aggrements - JU-DEV-Bootcamps/ERAS GitHub Wiki
JALA UNIVERSITY DEV-BOOTCAMP 2024-2025
For information about different technologies considered and the reasoning behind the decision made in this section, please visit Tool researchs and proposals
- Framework: Angular v19
- Component Library: Angular Material
- Charts: ???
- Framework: ASP.NET 8.0
- For ORM: Entity Framework Core
- For PDF Report generation: QuestPDF
- API Testing: PostMan
- Frontend Testing: Karma
- Backend Testing: xUnit
- Container: Docker
- CI/CD: ???
- CI/CD Libraries: Husky???
- Cloud image container: Docker Hub
The Feature Branching Strategy allows developers to work on new features or bug fixes in isolated branches within submodules. This approach helps maintain a stable main branch while enabling parallel development. Steps to Implement Feature Branching in Submodules
prefix = release|feature|ci|docs|bugfix|refactor|chore|style
storyNumber = "ERAS-BE #13".specialTrim() // "BE13"
storyTitle = verb + object // "importcosmic"
${prefix}/${storyNumber}/${stroyTitle}
<NAME_IMG>:<SEM_VER>-<SHORT_SHA>-<ENV_TAG>
Being:
- <NAME_IMG>: Image name. Eg: ERAS-FE
- <SEM_VER>: Semantic version: ... Eg: 0.2.13
- <ENV_TAG>: Special tag, indicating its environment. Eg: [dev | prod]
- <SHORT_SHA>: Git's short commit SHA. Eg: 6220e0e
Examples:
- ERAS-FE:0.2.13-6220e0e-dev
- ERAS-BE:1.0.2-2342e1e-prod
The ticket should follow these characteristics before the story point assignment as part of the Definition of Ready
- Ticket name: to track the sub-module and location of every ticket should contain in the name the following format: {submodule}-{Area}:{Description}
- The submodule: should be (BE for Backend, FE for Frontend, RT for root "ERAS")
- Area: should be the area of the page where is applied Example: Configurations, Dynamic Heatmap
- Description: The classic descriptive tittle.
- Labels: Every ticket when is created or identified the sub-module and/or the area affected, a related label should be added to the ticket to track in the future the ticket.
We gather data from Cosmic Latte's polls.
Whenever we encounter a question with multiple choices, we interpret the final risk value of said question as the average of the options chosen.
Every end of sprint a demo meeting is performed to show the progress to the client. 1 Day before the Demo a code freeze. Any US passed to Ready for Test will be included at the previous deadline. Regularly SM should- Start checking stuff to decide and see what's going to the demo.
The bug tickets should include an AC that helps to define the QAAC. The areas where the fix should have an impact should be explained to the QA in the ticket.
- best practices for coding
- Branching strategies
- Version control strategies
- Proposed libraries
- Testing practices and minimum code coverage
- Compromise for when to move to "Ready for testing" and more