Report 4. Testing, CI/CD & Deployment Setup #

UrTraining #

Authors: Ildar Rakiev, Makar Dyachenko, Salavat Faizullin, Egor Chernobrovkin, Alexandra Starikova, Ilona Dziurava, Anisya Kochetkova

Date: July 2025

Team Members #

Implemented features #

Visualization:
The user flow diagram can be seen below, the non-implemented features are highlighted in red:

Implemented Features: #

1. Advanced trainer registration #

2. Editing of trainer registration #

3. Training Uploading #

Training uploading:

Training uploading (success case)

4. AI assistants #

• An AI Assistant that pops up in the window when choosing courses.

Commits: AI Assistant implementation

• An AI Assistant that pops up in the window after clicking on the course. The main difference between this assistant is that it has a complete description of the program that the user is watching.

Commits: AI Assistant implementation

CI/CD Pipeline Documentation #

1. Pipeline Overview #

Deployment Targets #

2. Workflow Configuration #

Common Structure #

All workflows share the same trigger pattern: pull request with main branch or push to this branch.

on:
  push:
    branches: [ "main" ]
    paths: [ "service_path/**" ]
  pull_request:
    types: [closed]
    branches: [ "main" ]
    paths: [ "service_path/**" ]

Key Components #

1. Conditional Execution:

   if: |
     github.event_name == 'push' ||
     (github.event_name == 'pull_request' && github.event.pull_request.merged)  
   

2. SSH Deployment:

   uses: appleboy/ssh-action@v1.0.3
   with:
     host: ${{ secrets.SSH_HOST }}
     username: ${{ secrets.SSH_USER }}
     key: ${{ secrets.SSH_KEY }}
   

Here’s a polished version of the third section with clear technical explanations:

3. Deployment Processes #

For Backend and ML Services (Dockerized) #

Each Docker-based service follows this robust deployment sequence:

1. Code Synchronization
   The pipeline first pulls the latest main branch to ensure the server has all recent commits:

   cd ~/UrTraining
   git pull origin main
   

2. Container Management
   Using Docker Compose for deterministic deployments:

   cd service_directory
   docker-compose down            # Graceful shutdown
   docker-compose build --no-cache # Clean rebuild
   docker-compose up -d           # Daemonized startup
   

   Key notes:

   • --no-cache prevents cached layers from causing inconsistencies
   • -d flag runs containers in detached mode

3. Atomic Deployment
   The entire process is wrapped in a flock mutex lock to prevent concurrent deployments:

   flock /tmp/service-deploy.lock -c '...'
   

For Frontend (Static Assets) #

The frontend deployment takes a different approach:

1. Build Process
   Creates production-optimized assets:

   npm install              # Ensures fresh dependencies
   npm run build            # Generates /dist directory
   

2. Atomic File Replacement
   Safely updates live assets without downtime:

   sudo rm -rf /var/www/myfrontend/*     # Clean deploy
   sudo cp -r dist/* /var/www/myfrontend # Atomic copy
   sudo systemctl restart nginx          # Graceful reload
   

Critical Design Aspects:

• All file operations use sudo to ensure proper permissions
• Nginx restart is instantaneous to end-users
• The entire process is logged for audit purposes

4. Critical Features #

Deployment Safety Mechanisms #

1. File Locking:

   flock /tmp/service-deploy.lock -c '...'
   

2. Logging:

   LOG_FILE=~/deploy-service.log
   {
     # Deployment commands
   } >> $LOG_FILE 2>&1
   

Error Handling #

• set -e in scripts fails on first error
• All Docker commands run in sequence with error checking

5. Environment Details #

Server Requirements #

• Docker + Docker Compose installed
• Nginx for frontend
• SSH access configured
• Directory structure:

  ~/UrTraining/
    ├── backend/
    ├── frontend/
    ├── ml/
    │   ├── image2tracker/
    │   └── vector-db/
  

6. Troubleshooting #

Common Issues #

1. SSH Connection Failures:

   ssh -v $SSH_USER@$SSH_HOST
   

2. Docker Build Errors:

   docker system prune -a
   docker-compose build --no-cache
   

Log Locations #

~/deploy-backend.log
~/deploy-vector-db.log
~/deploy-image2tracker.log
/var/log/nginx/error.log

Problems and solutions: #

7. Maintenance #

Secret Rotation #

1. Updated information GitHub Secrets, especially Actions secrets:
   • SSH_HOST
   • SSH_USER
   • SSH_KEY

Update Procedure #

1. Modify workflow files in .github/workflows/
2. Test via PR to non-main branch (trigger PRs)
3. Merge to main for production deployment

CI/CD logs #

Deploy #

Fronted part is deployed HERE.

Backend part is deployed HERE.

ML part is deployed HERE.

Testing #

Unit tests for critical backend logic #

These are unit tests that check the correctness of the database models in our application. General principles of testing:

• Checking the creation of records (whether they are saved correctly in the database)
• Checking the relationships between models (for example, the user_id in the Training Profile)
• Checking default values (for example, is_active=True)
• Checking data types (numbers, strings, lists)

Commit: Unit tests

Integration tests for API endpoints #

API tests check all sorts of things with the API, mainly for the correct nature of the entered data, for example, that the user can register, log in, and delete the user from the database

Commit: API endpoints tests

Basic end-to-end tests for the core user journey #

Tests covering the trainee journey

• Authentication Flow
• Minimum/maximum values, Optional fields, Long text inputs, Empty fields, Country/city validation
• Survey data
• Profile setup
• View workout details

Commit: End-to-end tests

Vibe check #

During the team health check meeting, we aimed to assess our collaboration, communication, and overall team well-being. The discussion revealed several areas for improvement, especially from the online team members. One major concern was the lack of coordination meaning that team members often worked in isolation and contacted only the team lead in case of any problems. There was a shared opinion that the development process lacked transparency, with some features being implemented without others being aware. Team members suggested introducing short update sessions to keep everyone informed and aligned. Another key point was the inconsistency in how pull requests were handled. Some were submitted without titles or descriptions, making it hard for others to review or understand the context. It was agreed that improving PR practices and testing each other’s work would strengthen team dynamics, ensure better code quality, and help everyone feel more included. This health check provided a valuable space for honest feedback and reinforced our commitment to working as a more cohesive and communicative team.

Weekly Progress Report #

Challenges & Solutions #

The most challenging part of this week was setting up the CI/CD pipeline, as none of the team members had prior experience with it. To overcome this, three team members collaborated closely, sharing research, troubleshooting together, and verifying each step of the setup process. This teamwork ensured the pipeline was configured correctly and became a valuable learning experience for everyone involved.

Conclusions & Next Steps #

By the end of Week 4, we had a stable, tested, and deployed version of our application in a staging environment, complete with CI/CD automation. This allows for updates and reliable testing going forward. Additionally, the trainer user flow was successfully implemented.

Next Steps for Week 5 #

• Implement profile pages

  • Implement personal profile pages for user ans trainer.
  • Add functionality for profile editing.

• Feedback Collection:

  • Share the staging app with external testers.
  • Collect structured feedback through forms.

• Feedback Analysis:

  • Document feedback and create actionable issues in the backlog.
  • Prioritize bug fixes and usability improvements.

• Iteration & Refinement:

  • Address top-priority feedback, focusing on UI/UX and error handling.
  • Improve frontend responsiveness and backend robustness.
  • Polish documentation (README, API reference).

• ML Enhancements:

  • Refine model predictions based on validation outcomes.
  • Explore metrics to evaluate prediction quality and fairness.

Week 5 will focus on improving the product based on the the user experience, resolving known bugs, and improving the overall quality and stability of the product in preparation for final presentation and submission.

We confirm that the code in the main branch:

In working condition. Run via docker-compose.