diff --git a/deployment-documentation.md b/deployment-documentation.md
new file mode 100644
index 0000000000000000000000000000000000000000..1ac9e4b0e12b4939fe5c468c5eaff555ce367428
--- /dev/null
+++ b/deployment-documentation.md
@@ -0,0 +1,904 @@
+# 3-Tier Application Deployment: A Complete Guide
+
+## Introduction
+
+This document presents a complete implementation guide for deploying a 3-tier application using modern DevOps practices. It covers the entire deployment pipeline from local development to production-ready GitOps workflows.
+
+The guide is the result of a capstone project that demonstrates proficiency in containerization, Kubernetes orchestration, GitOps, and continuous deployment methodologies. By following this guide, you'll learn how to set up a complete CI/CD pipeline for a React frontend, Node.js backend, and PostgreSQL database application.
+
+### Who This Guide Is For
+
+This guide is designed for:
+- DevOps engineers looking to implement GitOps workflows
+- Developers wanting to learn Kubernetes and container orchestration
+- System administrators transitioning to cloud-native technologies
+- Students completing similar DevOps capstone projects
+
+### Key Technologies Used
+
+- **Containerization**: Docker
+- **Orchestration**: Kubernetes (Minikube)
+- **Package Management**: Helm
+- **CI/CD**: GitLab CI
+- **GitOps**: ArgoCD
+- **Connectivity**: ngrok
+
+### Prerequisites
+
+To follow this guide, you should have:
+- Basic understanding of Docker and containers
+- Familiarity with YAML syntax
+- Basic knowledge of Kubernetes concepts
+- A computer with at least 8GB RAM and 4 CPU cores
+- Git and a GitLab account
+
+Let's get started with setting up our environment and deploying our first application!
+
+## Table of Contents
+1. [Project Overview](#project-overview)
+2. [Architecture](#architecture)
+3. [Local Development Environment](#local-development-environment)
+4. [Kubernetes Setup with Minikube](#kubernetes-setup-with-minikube)
+5. [Application Containerization](#application-containerization)
+6. [Helm Chart Implementation](#helm-chart-implementation)
+7. [GitLab CI/CD Pipeline](#gitlab-cicd-pipeline)
+8. [ArgoCD and GitOps Setup](#argocd-and-gitops-setup)
+9. [Integration with ngrok](#integration-with-ngrok)
+10. [Testing and Validation](#testing-and-validation)
+11. [Troubleshooting Guide](#troubleshooting-guide)
+12. [Additional Resources](#additional-resources)
+
+## Project Overview
+
+This documentation provides a comprehensive guide for implementing a complete DevOps pipeline for a 3-tier task management application. The project demonstrates how to set up a modern CI/CD workflow that leverages GitOps principles to maintain consistent deployments across environments.
+
+### Project Background
+
+The task management application is composed of three distinct tiers:
+1. **Frontend**: A React application that provides the user interface
+2. **Backend**: A Node.js/Express API that handles business logic and data operations
+3. **Database**: A PostgreSQL database that stores task information
+
+Instead of focusing on application development, this project emphasizes the DevOps infrastructure needed to deploy, manage, and maintain the application using best practices.
+
+### Objectives Achieved
+
+- **Local Kubernetes Environment**: Set up and configured Minikube as a local Kubernetes cluster
+- **Application Containerization**: Created Dockerfiles and container images for all application components
+- **Helm Chart Development**: Packaged the application with Helm for simplified deployment and management
+- **CI/CD Pipeline Integration**: Implemented an automated build and deployment pipeline with GitLab CI/CD
+- **GitOps Implementation**: Configured ArgoCD to maintain GitOps workflow for automated deployments
+- **External Access**: Used ngrok to expose the local Kubernetes API server for CI/CD integration
+
+### Deliverables
+
+1. **Working Kubernetes Environment**: A functioning Minikube cluster with all necessary components
+2. **Containerized Application**: Docker images for all application tiers
+3. **Helm Charts**: Complete Helm chart templates for deploying the application
+4. **CI/CD Pipeline**: Configured GitLab CI/CD pipeline for automated builds and deployments
+5. **GitOps Workflow**: ArgoCD setup for automated synchronization with the Git repository
+6. **Documentation**: This comprehensive guide detailing implementation steps and procedures
+
+### Skills Demonstrated
+
+- **Container Orchestration**: Kubernetes cluster management and configuration
+- **Infrastructure as Code**: Defining infrastructure components in version-controlled YAML files
+- **CI/CD Pipelines**: Implementing automated build and deployment processes
+- **GitOps**: Applying declarative infrastructure management with Git as the source of truth
+- **Helm Package Management**: Using Helm to template and package Kubernetes applications
+- **Networking and Connectivity**: Exposing services internally and externally
+
+### How This Documentation Is Organized
+
+This guide follows a logical progression of steps to implement a complete DevOps workflow:
+
+1. First, we set up the local development environment and install necessary tools
+2. Next, we configure the Kubernetes cluster using Minikube
+3. Then, we package the application with Helm charts
+4. Following that, we implement the CI/CD pipeline with GitLab
+5. Next, we configure ArgoCD for GitOps-based deployments
+6. Finally, we connect all components with ngrok and verify the workflow
+
+Each section includes practical commands, configuration examples, and troubleshooting tips to help you replicate this setup for your own projects.
+
+## Architecture
+
+The implementation follows a modern microservices architecture pattern:
+
+```mermaid
+graph TD
+    Developer[Developer] -->|Git Push| GitLab[GitLab Repository]
+    GitLab -->|Trigger| Pipeline[CI/CD Pipeline]
+    Pipeline -->|Build & Push| Registry[Container Registry]
+    GitLab -->|Configuration Changes| ArgoCD[ArgoCD]
+    Registry -->|Pull Images| Kubernetes[Kubernetes Cluster]
+    ArgoCD -->|Apply Changes| Kubernetes
+    Kubernetes -->|Hosts| Frontend[React Frontend]
+    Kubernetes -->|Hosts| Backend[Node.js Backend]
+    Kubernetes -->|Hosts| Database[PostgreSQL Database]
+    Frontend -->|API Calls| Backend
+    Backend -->|Queries| Database
+    ngrok[ngrok] -->|Tunnel| Kubernetes
+```
+
+### Components Breakdown:
+- **Frontend**: React application for task management
+- **Backend**: Node.js/Express API server
+- **Database**: PostgreSQL for data persistence
+- **CI/CD Pipeline**: GitLab CI for automated builds
+- **GitOps**: ArgoCD for declarative deployments
+- **Connectivity**: ngrok for external access
+
+## Local Development Environment
+
+The project uses a standardized development environment to ensure consistency across team members. The application consists of three main components:
+
+- **Frontend**: React application in the `/app/frontend` directory
+- **Backend**: Node.js/Express API in the `/app/backend` directory
+- **Database**: PostgreSQL database initialized with sample data
+
+### Prerequisites
+
+- Docker and Docker Compose
+- Git
+- Node.js and npm (for local development)
+- kubectl CLI
+- Helm CLI
+
+### Directory Structure
+
+```
+task-app-management/
+├── app/
+│   ├── frontend/
+│   ├── backend/
+│   └── database/
+├── docs/
+│   ├── 01-local-setup.md
+│   ├── 02-helm-charts.md
+│   ├── 03-gitlab-ci.md
+│   ├── 04-argocd-setup.md
+│   └── 05-deployment.md
+├── task-app/
+│   ├── charts/
+│   ├── templates/
+│   │   ├── backend-deployment.yaml
+│   │   ├── backend-service.yaml
+│   │   ├── database-deployment.yaml
+│   │   ├── database-init-configmap.yaml
+│   │   ├── database-pvc.yaml
+│   │   ├── database-service.yaml
+│   │   ├── frontend-deployment.yaml
+│   │   └── frontend-service.yaml
+│   ├── .helmignore
+│   ├── Chart.yaml
+│   └── values.yaml
+└── .gitlab-ci.yml
+```
+
+## Kubernetes Setup with Minikube
+
+This project uses Minikube as the local Kubernetes environment. Minikube provides a lightweight, easy-to-use Kubernetes cluster that runs on your local machine.
+
+### Installing Minikube
+
+```bash
+# macOS (using Homebrew)
+brew install minikube
+
+# Windows (using Chocolatey)
+choco install minikube
+
+# Linux
+curl -LO https://storage.googleapis.com/minikube/releases/latest/minikube-linux-amd64
+sudo install minikube-linux-amd64 /usr/local/bin/minikube
+```
+
+### Starting the Cluster
+
+```bash
+# Start Minikube with sufficient resources
+minikube start --cpus=2 --memory=4096mb --driver=docker
+
+# Verify installation
+minikube status
+kubectl cluster-info
+```
+
+### Configuring the Cluster
+
+```bash
+# Enable the ingress addon
+minikube addons enable ingress
+
+# Create the task-app namespace
+kubectl create namespace task-app
+```
+
+Our Minikube cluster is configured with the following specifications:
+- Kubernetes version: v0.27.4
+- Minikube version: v1.32.0
+- Context: minikube
+- Namespace: task-app
+
+## Application Containerization
+
+The application is containerized using Docker, with separate Dockerfiles for each component:
+
+### Frontend Dockerfile
+
+```dockerfile
+FROM node:16-alpine as build
+WORKDIR /app
+COPY package*.json ./
+RUN npm install
+COPY . .
+RUN npm run build
+
+FROM nginx:alpine
+COPY --from=build /app/build /usr/share/nginx/html
+COPY nginx.conf /etc/nginx/conf.d/default.conf
+EXPOSE 3000
+CMD ["nginx", "-g", "daemon off;"]
+```
+
+### Backend Dockerfile
+
+```dockerfile
+FROM node:16-alpine
+WORKDIR /app
+COPY package*.json ./
+RUN npm install
+COPY . .
+EXPOSE 3000
+CMD ["npm", "start"]
+```
+
+### Database
+
+For the database, we use the official PostgreSQL image with a custom initialization script to create the necessary tables and seed data.
+
+## Helm Chart Implementation
+
+The Helm chart is structured to manage all three tiers of the application. The chart includes templates for deployments, services, persistent volume claims, and configuration.
+
+### Chart Structure
+
+```
+task-app/
+├── templates/
+│   ├── backend-deployment.yaml
+│   ├── backend-service.yaml
+│   ├── database-deployment.yaml
+│   ├── database-init-configmap.yaml
+│   ├── database-pvc.yaml
+│   ├── database-service.yaml
+│   ├── frontend-deployment.yaml
+│   └── frontend-service.yaml
+├── Chart.yaml
+└── values.yaml
+```
+
+### Chart.yaml
+
+```yaml
+apiVersion: v2
+name: task-app
+description: Task Management Application
+type: application
+version: 0.1.0
+appVersion: "1.0.0"
+```
+
+### Values Configuration
+
+The `values.yaml` file defines all configurable parameters:
+
+```yaml
+# Global settings
+global:
+  environment: development
+
+# Frontend configuration
+frontend:
+  replicaCount: 1
+  image:
+    repository: frontend
+    tag: latest
+    pullPolicy: Never
+  service:
+    type: ClusterIP
+    port: 3000  # Using React's dev server port
+
+# Backend configuration
+backend:
+  replicaCount: 1
+  image:
+    repository: backend
+    tag: latest
+    pullPolicy: Never
+  service:
+    type: ClusterIP
+    port: 3000
+  env:
+    NODE_ENV: development
+    DB_HOST: database
+    DB_PORT: 5432
+    DB_NAME: taskdb
+    DB_USER: postgres
+    DB_PASSWORD: postgres
+
+# Database configuration
+database:
+  enabled: true
+  image:
+    repository: postgres
+    tag: "13-alpine"
+  service:
+    port: 5432
+  persistence:
+    enabled: true
+    size: 1Gi
+  env:
+    POSTGRES_DB: taskdb
+    POSTGRES_USER: postgres
+    POSTGRES_PASSWORD: postgres
+```
+
+### Key Templates
+
+The Helm chart includes templates for all components:
+
+1. **Frontend Deployment**: Manages the React frontend pods
+2. **Backend Deployment**: Configures the Node.js API with appropriate environment variables
+3. **Database Deployment**: Sets up PostgreSQL with persistent storage
+4. **Services**: Expose each component within the cluster
+5. **ConfigMap**: Initializes the database with schema and sample data
+
+### Installing the Chart
+
+```bash
+# Install or upgrade the chart
+helm upgrade --install my-release task-app/ --namespace task-app --create-namespace
+```
+
+## GitLab CI/CD Pipeline
+
+The CI/CD pipeline is configured in `.gitlab-ci.yml` to automate the build and deployment process.
+
+### Pipeline Stages
+
+```yaml
+stages:
+  - build
+  - deploy
+```
+
+### Build Stage
+
+This stage builds the Docker images for the frontend and backend components:
+
+```yaml
+build-frontend:
+  stage: build
+  tags:
+    - docker-shell
+  script:
+    - docker login -u $CI_REGISTRY_USER -p $CI_REGISTRY_PASSWORD $CI_REGISTRY
+    - cd app/frontend
+    - docker build -t $CI_REGISTRY/$CI_REGISTRY_USER/task-app-management/app/frontend .
+    - docker push $CI_REGISTRY/$CI_REGISTRY_USER/task-app-management/app/frontend
+  only:
+    changes:
+      - app/frontend/**/*
+```
+
+### Deploy Stage
+
+This stage handles the deployment to the Kubernetes cluster:
+
+```yaml
+deploy-dev:
+  stage: deploy
+  script:
+    # Install kubectl and Helm
+    - curl -LO "https://dl.k8s.io/release/v1.28.0/bin/linux/amd64/kubectl"
+    - chmod +x ./kubectl
+    - mv ./kubectl /usr/local/bin/kubectl
+    - curl https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-3 | bash
+    # Set up kubeconfig 
+    - mkdir -p ~/.kube
+    - echo $KUBE_CONFIG | base64 -d > ~/.kube/config
+    - chmod 600 ~/.kube/config
+    # Deploy with Helm
+    - helm upgrade --install my-release task-app/ --namespace task-app --create-namespace --kube-apiserver $KUBE_API_SERVER --kube-insecure-skip-tls-verify
+  environment:
+    name: development
+  only:
+    - develop
+```
+
+### CI/CD Variables
+
+The pipeline uses the following environment variables:
+- `CI_REGISTRY_USER`: GitLab registry username
+- `CI_REGISTRY_PASSWORD`: GitLab registry password
+- `KUBE_CONFIG`: Base64 encoded kubeconfig file
+- `KUBE_API_SERVER`: Kubernetes API server URL
+
+## ArgoCD and GitOps Setup
+
+ArgoCD is used to implement GitOps, ensuring that the Kubernetes deployments stay in sync with the Git repository.
+
+### ArgoCD Installation
+
+```bash
+# Create namespace
+kubectl create namespace argocd
+
+# Install ArgoCD using Helm
+helm repo add argo https://argoproj.github.io/argo-helm
+helm repo update
+helm install argocd argo/argo-cd --namespace argocd --set server.extraArgs={--insecure}
+
+# Access the ArgoCD UI
+kubectl port-forward svc/argocd-server -n argocd 8080:443
+```
+
+### Application Configuration
+
+The ArgoCD application is defined in an Application resource:
+
+```yaml
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: task-app
+  namespace: argocd
+spec:
+  project: default
+  source:
+    repoURL: https://gitlab.stratpoint.dev/seanfredrickcruz/task-app-management.git
+    targetRevision: HEAD
+    path: task-app
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: task-app-management
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+```
+
+This configuration:
+1. Points to our GitLab repository
+2. Targets the `task-app` directory containing our Helm chart
+3. Deploys to the `task-app-management` namespace
+4. Enables automatic synchronization with pruning and self-healing
+
+### Sync Policy
+
+The sync policy is configured for:
+- **Automated sync**: Automatically apply changes when detected in Git
+- **Prune resources**: Remove resources that no longer exist in Git
+- **Self-healing**: Revert manual changes in the cluster
+
+## Integration with ngrok
+
+To connect your local Kubernetes cluster to GitLab CI/CD, we need to make the Kubernetes API server accessible outside your local network. This is where ngrok comes in - it creates secure tunnels to expose local services to the internet.
+
+### Setting Up ngrok for Kubernetes API Access
+
+Follow these step-by-step instructions to configure ngrok and GitLab CI/CD to work together:
+
+1. **Find your Kubernetes API server port**:
+   ```bash
+   kubectl config view | grep server
+   # This will show something like: https://127.0.0.1:8443
+   # Note the port number (8443 in this example)
+   ```
+
+2. **Create an ngrok tunnel**:
+   ```bash
+   # Open a tunnel to your Kubernetes API port
+   ngrok tcp 8443  # Replace 8443 with your actual port
+   ```
+
+3. **Get the ngrok forwarding address**:
+   Look for the "Forwarding" line in the ngrok output:
+   ```
+   Forwarding                    tcp://0.tcp.ap.ngrok.io:12345 -> localhost:8443
+   ```
+   Note the forwarding address and port (0.tcp.ap.ngrok.io:12345 in this example)
+
+4. **Update your kubectl configuration**:
+   ```bash
+   # Open a new terminal and update your cluster's API server address
+   kubectl config set-cluster minikube --server=tcp://0.tcp.ap.ngrok.io:12345
+   ```
+
+5. **Configure GitLab CI/CD variables**:
+   - Go to your GitLab project > Settings > CI/CD > Variables
+   - Update or create the `KUBE_API_SERVER` variable:
+     - Set the value to `https://0.tcp.ap.ngrok.io:12345`
+     - Note: Use `https://` in the GitLab variable, not `tcp://`
+   - Save the changes
+
+6. **Generate and add the kubeconfig**:
+   ```bash
+   # Generate the base64-encoded kubeconfig
+   kubectl config view --raw --minify --flatten | base64 -w 0
+   ```
+   - Copy the entire output string
+   - In GitLab, create or update the `KUBE_CONFIG` variable with this string
+   - Save the changes
+
+7. **Restore local kubectl access**:
+   ```bash
+   # When you need to use kubectl locally again, restore the original server
+   kubectl config set-cluster minikube --server=https://127.0.0.1:8443
+   ```
+
+### Testing the CI/CD Integration
+
+Once ngrok and GitLab are configured, you can test the integration:
+
+1. **Make a code change**:
+   ```bash
+   # Modify any file in your repository
+   echo "// Test change" >> app/frontend/src/App.js
+   
+   # Commit and push
+   git add .
+   git commit -m "Test CI/CD integration"
+   git push origin develop
+   ```
+
+2. **Monitor the pipeline**:
+   - Go to your GitLab project > CI/CD > Pipelines
+   - Watch the pipeline progress through the build and deploy stages
+   - The deploy stage should successfully connect to your local Kubernetes cluster
+
+3. **Verify the deployment**:
+   ```bash
+   # Make sure kubectl is pointing to your local cluster
+   kubectl config set-cluster minikube --server=https://127.0.0.1:8443
+   
+   # Check the deployed pods
+   kubectl get pods -n task-app
+   ```
+
+4. **Verify with ArgoCD**:
+   ```bash
+   # Access the ArgoCD UI
+   kubectl port-forward svc/argocd-server -n argocd 8080:443
+   ```
+   - Open https://localhost:8080 in your browser
+   - Check if the application has synced with the latest changes
+
+### Accessing the Application
+
+To access and test the deployed application:
+
+```bash
+# Port forward the frontend service
+kubectl port-forward svc/my-release-frontend -n task-app 3000:3000
+
+# In another terminal, port forward the backend service
+kubectl port-forward svc/my-release-backend -n task-app 3001:3000
+```
+
+Open your browser and navigate to http://localhost:3000 to use the task management application.
+
+### Understanding the "my-release" Prefix
+
+You'll notice that all deployed resources have a `my-release` prefix. This comes from the Helm release name specified during installation:
+
+```bash
+helm install my-release task-app/ --namespace task-app
+```
+
+This prefix serves several important purposes:
+
+1. **Resource Identification**: It makes it easy to identify which resources belong to a specific Helm release
+2. **Multiple Deployments**: It allows deploying multiple instances of the same chart in the same namespace
+3. **Helm Release Management**: It enables Helm to track and manage the release lifecycle
+
+When Helm templates are rendered, the `.Release.Name` variable is replaced with this prefix, as seen in our templates:
+
+```yaml
+metadata:
+  name: {{ .Release.Name }}-frontend
+```
+
+If you want to use a different prefix, you can change the release name in the `helm install` command:
+
+```bash
+helm install production task-app/ --namespace task-app
+```
+
+This would create resources with names like `production-frontend` instead of `my-release-frontend`.
+
+### Testing GitOps Workflow with ArgoCD
+
+To verify that the GitOps workflow is functioning correctly:
+
+1. **Make a change to your Helm chart**:
+   ```bash
+   # For example, modify a value in values.yaml
+   cd task-app
+   # Edit values.yaml to change frontend.replicaCount from 1 to 2
+   ```
+
+2. **Commit and push the change**:
+   ```bash
+   git add .
+   git commit -m "Increase frontend replicas"
+   git push origin main
+   ```
+
+3. **Observe ArgoCD synchronization**:
+   - Access the ArgoCD UI at https://localhost:8080
+   - Watch as ArgoCD detects the change and applies it
+   - You should see the number of frontend pods increase to 2
+
+4. **Verify the change**:
+   ```bash
+   kubectl get pods -n task-app
+   # You should now see two frontend pods
+   ```
+
+This demonstrates the complete GitOps workflow, where changes to the Git repository automatically trigger updates to the Kubernetes cluster without manual intervention.
+
+## Testing and Validation
+
+A crucial part of the DevOps pipeline is verifying that the deployment works correctly. This section outlines step-by-step procedures to validate each component of the application.
+
+### Deployment Verification Checklist
+
+Before testing the application functionality, verify that all Kubernetes resources are properly deployed:
+
+```bash
+# Check all pods in the task-app namespace
+kubectl get pods -n task-app
+
+# Expected output (all pods should be Running):
+# NAME                                   READY   STATUS    RESTARTS   AGE
+# my-release-backend-6c6dd77898-qhd4v    1/1     Running   0          6d18h
+# my-release-database-9d9b7bb65-t4dw7    1/1     Running   0          6d18h
+# my-release-frontend-59d4bd9df5-q6zz6   1/1     Running   0          20h
+
+# Check services
+kubectl get svc -n task-app
+
+# Expected output:
+# NAME                  TYPE        CLUSTER-IP      EXTERNAL-IP   PORT(S)    AGE
+# my-release-backend    ClusterIP   10.244.0.121    <none>        3000/TCP   6d18h
+# my-release-database   ClusterIP   10.244.0.130    <none>        5432/TCP   6d18h
+# my-release-frontend   ClusterIP   10.244.0.124    <none>        3000/TCP   6d18h
+
+# Check persistent volumes
+kubectl get pv,pvc -n task-app
+
+# Check pod logs for any errors
+kubectl logs my-release-backend-6c6dd77898-qhd4v -n task-app
+kubectl logs my-release-frontend-59d4bd9df5-q6zz6 -n task-app
+```
+
+### Component Health Check
+
+Verify that each component is functioning correctly:
+
+#### Database 
+
+```bash
+# Create a temporary pod to test database connection
+kubectl run pg-client --rm -it --image=postgres:13-alpine --namespace=task-app -- psql -h my-release-database -U postgres -d taskdb
+
+# Inside the psql prompt, check if tables exist
+\dt
+
+# Expected output:
+# Schema |  Name  | Type  |  Owner   
+#--------+--------+-------+----------
+# public | tasks  | table | postgres
+
+# Query sample data
+SELECT * FROM tasks LIMIT 3;
+
+# Exit the psql prompt
+\q
+```
+
+#### Backend API
+
+```bash
+# Port forward the backend service
+kubectl port-forward svc/my-release-backend -n task-app 3001:3000
+
+# In a new terminal, test the API
+curl http://localhost:3001/api/health
+# Expected: {"status":"ok","message":"Server is running"}
+
+curl http://localhost:3001/api/tasks
+# Expected: JSON array of tasks
+```
+
+#### Frontend Application
+
+```bash
+# Port forward the frontend service
+kubectl port-forward svc/my-release-frontend -n task-app 3000:3000
+```
+
+Open your browser and navigate to http://localhost:3000. You should see the task management application interface. Try these operations:
+- View the task list
+- Create a new task
+- Edit an existing task
+- Mark a task as complete
+- Delete a task
+
+### End-to-End CI/CD Test
+
+To validate the complete CI/CD pipeline:
+
+1. **Make a code change**:
+   ```bash
+   # For example, modify the frontend title
+   cd app/frontend/src
+   # Edit App.js to change the title
+   
+   # Commit and push changes
+   git add .
+   git commit -m "Update application title"
+   git push origin develop
+   ```
+
+2. **Monitor the GitLab CI/CD pipeline**:
+   - Go to your GitLab repository
+   - Navigate to CI/CD > Pipelines
+   - Watch the build stage complete successfully
+   - Observe the deploy stage applying changes to Kubernetes
+
+3. **Verify ArgoCD synchronization**:
+   ```bash
+   # Access ArgoCD UI
+   kubectl port-forward svc/argocd-server -n argocd 8080:443
+   ```
+   - Open https://localhost:8080 in your browser
+   - Login with your ArgoCD credentials
+   - Check the task-app application status
+   - Verify that it shows "Synced" and "Healthy"
+   - View the resource tree to confirm all components are updated
+
+4. **Verify changes in the application**:
+   ```bash
+   kubectl port-forward svc/my-release-frontend -n task-app 3000:3000
+   ```
+   - Open http://localhost:3000
+   - Confirm that your changes are visible in the application
+
+### Performance Testing
+
+For basic performance validation:
+
+```bash
+# Install hey (HTTP load generator)
+go get -u github.com/rakyll/hey
+
+# Test backend API performance
+hey -n 100 -c 10 http://localhost:3001/api/tasks
+
+# Check resource usage during load
+kubectl top pods -n task-app
+```
+
+### Security Validation
+
+Perform basic security checks:
+
+```bash
+# Check pod security contexts
+kubectl get pods -n task-app -o jsonpath='{.items[*].spec.securityContext}'
+
+# Check network policies
+kubectl get networkpolicies -n task-app
+
+# Verify that database is not exposed outside the cluster
+kubectl get svc my-release-database -n task-app -o yaml
+```
+
+After completing these validation steps, you can be confident that your deployment is functioning correctly and that the CI/CD pipeline is properly configured for continuous delivery.
+
+## Troubleshooting Guide
+
+### Common Issues and Solutions
+
+#### Pods Not Starting
+
+```bash
+# Check pod status and events
+kubectl describe pod <pod-name> -n task-app
+
+# Check logs
+kubectl logs <pod-name> -n task-app
+```
+
+Common causes:
+- Image pull errors: Check the image repository and tag
+- Resource constraints: Verify Minikube has sufficient resources
+- Config errors: Check environment variables and configurations
+
+#### Database Connection Issues
+
+```bash
+# Check if database pod is running
+kubectl get pods -n task-app | grep database
+
+# Check database logs
+kubectl logs <database-pod> -n task-app
+
+# Check if the service is accessible
+kubectl exec -it <backend-pod> -n task-app -- curl <database-service>:5432
+```
+
+#### ArgoCD Sync Failures
+
+```bash
+# Check application status
+kubectl get applications -n argocd
+
+# Check detailed sync status
+kubectl describe application task-app -n argocd
+
+# Check controller logs
+kubectl logs deployment/argocd-application-controller -n argocd
+```
+
+#### ngrok Connection Issues
+
+- Verify ngrok is running and the tunnel is active
+- Confirm the tunnel URL is correctly set in GitLab CI/CD variables
+- Check firewall settings that might block the ngrok connections
+
+## Additional Resources
+
+- [Kubernetes Documentation](https://kubernetes.io/docs/)
+- [Helm Documentation](https://helm.sh/docs/)
+- [GitLab CI/CD Documentation](https://docs.gitlab.com/ee/ci/)
+- [ArgoCD Documentation](https://argo-cd.readthedocs.io/)
+- [ngrok Documentation](https://ngrok.com/docs/)
+
+## Conclusion
+
+This project successfully implemented a complete DevOps pipeline for a 3-tier application using modern practices and tools. By leveraging Kubernetes, Helm, GitLab CI/CD, and ArgoCD, we've created an automated workflow that enables continuous delivery of our application with minimal manual intervention.
+
+### Key Achievements
+
+1. **Environment Consistency**: Using Helm charts ensures that our application deploys consistently across all environments.
+2. **Automation**: The GitLab CI/CD pipeline automates the build and initial deployment process.
+3. **GitOps Workflow**: ArgoCD maintains the desired state of our application by continuously synchronizing with our Git repository.
+4. **Infrastructure as Code**: All aspects of our infrastructure are defined in code and tracked in version control.
+5. **Local-to-Production Parity**: The setup works consistently from local development through to production.
+
+### Lessons Learned
+
+Throughout this project, several valuable lessons emerged:
+
+1. **Start Simple**: Beginning with a basic deployment and iteratively adding complexity proved more effective than attempting to implement everything at once.
+2. **Containerization Fundamentals**: Properly designed containers with clear separation of concerns make Kubernetes deployments much more manageable.
+3. **GitOps Benefits**: Using Git as the single source of truth streamlined collaboration and simplified rollbacks when issues occurred.
+4. **Infrastructure Testing**: Testing infrastructure changes before applying them prevented many potential issues.
+5. **Documentation Importance**: Maintaining clear documentation throughout the process made troubleshooting and knowledge sharing much easier.
+
+### Future Improvements
+
+While the current implementation satisfies all requirements, several enhancements could be made:
+
+1. **Monitoring and Logging**: Implement ELK or Prometheus/Grafana for comprehensive monitoring.
+2. **Secret Management**: Integrate a dedicated secret management solution like HashiCorp Vault.
+3. **Multi-Environment Support**: Extend the setup to support multiple environments (dev, staging, production).
+4. **Automated Testing**: Add automated tests to the CI/CD pipeline.
+5. **High Availability**: Configure high-availability deployments for production use.
+
+By completing this project, we've demonstrated proficiency in modern DevOps practices and created a solid foundation for future application deployments. The combination of containerization, orchestration, and GitOps provides a robust framework that can be adapted to a wide range of applications and use cases.
diff --git a/task-app-application.yaml b/task-app-application.yaml
new file mode 100644
index 0000000000000000000000000000000000000000..9d4209e4994eff8b086505659e1cb119e9be1624
--- /dev/null
+++ b/task-app-application.yaml
@@ -0,0 +1,28 @@
+apiVersion: argoproj.io/v1alpha1
+kind: Application
+metadata:
+  name: task-app
+  namespace: argocd
+spec:
+  project: default
+  source:
+    repoURL: https://gitlab.stratpoint.dev/seanfredrickcruz/task-app-management.git  # Your GitLab repository
+    targetRevision: HEAD
+    path: task-app  # Path to your Helm chart
+  destination:
+    server: https://kubernetes.default.svc
+    namespace: task-app-management
+  syncPolicy:
+    automated:
+      prune: true
+      selfHeal: true
+
+---
+# ConfigMap for frontend configuration
+apiVersion: v1
+kind: ConfigMap
+metadata:
+  name: frontend-config
+  namespace: task-app
+data:
+  REACT_APP_API_URL: "http://localhost:3001/api"  # Backend API URL
\ No newline at end of file