PHP vs Old Tools: What Changed for DevOps Engineers

Old PHP deploy — the "classic" workflow:

1. Developer edits file locally in an editor
2. Opens FTP client (FileZilla) or cPanel File Manager
3. Drags changed files onto the live server
4. Restarts Apache manually (sometimes)
5. Hopes nothing broke
6. If it did — restores from yesterday's backup

Common variations:
- Uploading a zip and extracting it in cPanel
- Editing files directly on the server via cPanel editor
- Sharing database credentials in a chat message
- No staging environment at all

Why the old way broke at scale:

✗ No version history
  "Who changed this file?" → nobody knows.

✗ No rollback
  Incidents took hours to recover.

✗ No consistency
  Different servers had different php.ini.

✗ No audit trail
  Deploys happened with no record.

✗ No tests
  Code went live untested.

✗ No dependency management
  Libraries were copy-pasted between projects.

Transition-era PHP workflow (2010s):

1. Code lives in Git
   → git push origin main

2. Dependencies declared in composer.json
   → composer install --no-dev --optimize-autoloader

3. .env file holds environment secrets
   → APP_ENV=production
     DB_HOST=prod-db.internal

4. Deploy via SSH + script
   → ssh deploy@app-server
     cd /var/www/app && git pull && composer install
     php artisan migrate --force
     systemctl reload php-fpm

5. Rollback = revert the commit and redeploy

First CI pipeline (GitHub Actions example):

name: Deploy PHP

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install PHP & Composer
        uses: shivammathur/setup-php@v2
        with:
          php-version: '8.2'
      - name: Install dependencies
        run: composer install --no-dev --optimize-autoloader
      - name: Run tests
        run: vendor/bin/phpunit
      - name: Deploy via SSH
        run: ./scripts/deploy.sh

Result: every merge to main is tested and deployed
in a repeatable way — no more FTP.

Modern PHP Dockerfile (production-style):

FROM php:8.2-fpm-alpine

# Install system dependencies
RUN apk add --no-cache nginx supervisor

# Install PHP extensions
RUN docker-php-ext-install pdo_mysql opcache

# Copy composer binary
COPY --from=composer:2 /usr/bin/composer /usr/bin/composer

# Copy app code
WORKDIR /var/www/html
COPY composer.json composer.lock ./
RUN composer install --no-dev --optimize-autoloader

COPY . .

# Set proper permissions
RUN chown -R www-data:www-data /var/www/html

EXPOSE 9000
CMD ["php-fpm"]

Kubernetes deployment for PHP (simplified):

apiVersion: apps/v1
kind: Deployment
metadata:
  name: php-app
spec:
  replicas: 3
  selector:
    matchLabels:
      app: php-app
  template:
    metadata:
      labels:
        app: php-app
    spec:
      containers:
      - name: php-app
        image: registry.example.com/php-app:${GIT_SHA}
        ports:
        - containerPort: 9000
        envFrom:
        - secretRef:
            name: php-app-secrets
        readinessProbe:
          tcpSocket:
            port: 9000
        livenessProbe:
          tcpSocket:
            port: 9000

# Deploys are now:
# 1. Build image with new commit SHA
# 2. Push to registry
# 3. Update the image tag
# 4. Kubernetes rolls out new pods — no FTP, no downtime

Old vs modern observability checklist:

OLD WAY:
☐ SSH into server to read error logs
☐ Grep through /var/log/apache2
☐ Ask the team "is the site down?"
☐ No alerts — users report issues
☐ No visibility into slow queries

MODERN DEVOPS:
☐ Structured JSON logs shipped centrally
☐ Logs queryable by request ID
☐ Metrics: request rate, latency, error rate
☐ Distributed traces for slow requests
☐ SLOs defined and alerted on
☐ Auto-rollback on error-rate spike

Deploy readiness tracker (per release):

Release version: ____________________________
Git SHA: ____________________________________

Pre-deploy:
☐ Tests passing in CI
☐ Docker image built and pushed
☐ Migration plan reviewed
☐ Feature flags configured
☐ Rollback image available

Deploy:
☐ Deploy to staging first
☐ Smoke tests pass
☐ Canary at 5% → 25% → 100%
☐ Monitored for 15 minutes

Post-deploy:
☐ Error rate < baseline
☐ Latency < baseline
☐ No alerts triggered
☐ Announce in #deploys channel