Files

Paul O'Reilly e0f8e6471c Add best-practices library, knowledge distillation pipeline settings, and first session log

- best-practices/: 11 topic files + INDEX.md extracted from cluster-bootstrap
  and custom-claude-skills (validation, k8s, helm, ansible, secrets, debugging, etc.)
- settings.yaml: pipeline config (log retention, tracked projects, max logs per run)
- CLAUDE.md: updated with best-practices loading and pipeline documentation
- memory/log/: first session log demonstrating the format

Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>

2026-03-12 23:39:06 +13:00

1.7 KiB

Raw Blame History

Validation & Deployment

Validate Locally, Deploy Once

The single biggest time sink across projects is "deploy first, validate later." Real-world stats from a 9-milestone infrastructure project showed 50-60% of commits were fixes that could have been caught locally.

Always validate before pushing:

helm template for Helm chart values
kustomize build (or kubectl kustomize) for Kustomize apps
kubectl apply --dry-run=server for K8s naming/schema issues
docker run <app> validate-configuration for apps that support it (Authelia, Homepage, etc.)
docker inspect for unfamiliar container images before writing init containers
Lint/typecheck/test for application code

Batch fixes locally, push once. Each push-sync-crash-fix cycle wastes minutes and clutters Git history.

Test the Full Chain Immediately

After wiring up any new service or endpoint, test end-to-end from the user's perspective right away. Don't assume intermediate steps working means the whole chain works.

curl --resolve domain:443:<ip> https://domain to test bypassing DNS/proxy layers
Test from the actual consumer (not same-namespace test pods for network policies)
Test DNS resolution after deploying FQDN-based policies

Pre-Flight Checks

Before starting a deploy or automation phase:

Verify SSH keys are loaded (ssh -T git@<host>)
Confirm environment variables and credentials are available
Check that the target environment is in the expected state
Verify DNS records resolve as expected

Scripts That Change Config Must Self-Verify

After updating and restarting a service, the script should test that the change actually took effect (e.g., curl an API endpoint, check a config value). A "success" message without verification hides failures.

1.7 KiB Raw Blame History