mirror of
https://github.com/azaion/gps-denied-desktop.git
synced 2026-04-22 15:06:35 +00:00
Oleksandr Bezdieniezhnykh
74 lines
2.9 KiB
Markdown
74 lines
2.9 KiB
Markdown
# Create Initial Structure
|
|
|
|
## Initial data:
|
|
- Problem description: `@_docs/00_problem/problem_description.md`.
|
|
- Input data: `@_docs/00_problem/input_data`. They are for reference only, yet it is an example of the real data.
|
|
- Restrictions: `@_docs/00_problem/restrictions.md`.
|
|
- Acceptance criteria: `@_docs/00_problem/acceptance_criteria.md`.
|
|
- Security approach: `@_docs/00_problem/security_approach.md`.
|
|
- Full Solution Description: `@_docs/01_solution/solution.md`
|
|
- Components with Features specifications: `@_docs/02_components`
|
|
|
|
## Role
|
|
You are a professional software architect
|
|
|
|
## Task
|
|
- Read carefully all the component specs and features in the components folder: `@_docs/02_components`
|
|
- Investigate in internet what are the best way and tools to implement components and its features
|
|
- Make a plan for the creating initial structure:
|
|
- DTOs
|
|
- component's interfaces
|
|
- empty implementations
|
|
- helpers - empty implementations or interfaces
|
|
- Add .gitignore appropriate for the project's language/framework
|
|
- Add .env.example with required environment variables
|
|
- Configure CI/CD pipeline with full stages:
|
|
- Build stage
|
|
- Lint/Static analysis stage
|
|
- Unit tests stage
|
|
- Integration tests stage
|
|
- Security scan stage (SAST/dependency check)
|
|
- Deploy to staging stage (triggered on merge to stage branch)
|
|
- Define environment strategy based on `@_docs/00_templates/environment_strategy.md`:
|
|
- Development environment configuration
|
|
- Staging environment configuration
|
|
- Production environment configuration (if applicable)
|
|
- Add database migration setup if applicable
|
|
- Add README.md, describe the project by @_docs/01_solution/solution.md
|
|
- Create a separate folder for the integration tests (not a separate repo)
|
|
- Configure branch protection rules recommendations
|
|
|
|
## Example
|
|
The structure should roughly looks like this:
|
|
- .gitignore
|
|
- .env.example
|
|
- .github/workflows/ (or .gitlab-ci.yml)
|
|
- api
|
|
- components
|
|
- component1_folder
|
|
- component2_folder
|
|
- ...
|
|
- db
|
|
- migrations/
|
|
- helpers
|
|
- models
|
|
- tests
|
|
- unit_test1_project1_folder
|
|
- unit_test2_project2_folder
|
|
...
|
|
- integration_tests_folder
|
|
- test data
|
|
- test01_file
|
|
- test02_file
|
|
...
|
|
|
|
Also it is possible that some semantically coherent components (or 1 big component) would be in its own project or project folder
|
|
Could be common layer or project consisting of all the interfaces (for C# or Java), or each interface in each component's folder (python) - depending on the language common conventions
|
|
|
|
## Notes
|
|
- Follow SOLID principles
|
|
- Follow KISS principle. Dumb code - smart data.
|
|
- Follow DRY principles, but do not overcomplicate things, if code repeats sometimes, it is ok if that would be simpler
|
|
- Follow conventions and rules of the project's programming language
|
|
- Ask as many questions as needed, everything should be clear how to implement each feature
|