Add CI workflow

.github/workflows/ci.yml

@@ -0,0 +1,33 @@
+name: CI Pipeline
+
+on:
+  push:
+    branches:
+      - main
+      - devops-task
+  pull_request:
+    branches:
+      - main
+
+jobs:
+  build:
+    runs-on: ubuntu-latest
+
+    steps:
+      - name: Checkout repository
+        uses: actions/checkout@v4
+
+      - name: Setup Python
+        uses: actions/setup-python@v5
+        with:
+          python-version: '3.11'
+
+      - name: Install dependencies (vote app)
+        run: |
+          cd vote
+          pip install -r requirements.txt
+
+      - name: Run simple test
+        run: |
+          cd vote
+          python3 -m py_compile app.py

README.md

@@ -63,3 +63,32 @@ The voting application only accepts one vote per client browser. It does not reg
 This isn't an example of a properly architected perfectly designed distributed app... it's just a simple
 example of the various types of pieces and languages you might see (queues, persistent data, etc), and how to
 deal with them in Docker at a basic level.
+
+# For task-1 (CI/CD and Version Control)
+For CI/CD, i use GitHub actions because it is tightly integrated with GitHub repositories and its easy to configure. The pipeline is triggered on push and pull request events to the main branch. It will perfoms basic checks such as installing dependencies and running a simple validation that will command to ensure the application code does not contain syntax errors
+
+# For task-2 (containerization):
+This application is fully containerized using Docker. Each service: vote, result, worker has its own Dockerfile.
+
+To ensure minimal image size and follow Docker best practices:
+- Slim base images are used: node:18-slim, postgres:15-alpine
+- Multi-stage build are implemented for the .NET worker service to separate build-time & runtime dependencies
+- Package manager cache are straight cleaned after installation to reduce image size
+- Only required runtime files are included in the final images
+
+The application can be run locally using Docker Compose with a single command:
+docker compose up --build
+
+# For task-3: Infrastructure as Code (IaC)
+This project uses Ansible to demonstrate IaC principles.
+A simple ansible playbook is provided to automate envrionment checks on a local machine.
+- inventory.ini = to defines the target host, which in this project i only use localhost
+- playbook.yml = contains automated tasks in Ansible version to verify Docker installation
+
+# For task-4: Monitoring & Logging
+- i choose prometheus for metrics collection because its wide ecosystem and strong docker support, while Grafana is used for visualization and dashboards. 
+
+# Improvements with More Time
+- i will add automated test cases (unit and integration test) to the CI pipeline
+- also deploy the application to a cloud environment using terraform
+- also add authentication and authorization to application

ansible/inventory.ini

@@ -0,0 +1,2 @@
+[app]
+localhost ansible_connection=local

ansible/playbook.yml

@@ -0,0 +1,28 @@
+- name: Setup environment for Example Voting App
+  hosts: app
+  become: true
+
+  tasks:
+    - name: Ensure required packages are installed
+      apt:
+        name:
+          - docker.io
+          - docker-compose
+        state: present
+        update_cache: yes
+
+    - name: Ensure Docker service is running
+      service:
+        name: docker
+        state: started
+        enabled: true
+
+    - name: Pull application images
+      command: docker compose pull
+      args:
+        chdir: /opt/example-voting-app
+
+    - name: Run application with Docker Compose
+      command: docker compose up -d
+      args:
+        chdir: /opt/example-voting-app

result/monitoring_plan.md

@@ -0,0 +1,29 @@
+# Monitoring Plan - for Example Voting App
+
+Tools
+- Prometheus for collecting metrics
+- Grafana for visualization and dashboards
+- Alertmanager for alert notifications
+- Docker metrics via cAdvisor
+
+Metrics to Monitor
+- CPU and memory usage per container
+- Container uptime and restart count
+- HTTP request rate and response time
+- Error rate (4xx or 5xx)
+- Redis and PostgreSQL availability
+
+Alerting Strategy
+- Alert if CPU usage > 80% for more than 5 minutes
+- Alert if any container is down
+- Alert if application endpoints are not reachable
+- Alert if error rate exceeds defined threshold
+
+Example Prometheus Configuration (in Pseudocode):
+- alert: HighCPUUsage
+  expr: cpu_usage > 80
+  for: 5m
+  labels:
+    severity: warning
+  annotations:
+    description: CPU usage is above 80%