---

Overview

This project is divided into three major steps: DevOps, Web Development, and Application Development.

Step 1: DevOps

The DevOps phase lays the groundwork for the Web and Application development phases. The goal is to automate, streamline, and secure development and deployment processes.

Objectives

• Implement CI/CD pipelines to ensure continuous delivery and code quality.
• Dockerize the environments for consistent development and production setups.
• Establish robust security measures to protect sensitive data.

Steps

1. Plan CI/CD Pipelines:

• Design a comprehensive CI/CD pipeline.
• Use GitLab to define stages: build, test, and deploy.
• Dockerize applications for both development and production.

2. Automate Deployment:

• Configure automated deployments with minimal manual intervention.
• Integrate unit tests in the pipeline to maintain code quality.
• Achieve zero-downtime deployments.

3. Set Up GitLab Runners:

• Install and configure runners on a virtual machine or VPS.
• Ensure connectivity with the GitLab server for pipeline execution.

4. Security:

• Ensure no passwords or sensitive data are visible in Git repositories.
• Secure communications and follow best practices for DevOps security.

Deliverables

• Dockerfiles for development and production.
• .gitlab-ci.yml defining the CI/CD pipeline.
• A working pipeline demonstrating build, test, and deployment.
• Documentation covering technologies, architecture, and pipeline setup.

Step 2: Web Development

The web development phase focuses on creating a functional web application and a RESTful API for managing products, users, and sales.

Objectives

• Develop a back office for managers to manage inventory, users, and sales.
• Build a front office that provides a user-friendly interface for navigation.
• Secure communications and implement robust authentication mechanisms.

Steps

1. API Development:

• Create endpoints for managing users, invoices, products, and reports.
• Secure API requests with JWT authentication.
• Integrate with Open Food Facts API for automated product data updates.

2. Back Office:

• Implement CRUD functionalities for stock and user management.
• Provide advanced search and filtering options.
• Visualize key performance indicators (KPIs).

3. Front Office:

• Use a modern framework (e.g., React, Vue) to build an intuitive UI.
• Design routes for users, invoices, products, and reports.

4. Testing and Optimization:

• Write unit tests for critical features (min. 20% coverage).
• Automate tests in the CI pipeline.
• Optimize performance with caching and modular architecture.

Deliverables

• Source code for the web application (API, back office, and front office).
• UML diagrams (class and activity) for architecture and workflows.
• Technical documentation covering design choices, architecture, and data flows.
• Unit test reports visible in the CI/CD pipeline.

Step 3: Application Development

The mobile application enhances the customer experience by simplifying purchasing processes and providing detailed product information.

Objectives

• Build a mobile app with scanning, cart management, and payment functionalities.
• Ensure smooth integration with the API and secure transactions.
• Design an intuitive and visually appealing user interface.

Steps

1. Core Features:

• Implement login and account creation with secure authentication.
• Build a home page showcasing navigation options and recommendations.
• Integrate a barcode scanner for product information retrieval.

2. Cart and Payment:

• Enable real-time cart management and total purchase calculations.
• Integrate the PayPal API for secure payments.

3. Purchase History:

• Provide users access to their transaction history with details.

4. Technical Challenges:

• Optimize camera usage and scanning for low-light conditions.
• Implement robust transaction security with HTTPS and encryption.
• Follow UX/UI best practices for an intuitive design. 5.Testing and Optimization:
• Write unit tests for critical features (min. 20% coverage).
• Automate tests as part of the CI pipeline.
• Use modular architecture to ensure scalability and maintainability.

Deliverables

• Source code for the mobile application.
• UML diagrams (class and activity) for architecture and workflows.
• Technical documentation covering architecture, components, and data flows.
• Unit test reports visible in the CI/CD pipeline.

---

Get Started

Clone the Repo

git clone git@t-dev.epitest.eu:STG_1/T-DEV-701-Devops.git

Setup GitLab Runner on a VPS

Install GitLab Runner

1. Add the official GitLab repository:

curl -L "https://packages.gitlab.com/install/repositories/runner/gitlab-runner/script.deb.sh" | sudo bash

2. Install the latest version of GitLab Runner

sudo apt install gitlab-runner

Add a new Project runners

1. In the Settings tab in GitLab, select CI/CD and Runners
2. Click on the New project runner button
3. Complete the steps and you'll get the runner authentication token, copy it

Register the runner

1. Copy and paste the following command into the VPS command line to register the runner.

sudo gitlab-runner register  
  --url https://<runner_url>
  --token <your_runner_token>

2. Choose the docker executor when prompted by the command line.
3. For the default Docker image, use an image like alpine:latest or docker:stable.
4. (Optional) Manually verify that the runner is available to pick up jobs.

gitlab-runner run

Environment Setup

To configure and run the Trinity project, follow these steps to set up your environment and utilize the provided Makefile commands for streamlined development and production workflows.

Environment Variables

Create a .env file inside the docker folder with the following content:

# Postgres
POSTGRES_USER=postgres
POSTGRES_PASSWORD=postgres
POSTGRES_DB=trinity_db
POSTGRES_HOST=postgres
POSTGRES_PORT=5432

# Adminer
ADMINER_PORT=9000

# API
API_PORT=4000
SPICE=myApplicationWideSecret
JWT_SECRET_KEY=secret
DB_SSLMODE=disable
DB_DSN=host=${POSTGRES_HOST} user=${POSTGRES_USER} password=${POSTGRES_PASSWORD} dbname=${POSTGRES_DB} port=${POSTGRES_PORT} sslmode=${DB_SSLMODE}
STASH_FOOD_API=true
PAYPAL_ID=ABCDEF
PAYPAL_SECRET=ABCDEF
AWS_S3_BUCKET=user-name
AWS_REGION=us-east-1
AWS_CLIENT_KEY=ABCDEF
AWS_SECRET_KEY=ABCDEF

# Client
REACT_API_URL=http://localhost:4000
CLIENT_PORT=80

# Traefik
CERT_EMAIL=your@email.com
API_HOST=api.trinity.example.com
CLIENT_HOST=trinity.example.com

This file configures:

• Postgres: The database credentials and connection settings.
• Adminer: Port for database administration.
• API: API service port and JWT secret key for authentication.
• Client: API base URL and client service port.
• Traefik: Email for SSL certificate registration and hostnames for API and client routing.

Makefile Commands

The project includes a Makefile to simplify common tasks. Below are the available commands:

prod:
	docker compose -p trinity -f ./docker/compose.prod.yml up -d --build
dev:
	docker compose -p trinity -f ./docker/compose.dev.yml up -d --build 
test:
	docker compose -p trinity_test -f ./docker/compose.test.yml --env-file ./docker/.env.test up -d --build
stop:
	docker compose -p trinity down
prune: stop
	docker container prune -f
	docker image prune -a -f
	docker volume prune -f
go: 
	cd api && air
air: go
next:
	cd client && npm run dev

Command Breakdown:

• make prod: Start the production environment using docker/compose.prod.yml.
• make dev: Start the development environment using docker/compose.dev.yml.
• make stop: Stop and remove all running containers for the project.
• make prune: Remove stopped containers, unused images, and volumes.
• make go: Navigate to the api folder and run the Go application with live reloading using air.
• make air: Alias for make go.
• make next: Navigate to the client folder and start the Next.js development server.

Technology Choices: Next.js, Go, GitLab, and Flutter

Our project leverages Next.js, Go, GitLab, and Flutter as the foundational technologies for development. These choices were made to ensure scalability, maintainability, and a seamless user experience across the DevOps, Web, and Application components of the project.

Next.js

Next.js is an excellent choice for the front-end web development because of its server-side rendering (SSR) and static site generation (SSG) capabilities. These features allow us to build a performant and SEO-friendly web application, which is critical for the stock and sales management platform. Additionally, Next.js’s support for TypeScript ensures robust type-checking, improving code quality and maintainability.

Go

Go with the fiber framework was selected for the backend API due to its high performance, simplicity, and scalability. Its lightweight nature and concurrency features make it ideal for handling multiple API requests efficiently, such as those required for product, user, and sales management. The strong community support and availability of Go libraries also simplify tasks like JWT authentication.

GitLab

GitLab provides an integrated CI/CD pipeline and repository management solution, which aligns perfectly with the DevOps methodology. Using GitLab runners, we ensure a seamless automation of building, testing, and deploying the project, maintaining a high level of code quality and reducing deployment cycles. Its robust security features also protect sensitive data and streamline collaboration.

Flutter

For the mobile application, Flutter is a powerful framework that enables the development of cross-platform applications with a single codebase. It ensures a consistent look and feel on both iOS and Android devices while reducing development time. Its rich set of pre-built widgets and native performance capabilities allows us to deliver an intuitive, visually appealing, and responsive app, ideal for enhancing the end-customer shopping experience.

Why These Technologies Fit Our Project

These tools collectively address the needs of our project by focusing on performance, scalability, and usability:

• Next.js ensures a dynamic yet efficient web interface for managers.
• Go guarantees a fast and secure API backend, essential for managing stock and sales.
• GitLab streamlines CI/CD processes, making DevOps implementation more efficient and reliable.
• Flutter simplifies the development of a high-quality mobile application, ensuring customers enjoy a smooth and intuitive experience.

By combining these technologies, our project benefits from a well-rounded, modern tech stack that meets the demands of both internal users (managers) and external customers.

Mobile Design Principles

For the mobile app, we follow a Material 3 design approach with a clean and modern UI. The key design principles include:

• Minimalist Aesthetic:
  • A clean, distraction-free interface ensuring a smooth user experience.
  • Focus on key interactions without unnecessary visual clutter.
• Optimized Interaction Zones:
  • Primary controls (navigation, order validation) positioned at the bottom for easy thumb reach.
  • Action buttons placed on the right-hand side to match natural hand placement.
• Smooth Animations & Transitions:
  • Use of subtle animations to guide user interactions.
  • Consistent transitions between screens for a seamless experience.
• Accessible UI/UX:
  • Proper contrast, font sizes, and touch-friendly components.
  • Support for dark mode and accessibility options.

By leveraging Material 3, the design ensures both visual coherence and usability, improving navigation and interaction efficiency.

Project Architecture

Next.js Architecture

client/
├── package.json
├── tailwind.config.ts
├── tsconfig.json
├── Dockerfile.dev
├── Dockerfile.prod
├── Dockerfile.test
├── artifacts/
│   ├── cypress/
│   ├── mochawesome-report/
│   └── reports/
├── cypress/
│   └── e2e/
│       └── tests.cy.ts
├── public/
│   └── images/
│       └── [image files]
└── src/
    ├── components/
    │   ├── Login/
    │   │   ├── LoginForm.tsx
    │   │   └── LoginForm.cy.tsx
    │   └── [other components folders]
    ├── app/
    │   ├── login/
    │   │   ├── page.tsx
    │   │   └── layout.tsx
    │   └── [other pages folders]
    ├── page.tsx
    ├── layout.tsx
    ├── global.css
    └── page.cy.tsx

Description:

• artifacts/: Contains reports generated by testing tools (Cypress, Mochawesome). Organize reports here for easier access and CI/CD integration.
• cypress/: Houses end-to-end tests, keeping test files separate from components and pages for clarity.
• public/: Stores static assets like images to be served by the application.
• src/: Contains application logic:
  • components/: Modular and reusable UI components with related test files (e.g., LoginForm.tsx and LoginForm.cy.tsx).
  • app/: Next.js app directory, organizing routes into folders with page.tsx and layout.tsx.
  • Global files like global.css for styling and top-level page.tsx/layout.tsx.

Go Fiber API Architecture

api/
├── config/
│   └── database.go
├── controllers/
│   ├── user_controller.go
│   ├── product_controller.go
│   └── [other handlers]
├── docs/
│   ├── swagger.yaml
├── middlewares/
│   ├── auth_middleware.go
│   └── [other middleware]
├── models/
│   ├── user_model.go
│   ├── product_model.go
│   └── [other models]
├── routes/
│   ├── user_route.go
│   ├── product_route.go
│   └── [other routes]
├── tests/
│   ├── main_test.go
│   └── [other test files]
├── utils/
│   ├── hash_password.go
│   ├── jwt.go
│   └── [other utility files]
├── views/
│   ├── user_view.go
│   ├── product_view.go
│   └── [other test files]
├── Dockerfile.dev
├── Dockerfile.prod
├── go.mod
├── go.sum
└── main.go

Description:

• config/: Handles centralized configurations such as database connections (database.go) and environment variables to manage application settings.
• controllers/: Contains logic for processing incoming HTTP requests, interacting with services, and returning appropriate responses. Examples include user_controller.go for user-specific operations and product_controller.go for product-related functionality.
• docs/: Stores API documentation files, such as swagger.yaml, which define the API specification for tools like Swagger.
• middlewares/: Implements request-level functionality like authentication (auth_middleware.go), and other request-level operations.
• models/: Defines the database schema and data representations, such as user_model.go for user entities and product_model.go for products.
• routes/: Maps API endpoints to corresponding controllers, such as user_route.go for user-related routes and product_route.go for product endpoints.
• tests/: Includes test files for unit and integration testing, ensuring API reliability and robustness (e.g., main_test.go for testing the main application flow).
• utils/: Provides utility functions and helpers like password hashing (hash_password.go) and JWT handling (jwt.go).
• views/: Handles the final formatting or structuring of responses sent to the client, such as user_view.go for user-related outputs.
• Dockerfiles:
  • Dockerfile.dev: Configurations for the development environment.
  • Dockerfile.prod: Configurations for the production environment.
• Miscellaneous Files:
  • go.mod & go.sum: Dependency management files for the Go application.
  • main.go: Entry point of the application, initializing routes, middleware, and services.

Flutter Mobile App Architecture

mobile/
├── lib/
│   ├── main.dart
│   ├── providers/
│   │   ├── auth_provider.dart
│   │   ├── cart_provider.dart
│   │   ├── product_provider.dart
│   │   ├── invoice_provider.dart
│   │   └── providers.dart
│   ├── requests/
│   │   └── api_service.dart
│   ├── routes/
│   │   └── go_route.dart
│   ├── feature_1/
│   │   ├── screens/
│   │   ├── widgets/
│   │   └── models/
│   │   └── services/
│   │   └── view_models/
│   ├── feature_2/
│   │   ├── screens/
│   │   ├── widgets/
│   │   └── models/
│   │   └── services/
│   │   └── view_models/
│...

Description:

• Feature-Based Modularity: Each feature (authentication, product browsing, checkout, etc.) is self-contained in feature/, making it easier to develop and maintain.
• screens/: Contains the UI components responsible for rendering different pages within a feature.
• widgets/: Reusable UI components that can be shared across multiple screens.
• models/: Data models and entities used within the feature.
• services/: Handles business logic and data fetching for the feature.
• view_models/: Manages the state and logic for the UI components within the feature.
• main.dart: Entry point of the application, initializing the app and routing to different features.
• providers/: Contains state management providers for different features, ensuring data consistency and reactivity.
• providers.dart: Centralizes provider imports and exports for easy access.
• requests/: Manages API calls and service interactions for the application.
• api_service.dart: Centralizes API calls and responses, abstracting network logic from the UI components.
• routes/: Contains route definitions and navigation logic for the application.

Schema Design

classDiagram
    direction TB

    class Users {
        +varchar id
        +varchar firstname
        +varchar lastname
        +varchar address
        +varchar zipcode
        +varchar city
        +varchar email
        +text password
        +json role
        +date created_at
        +date updated_at
    }

    class Carts {
        +varchar id
        +varchar user_id
        +date created_at
        +date updated_at
    }

    class Invoices {
        +varchar id
        +varchar user_id
        +decimal totalPrice
        +boolean paid
        +date created_at
        +date updated_at
    }

    class CartProducts {
        +varchar id
        +varchar? cart_id
        +varchar? invoice_id
        +varchar product_id
        +int quantity
        +decimal paidCost
        +date created_at
        +date updated_at
    }

    class Products {
        +varchar id
        +bigint code
        +int stock
        +decimal price
        +date created_at
        +date updated_at
    }

    %% Relations
    Users "1" --> "1" Carts : has
    Users "1" --> "0..*" Invoices : has
    Carts "1" --> "0..*" CartProducts : contains
    Products "1" --> "1" CartProducts : referenced_in
    Invoices "1" --> "0..*" CartProducts : associated_with

Loading

User ERD

erDiagram
    Users {
        varchar id PK
        varchar firstname
        varchar lastname
        varchar address
        varchar zipcode
        varchar city
        varchar email
        text password
        json role
        date created_at
        date updated_at
    }

    Carts {
        varchar id PK
        varchar user_id FK
        date created_at
        date updated_at
    }

    CartProducts {
        varchar id PK
        varchar cart_id FK
        varchar invoice_id FK
        varchar product_id FK
        int quantity
        decimal paidCost
        date created_at
        date updated_at
    }

    Products {
        varchar id PK
        bigint code
        int stock
        decimal price
        date created_at
        date updated_at
    }

    Invoices {
        varchar id PK
        varchar user_id FK
        decimal totalPrice
        boolean paid
        date created_at
        date updated_at
    }

    %% Relations
    Users ||--o{ Carts : "owns"
    Carts ||--o{ CartProducts : "contains"
    CartProducts }o--|| Products : "references"
    Users ||--o{ Invoices : "generates"
    Invoices ||--o{ CartProducts : "includes"

Loading

Explanation:

1. The user Users own one Carts
2. The Carts contains one or multiple CartProducts
3. Each products is referenced by one CartProducts
4. The Users generate multiple Invoices, and each Invoices includes one or multiple CartProducts

Manager ERD

erDiagram
    Users {
        varchar id PK
        varchar firstname
        varchar lastname
        varchar address
        varchar zipcode
        varchar city
        varchar email
        text password
        json role
        date created_at
        date updated_at
    }

    Products {
        varchar id PK
        bigint code
        int stock
        decimal price
        date created_at
        date updated_at
    }

    Invoices {
        varchar id PK
        varchar user_id FK
        decimal totalPrice
        boolean paid
        date created_at
        date updated_at
    }

    Stats {}
    
    %% Relations
    Users ||..o{ Products : "creates"
    Users ||--o{ Invoices : "views"
    Users ||..o{ Stats : "views"

Loading

Explanation:

1. The manager Users can create and manage multiple Products
2. The manager can view multiple Invoices
3. The manager can access and view multiple Stats

Customer Add To Cart Flow

Customer Purchase Process Flow

Explanation of the Process:

1. Adding to Cart:
   • The client selects products and adds them to the cart.
   • The UI fetches product details from the API, which verifies availability in the database.
2. Checkout:
   • Upon proceeding to checkout, the API creates an invoice in the database and adjusts the product stock.
3. Payment:
   • The client initiates payment via the PurchaseService.
   • The PurchaseService communicates with PayPal to process the transaction.
     • PayPal validates the payment with the bank and sends confirmation back to the PurchaseService.
4. Invoice Update:
   • After successful payment, the UI informs the API, which marks the invoice as "paid" in the database.
5. Final Confirmation:
   • The API sends a final order confirmation to the client.

CI/CD Pipeline Design API & Client

graph TD
  A[Start: Push Code] --> B{Branch?}
  B -->|main| C[Build Server Image]
  B -->|dev| C
  B -->|dev| H[Build Client Image]
  B -->|main| H

  C --> D[Run Server Tests]
  D --> E{Server Tests Passed?}
  E -->|Yes| N{Branch?}
  E -->|No| G[Fail Server Pipeline]

  H --> I[Run Cypress Tests]
  I --> J{Client Tests Passed?}
  J -->|Yes| R{Branch?}
  J -->|No| L[Fail Client Pipeline]

  G --> M[End: Server Pipeline]
  N -->|main| O[Push Server Image]
  N -->|else| M
  O --> M

  L --> Q[End: Client Pipeline]
  R -->|main| S[Push Client Image]
  R -->|else| Q
  S --> Q

Loading

CI/CD Pipeline Design Mobile App

graph TD
  A[Start: Push Code] --> B{Branch?}
  B -->|main| C[Build App Image]
  B -->|dev| C
  C --> D[Save apk artifact]

  C --> E[Run Unit Tests]
  E --> F{Unit Tests Passed?}
  F -->|Yes| N[Success Pipeline]
  F -->|No| G[Fail Pipeline]

  G --> M[End: Pipeline]
  N --> M

Loading