Please Please Dont Ask For Stuff On Friday Afternoon

PleasePlease Dont Ask For Stuff On Friday Afternoon## INTRODUCTION

If you’ve ever spent a Friday afternoon fielding a barrage of “Can we push this change now?” messages, you know the sinking feeling that comes with a half‑finished deployment, a bloated inbox, and a team that’s already mentally checking out for the weekend. In homelab and self‑hosted environments, where resources are limited and the operator often wears multiple hats, the timing of requests can make the difference between a smooth rollout and a night‑long firefight.

This guide tackles a simple yet powerful practice: don’t ask for infrastructure changes, ticket approvals, or deployment approvals on Friday afternoons. We’ll explore why this rule matters, how it ties into broader DevOps principles such as change management, automation, and observability, and how you can embed it into a self‑hosted ticketing or workflow system.

By the end of this article you will:

• Understand the historical context of Friday‑afternoon change aversion and its impact on system stability.
• Learn how to set up a lightweight, open‑source ticketing platform that enforces process discipline. * Walk through a complete installation and configuration of the platform using Docker, with clear explanations of each step.
• Discover configuration tweaks, security hardening, and performance optimizations that keep your homelab resilient.
• Gain practical knowledge of day‑to‑day operations, troubleshooting, and future‑proofing strategies. Whether you’re running a personal lab, a small office server, or a modest production‑grade homelab, the concepts covered here will help you protect your weekend sanity while maintaining a reliable, automated infrastructure.

---

UNDERSTANDING THE TOPIC

What is “Ask For Stuff On Friday Afternoon”

In many organizations, a “ticket” represents a formal request for change — whether it’s a new service, a configuration tweak, or a patch. The phrase “Ask For Stuff On Friday Afternoon” has become shorthand for the anti‑pattern of submitting these requests when the workweek is winding down, often leading to:

• Delayed approvals because senior reviewers are offline.
• Unplanned deployments that bypass standard testing pipelines.
• Increased risk of human error due to rushed reviews.

The underlying technology that manages these requests is typically a ticketing or change‑management system. Popular options include Jira Service Management, ServiceNow, and open‑source alternatives like Redmine, OpenProject, and Taiga. These tools provide a structured workflow for creating, reviewing, and closing tickets, often integrating with version‑control systems, CI/CD pipelines, and monitoring stacks.

History and Development

Ticket‑based workflows emerged from early issue‑tracking systems in the 1990s, evolving from simple bug logs to comprehensive change‑management platforms. With the rise of DevOps, the ticketing system became a central hub for infrastructure as code (IaC), continuous integration (CI), and continuous delivery (CD). Open‑source projects like Redmine (released in 2006) offered a self‑hosted, extensible foundation that could be tailored to specific operational needs, making it ideal for homelab enthusiasts who want full control over their data and processes.

Key Features and Capabilities * Workflow Customization – Define custom states, transitions, and permission schemes.

• Integration Hooks – Connect to Git, Jenkins, GitLab CI, or any webhook‑compatible pipeline.
• Role‑Based Access Control (RBAC) – Granular permissions for operators, reviewers, and administrators.
• Notifications & Escalations – Email, Slack, or Mattermost alerts when a ticket reaches a certain status. * Reporting & Analytics – Dashboards that surface cycle time, bottleneck frequencies, and change volume.

Pros and Cons | Pros | Cons |

|——|——| | Full data ownership – no SaaS vendor lock‑in | Requires maintenance of the hosting environment | | Extensible via plugins and APIs | Initial setup can be non‑trivial for newcomers | | Cost‑effective for small teams | UI may feel dated compared to commercial products | | Aligns with DevOps culture of transparency | Needs proper process discipline to be effective |

Use Cases and Scenarios

• Homelab Change Management – Prevent a Friday‑afternoon request from causing an untested kernel upgrade.
• Self‑Hosted CI/CD Gatekeeping – Use ticket status to automatically trigger pipelines only after approval.
• Incident Post‑Mortem Tracking – Capture root‑cause tickets that arise from weekend outages.

Current State and Future Trends

Modern ticketing platforms are increasingly integrating AI‑driven triage, chat‑ops interactions, and policy‑as‑code enforcement. However, the core principle remains: process discipline beats speed when it comes to production‑grade changes. For homelab operators, the trend is toward lightweight, containerized deployments that can be version‑controlled alongside infrastructure code.

Comparison to Alternatives

Platform	License	Primary Strength	Typical Deployment
Redmine	GPL‑2.0	Highly plugin‑friendly, Ruby on Rails	Docker, VM, or bare‑metal
OpenProject	GPL‑2.0	Rich project management features	Docker, Kubernetes
Taiga	AGPL‑3.0	Modern UI, agile boards	Docker, Heroku
Jira Service Management	Proprietary	Enterprise‑grade workflow	SaaS (not self‑hosted)

For a self‑contained homelab, Redmine offers a balanced mix of flexibility and ease of deployment, making it a practical choice for illustrating the “don’t ask on Friday” workflow.

---

PREREQUISITES

System Requirements

Component	Minimum	Recommended
CPU	2 vCPU	4 vCPU
RAM	2 GB	4 GB
Disk	10 GB SSD	20 GB SSD
OS	Ubuntu 22.04 LTS	Debian 12 or Ubuntu 24.04 LTS
Docker Engine	24.0.x	Latest stable release
Docker Compose	2.20.x	Latest stable release

Required Software

• Docker – Provides container runtime for Redmine and its dependencies.
• Docker Compose – Orchestrates multi‑container setup (Redmine, PostgreSQL, Redis).
• Git – Optional, for pulling custom themes or plugins.
• SSL Termination – Use a reverse proxy (e.g., Nginx) with Let’s Encrypt for HTTPS.

Network and Security Considerations

• Open only ports 80 and 443 to the public; internal services (PostgreSQL, Redis) should stay on a private network.
• Generate strong secret keys for PostgreSQL (POSTGRES_PASSWORD) and Redmine (SECRET_KEY_BASE).
• Consider enabling AppArmor or SELinux profiles for Docker containers to limit privilege escalation.

User Permissions

• Create a non‑root user (e.g., devops) that owns the Docker socket (/var/run/docker.sock).
• Ensure the user has sudo rights only for Docker commands, not for system‑wide administration. ### Pre‑Installation Checklist

1. Verify Docker Engine is installed and running (docker version).
2. Pull the latest Redmine Docker image (docker pull redmine:latest).
3. Create a dedicated directory for persistent data (/opt/redmine/data).
4. Generate secret values for environment variables.
5. Draft a basic Nginx reverse‑proxy configuration (optional but recommended).

---

INSTALLATION & SETUP

Below is a step‑by‑step guide to deploying Redmine in a Docker‑based homelab, complete with environment‑variable explanations and verification checkpoints.

1. Create a Docker‑Compose File

version: '3.8'

services:
  db:
    image: postgres:15-alpine
    container_name: $CONTAINER_NAMES_db
    restart: unless-stopped
    environment:
      POSTGRES_DB: redmine_production
      POSTGRES_USER: redmine_user
      POSTGRES_PASSWORD: $POSTGRES_PASSWORD
    volumes:
      - $CONTAINER_ID:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U redmine_user -d redmine_production"]
      interval: 30s
      timeout: 5s
      retries: 5

  redmine:
    image: redmine:latest
    container_name: $CONTAINER_NAMES_redmine    restart: unless-stopped
    depends_on:
      db:
        condition: service_healthy
    environment:
      REDMINE_DB_NAME: redmine_production
      REDMINE_DB_USER: redmine_user
      REDMINE_DB_PASSWORD: $POSTGRES_PASSWORD      SECRET_KEY_BASE: $SECRET_KEY_BASE
      RAILS_ENV: production    ports:
      - "8080:3000"
    volumes:
      - $CONTAINER_ID:/var/www/html    ports:
      - "8080:3000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:3000/health_check"]
      interval: 30s
      timeout: 10s
      retries: 5

Explanation of key variables

Variable	Purpose
$CONTAINER_NAMES_db	Unique identifier for the PostgreSQL container; used for volume naming.
$CONTAINER_ID	Persistent volume mount point for database files and Redmine assets.
$POSTGRES_PASSWORD	Secret password for PostgreSQL; store in a .env file outside version control.
$SECRET_KEY_BASE	Rails secret used for session signing; generate via bundle exec rake secret.
$CONTAINER_NAMES_redmine	Identifier for the Redmine container; appears in logs and docker ps output.
$CONTAINER_STATUS	Used by health‑check scripts to verify container state.

2. Generate Secrets

# Generate a strong secret key for Rails
export SECRET_KEY_BASE=$(bundle exec rake secret 2>/dev/null || python3 -c 'import secrets; print(secrets.token_urlsafe(30))')
# Export PostgreSQL password
export POSTGRES_PASSWORD=$(python3 -c 'import secrets