Week #4 #
Testing and QA #
As part of our testing strategy, we focused initially on implementing unit tests for the service layer of the backend. This decision was made to ensure that the core business logic is thoroughly tested in isolation, without external dependencies like databases or web layers. Unit testing the service layer allows us to catch logical errors early and keep our codebase maintainable and reliable.
At this stage, only unit tests for service and controller parts have been written. In the next steps, we plan to extend test coverage to other layers of the application. For example, integration tests will be added to cover the controller layer and verify the interaction between components and the overall system behavior.
We used JaCoCo to generate a code coverage report, providing visibility into the extent of test coverage and helping us identify untested code areas.
Evidence of test execution #
JaCoCo test coverage report is stored in backend directory after mvn verify task in target/site/jacoco/index.html. Links to the screenshots: Screenshot_1, Screenshot_2, Screenshot_3
CI/CD #
The project uses a complete CI/CD pipeline powered by GitHub Actions. The pipeline includes the following key stages:
Continuous Integration (CI) #
- Docker builds: All Dockerfiles in the repository — both for the machine learning services and the backend — are built and tested to ensure they work correctly.
- Flutter: The Flutter frontend is linted and built as part of the pipeline to catch issues early.
- Linting & static analysis: Code quality checks are applied to ensure clean and maintainable code across all components.
jaCoCo
in target directory in backend part for detection of code coverage by tests
Continuous Deployment (CD) #
- Self-hosted GitHub Actions runners are used to execute deployment jobs.
- These runners automatically deploy the latest versions of the application using docker-compose, based on the branch or environment.
- The deployment includes the backend, ML models, and all related services as defined in the docker-compose.yml.
Environment separation #
- Different environments (e.g., stage and production) are handled via branch-based deployments and environment-specific configurations.
- Secrets and environment variables are managed through GitHub Environments and Actions secrets.
Challenges #
Some of the challenges faced during CI/CD setup included:
- Configuring self-hosted runners with proper systemd services to ensure stability.
- Ensuring consistency across Docker builds and networking in docker-compose.
- Syncing main and stage branches
- Allowing the PR’s to main only from main (resolve it within some CI workflow)
Links to CI/CD configuration files #
- Build Docker images
- Build & linting for flutter
- Checker for PR in main (it is allowed only from stage)
- Deployment by button for STAGE
- Deployment by button for PROD
- Java CI
Staging #
- From now on, a dedicated staging environment has been introduced for pre-production testing.
- It is deployed manually (by button) from the stage branch using the same CI/CD pipeline.
- Staging has its own domain name and infrastructure, isolated from the production environment.
- This allows testing new features, integration, and deployments in a safe and reproducible environment before promoting them to production.
- All services — backend, ML components, and frontend — are deployed via docker-compose on a separate self-hosted runner.
- Environment-specific secrets and configuration are managed independently using GitHub Environments and Actions secrets.
- This separation ensures safer deployments, early detection of integration issues, and a more reliable development lifecycle.
Production #
The production environment has been set up on a dedicated Virtual Dedicated Server (VDS) and swagger for backend is publicly accessible at:
https://capstone.aquaf1na.fun/swagger-ui/index.html#/
This environment is fully separated from staging and represents the live version of the application. It is used for final delivery, testing under real conditions, and demonstration purposes.
Infrastructure and Deployment #
- Each major component (backend, ML services, etc.) is containerized and deployed using docker-compose.
- The production backend is hosted on a separate VDS from the staging environment to ensure isolation, security, and performance.
- Both the staging and production servers are set up with reverse proxies (nginx) that route incoming HTTPS traffic to the appropriate internal services.
- SSL/TLS certificates are configured using Let’s Encrypt, ensuring secure HTTPS connections.
Vibe Check #
The team is functioning well with strong collaboration, all members actively contributing to their assigned areas without major problems
Weekly commitments #
Individual contribution of each participant #
Stepan Vagin:
- Started Qdrant cluster, link to the screenshot provided, since it is needed to use API-key to access dashboard, Screenshot
- Wrote program, that uploaded all fish enteries into the Qdrant, Screenshot
- Build faiss indexing, qwen text embedding, debugged system, build CLI for usage, build Qdrant access for faiss and much more, PR
- Task distribution
Kostya Zimin:
- Realize endpoints with service logic for getting fishes, fish, fishings, fishing. Create new exceptions and solve bugs, issue
- Create Testing structure, add JaCoCo for test coverage checking with automatic generated html file in target directory at backend. Create tests for service logic, issue
Ivan Vasiliev:
- rebuild embeddings (cleaned the input descriptions, used another embedding model) datasets can be found here https://disk.yandex.ru/d/1UGiENnMIG0OSg
- fixed the base model that find relevant fish
- executed experiments with 3 different models and fine-tuned their parameters to achieve the fastest the most accurate model, PR
Kirill Greshnov:
Egor Belozerov:
- Setup stage environment fully, PR
- Configure stage VDS server + setup stage gh runner + configure stage nginx
- Create CI for ensuring that PR to main can be only from STAGE, commited into main, so no pr, Commit
- Introduce java tests into CI pipeline, Link
Damir Sadykov:
- Change the fishing event, PR
- Add real counting of catches
- Fix connection bugs for start / end of event
- Reconstruct the Fishing page
- Add some drafts for future improvement (catches gallery with editing)
Adel Gaznanov:
- Wrote few mock tests, PR
- Fix bugs related to endpoints and openAPI naming, PR_1, PR_2, PR_3
- Add possibility for users to upload photos of caught fish during fishing, PR
Plan for Next Week #
- Write more tests
- Continue connecting backend and frontend
- Integrate ready ml system into the project
- Fixing bugs
- Implementing new features
Confirmation of the code’s operability #
We confirm that the code in the main branch:
- [+] In working condition.
- [+] Run via docker-compose (or another alternative described in the
README.md
).