CSC-519-PROJECT

Team Members

Name	Unity ID	Role
Bipin Gowda	bvgowda	Infrastructure and Monitoring
Makarand Pundlik	mpundli	Quality Assurance and Security
Michelle Varghese	mmvarghe	Deployment and Release Management

---

Deliverables

All required deliverables are documented below.

Deliverable 1: Pipeline Implementation

• The Project integrated into CI/CD workflow.
• GitHub Actions configured for develop and release branch triggers.
• Automated build, test, and deployment pipeline created.
• Static analysis and security scans run through SonarQube.
• Docker image built and deployed via Ansible to the Dev environment.

Deliverable 2: Use Cases

1. Feature Merge Triggers Automated Dev Pipeline
   Describes CI trigger, build, test, and Dev deployment flow.
2. Feature Enablement via Feature Flags Describes dynamic rollout of new features using configuration flags.

Deliverable 3: Reports and Logs

• Test and linting reports generated on each pipeline run.
• Logs and artifacts uploaded automatically for instructor review.
• Reports shared through email or Slack integration.

Deliverable 4: Deployment Environments

• Dev, Staging, and Production configured through Ansible.
• Inventory files maintain separation of credentials.
• Feature flags controlled in environment configuration.

---

Branching and Triggers

• feature/*: Used for new feature development.
• develop: Integrates completed features.
• release/*: Prepares stable builds for staging.
• main: Production-ready branch.
• hotfix/*: Handles urgent fixes in production.

Each merge into develop triggers an automatic Dev pipeline.
The Release Manager triggers the Staging and Production pipelines manually.

---

Reports and Access

All reports, test summaries, and deployment logs are stored as build artifacts.
Slack or email notifications provide quick visibility into pipeline results.

---

Versioning

Versions follow the format major.minor.patch (for example, 1.0.1).
Each release is tagged on merge to main.
Hotfix versions increment the patch number.

---

Repository Link

This repository hosts the DevOps pipeline for our Project.
All team deliverables and documentation are available here.

---

Byte My Dish

Recipe sharing app built with Node.js and MySQL. You can add recipes, rate them, and search by ingredients..

Running it

First, create a .env file in the root directory. You can copy the example:

# On Windows (PowerShell)
Copy-Item example.env .env

# On Windows (Command Prompt)
copy example.env .env

# On Linux/Mac
cp example.env .env

Or create .env manually with these values (copy from example.env):

DB_HOST=mysql
DB_PORT=3306
DB_USER=root
DB_PASSWORD=recipe_password
DB_NAME=recipe_app
PORT=3000
NODE_ENV=development

Important: All values must be set in your .env file. The application requires these environment variables and will not work without them.

Then just run:

docker-compose up

App should be at http://localhost:3000

To run in the background:

docker-compose up -d

Stop it:

docker-compose down

Running without Docker

If you have MySQL running locally, just set up the .env file with DB_HOST=localhost and run:

npm install
npm run migrate
npm start

API

• GET /api/recipes - List all recipes
• GET /api/recipes/:id - Get a recipe
• POST /api/recipes - Create recipe
• PUT /api/recipes/:id - Update recipe
• DELETE /api/recipes/:id - Delete recipe
• POST /api/ratings - Add rating
• GET /api/search/ingredient/:ingredient - Search recipes by ingredient

Feature Flags

The application uses feature flags to enable/disable features dynamically. Feature flags can be toggled via the admin API endpoints.

Available Feature Flags

• new_ui - Enable new UI design theme (dark launch)
• search_feature - Enable/disable recipe search functionality
• compact_list_view - Enable horizontal compact list layout recipe cards
• helmet - Enable HTTP header hardening via the helmet middleware (mitigates XSS, clickjacking, MIME sniffing)
• api_key_auth - Require an internal API key header (X-API-Key) for critical POST API endpoints

Enabling Feature Flags Example

Enable feature flags using the admin API. Replace HOST with your actual server host (e.g., http://localhost:3000 or http://csc519-164-host.csc.ncsu.edu:3000):

Enable New UI:

curl -X POST http://HOST:3000/api/admin/feature-flags/new_ui/toggle \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Enable Search Feature:

curl -X POST http://HOST:3000/api/admin/feature-flags/search_feature/toggle \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Enable Compact List View:

curl -X POST http://HOST:3000/api/admin/feature-flags/compact_list_view/toggle \
  -H "Content-Type: application/json" \
  -d '{"enabled": true}'

Quick: Enable Helmet and verify it (runtime)

• Enable Helmet via the admin API (no restart required):

curl -X POST http://HOST:3000/api/admin/feature-flags/helmet/toggle \
   -H "Content-Type: application/json" \
   -d '{"enabled": true}'

Disabling Feature Flags

To disable a feature flag, set enabled to false:

curl -X POST http://HOST:3000/api/admin/feature-flags/new_ui/toggle \
  -H "Content-Type: application/json" \
  -d '{"enabled": false}'

Admin API Endpoints

• GET /api/admin/feature-flags - List all feature flags
• GET /api/admin/feature-flags/:name - Get details for a specific feature flag
• POST /api/admin/feature-flags/:name/toggle - Toggle a feature flag (requires enabled boolean in request body)

Environment Variables

Everything goes in .env. All variables are required - the application will not work without them:

• DB_HOST - MySQL host (mysql for Docker, localhost for local development)
• DB_PORT - MySQL port (typically 3306)
• DB_USER - MySQL user (use root for simplicity)
• DB_PASSWORD - MySQL password
• DB_NAME - Database name
• PORT - Application port
• NODE_ENV - development or production

Don't commit .env to git. Copy example.env to .env and update the values as needed.

Troubleshooting

If you get "Access denied" or connection errors:

1. Check your .env file - Make sure all required variables are set:

   • DB_HOST, DB_PORT, DB_USER, DB_PASSWORD, DB_NAME, PORT, NODE_ENV
   • Values must match your MySQL configuration

2. Reset the database (this will delete all data):

   docker-compose down -v
   docker-compose up -d

   The -v flag removes volumes, so the database is recreated with proper permissions.

3. Verify environment variables are loaded:

   • For Docker: Ensure .env file exists in the project root
   • For local: Ensure .env file is in the same directory as package.json

Important stuff about data persistence

The MySQL data is stored in a Docker volume. Your data stays when you:

• Restart containers
• Rebuild the app image
• Run docker-compose down (without -v)

You'll lose data if you:

• Run docker-compose down -v (removes the volume)
• Delete the volume manually
• Change the volume config

Security scanning (Gitleaks)

• CI: runs via gitleaks/gitleaks-action@v2 on release*/security-check, fails on findings, uploads gitleaks-report.json.

• Local: brew install gitleaks then gitleaks detect --source . --no-git --redact --report-format json --report-path gitleaks-report.json (exit 0 = clean).

• Optional Docker: docker run --rm -v "$PWD":/path zricethezav/gitleaks:latest detect --source /path --no-git --redact --report-format json --report-path /path/gitleaks-report.json.

• Dependency audit: npm audit --audit-level=high --json > npm-audit-report.json (exit non-zero on high/critical); view the report for details.

The migrations/init.sql only runs on a fresh database. It won't re-run if data already exists.

Quick backup (using environment variables):

docker exec recipe-app-mysql mysqldump -u ${DB_USER} -p${DB_PASSWORD} ${DB_NAME} > backup.sql

Or if running from host (load .env first):

source .env
docker exec recipe-app-mysql mysqldump -u ${DB_USER} -p${DB_PASSWORD} ${DB_NAME} > backup.sql

Restore:

source .env
docker exec -i recipe-app-mysql mysql -u ${DB_USER} -p${DB_PASSWORD} ${DB_NAME} < backup.sql