Communitygithub.com

lguidolin/cloud-delivery-aks

Úsalo al desplegar en Kubernetes o Azure Kubernetes Service (AKS), configurar secretos en la nube, configurar despliegues progresivos/canary, entornos efímeros por PR o health probes de k8s. Palabras clave: Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canary, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

¿Qué es cloud-delivery-aks?

Cloud Delivery on AKS es una skill especializada para definir el mecanismo de entrega segura en Kubernetes y Azure Kubernetes Service (AKS). Su propósito principal es implementar un pipeline de despliegue que garantice la inmutabilidad de artefactos, promociones seguras mediante digests de contenido y despliegues progresivos (canary/blue-green) con compuertas de verificación automáticas basadas en SLO. La skill se activa únicamente cuando la tarea involucra k8s/AKS, evitando que contenido de cloud contamine proyectos locales. Soporta entornos efímeros por PR, rollback ensayado, gestión de secretos mediante Azure Key Vault, migraciones de esquema desacopladas y una compuerta de aprobación que puede ser obligatoria (con revisores) o indicativa (disparo manual). Está diseñada para stack Azure/k8s, pero los principios subyacentes provienen de una skill general de resiliencia y seguridad en despliegues.

Compatible con~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/cloud-delivery-aks
Ver original→Ver todas las habilidades

Preguntar en tu IA favorita

Abre un nuevo chat con esta habilidad de agente ya precargada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentación

Cloud Delivery en AKS

Resumen

Mecanismo de entrega para Kubernetes/Azure. Implementa seguridad en despliegues y la compuerta de verificación en AKS. Diseñada específica por stack — esta skill solo se carga cuando la tarea involucra k8s/AKS, de modo que los proyectos sin despliegue cloud (por ejemplo, Docker Compose solo local) nunca ven este contenido.

Reglas de Entrega

  • El desarrollo local ejecuta el stack completo mediante Docker Compose, un solo comando, integral — un requisito de primera clase.
  • Las imágenes se construyen en CI → GHCR, identificadas por su digest de contenido, luego se promocionan sin cambios de preview → staging → producción. Nunca se reconstruyen por entorno.
  • Entornos de vista previa efímeros por PR. Cada PR despliega en su propio namespace aislado en AKS para revisión, eliminado al fusionar/cerrar. Banco de pruebas de integración; baratos de crear y destruir.
  • Compuerta de salud de Kubernetes. Cada carga de trabajo define probes de liveness, readiness y startup (conectadas a los endpoints en observability-and-slos), una estrategia de actualización continua con maxUnavailable/maxSurge acotados, y un PodDisruptionBudget. Usa un HPA para la carga.
  • Entrega progresiva a producción. Canary o blue-green mediante Argo Rollouts / Flagger con análisis automático de métricas vinculado a SLOs; un canary fallido se aborta automáticamente.
  • Rollback es de primera clase y ensayado. Las imágenes inmutables y direccionadas por digest hacen que un rollback sea redeploy del digest previamente bueno (kubectl rollout undo / abortar el rollout). Verificado antes de enviar cambios arriesgados.
  • Las migraciones son un paso de pipeline separado y ordenado, seguro de expansión (ver zero-downtime-migrations), ejecutadas antes del código que depende de ellas — nunca empaquetadas en el pod que necesita el nuevo esquema.
  • CI es la compuerta: lint, typecheck, contratos, pruebas, escaneos de seguridad se ejecutan en cada cambio y bloquean la fusión en modo enforced. CI también construye la imagen y publica su atestación de procedencia, luego promociona ese digest sin cambios.
  • Paridad dev/prod y configuración desde el entorno. Secretos desde Azure Key Vault (a través del driver CSI de Secrets Store o sealed secrets) — nunca en imágenes o .env commit. Puertos/config desde el entorno. Herramientas solo para dev (pgTAP, runners de pruebas) nunca se envían en imágenes de producción.

El Pipeline

NivelDisparadorEntornoDigest
previewPR abierto / sincronizadons efímero preview-<app>-pr-<N>construido aquí, etiquetado sha-<pr-head>
stagingfusión a mainns persistente stagingreetiquetado del digest de preview como sha-<merge>
productionrelease publicado + aprobaciónns productiondigest del padre del commit de release

Por qué el commit padre. El commit de release de release-please solo modifica CHANGELOG.md y el manifest, por lo que su árbol nunca es el que staging absorbió — cualquier cosa que preview construyó para el PR de release en sí nunca fue promocionada más allá de preview. Su padre es la última fusión de funcionalidad, que es exactamente lo que staging ha estado validando, siempre que release-please mantenga su rama de release en la punta de main (su comportamiento por defecto). Derivar el digest de git en lugar del estado del clúster en vivo mantiene la promoción reproducible.

Seguridad del reetiquetado. Squash-merge produce un SHA de commit diferente y, si main se movió mientras el PR estaba abierto, un árbol diferente. Dos salvaguardas:

  • Exigir "ramas actualizadas antes de fusionar" — un subconjunto de la regla de comprobaciones de estado requeridas — de modo que el árbol squash sea igual al árbol head del PR por construcción. Esta guarda necesita protección de rama, por lo que solo existe en modo enforced; un proyecto en modo advisory tiene la comparación de árbol siguiente como su única guarda, y debe esperar que el camino de reconstrucción sea rutinario en lugar de excepcional.
  • Verificar en lugar de asumir: comparar git rev-parse <merge>^{tree} contra el árbol head del PR. Igual → reetiquetar. Desigual → reconstruir en el SHA de fusión. Eso no es la reconstrucción por entorno que las Reglas de Entrega prohíben: un árbol desigual significa que el contenido en sí difiere de lo que preview validó, por lo que no hay artefacto promocionable para reutilizar — y la imagen reconstruida entra en staging como un candidato fresco, no como una promoción. Ten en cuenta lo que se pierde cuando se toma este camino: esa imagen nunca fue revisada en un entorno de vista previa, por lo que "la imagen enviada es la imagen revisada" no se cumple para ella. Staging es entonces su primera validación, no la segunda.

El reetiquetado es una operación de puntero — sin reconstrucción, sin pull:

docker buildx imagetools create -t "$REPO:sha-$MERGE_SHA" "$REPO@sha256:$DIGEST"

La atestación permanece vinculada al SHA head del PR, por lo que registra la asignación head→merge en el registro de despliegue; la configuración de la imagen no se puede editar sin reconstruir.

La compuerta de aprobación — una propiedad, dos mecanismos:

ModoMecanismo
enforcedEntorno de GitHub production con revisores requeridos
advisoryUn trabajo workflow_dispatch de promoción; ejecutarlo es la decisión

Referencia Rápida

AspectoMecanismo
SecretosKey Vault → driver CSI; rotados; nunca en imagen
Saludprobes de liveness + readiness + startup; readiness verifica dependencias reales
Despliegue segurocanary/blue-green, con compuerta de SLO, autoabort en fallo
Rollbackredeploy del digest previamente bueno; ensayado antes de envíos arriesgados
Entorno por PRnamespace aislado, eliminado al fusionar
Esquemapaso ordenado separado, seguro de expansión, antes del código
PromociónReetiquetar el digest; nunca reconstruir por entorno
AprobaciónRevisores de entorno (enforced) o envío manual (advisory)

Por qué esto está aislado: todos los detalles específicos de Azure/k8s viven aquí detrás de un disparador específico de stack. Un proyecto solo local o de otra nube sustituye su propia skill de entrega; los principios (artefacto inmutable, despliegue reversible y progresivo, migraciones desacopladas) provienen de resilience-and-deploy-safety.

Razonamiento completo: Artículo XIX de la constitución, incluido en engineering-constitution/references/engineering-constitution.md.

Individual skills in this repo

This repo contains 18 individual skills — each has its own dedicated page.

lguidolin/change-hygiene-and-code-craft

Use when writing or refactoring code, structuring a commit or PR, or deciding whether to abstract duplication. Symptoms — mixing reorg with logic changes, a PR doing several things at once, a file growing large, the second copy of similar code, or unsure whether to DRY something up.

lguidolin/commit-history-rewrite

Use when an existing repository has messy commit history that needs to conform to conventional commits before adopting release-please, or when intermediate WIP/fixup/merge commits need to be cleaned up.

lguidolin/conventional-commits-and-releases

Use when committing, writing a commit message, opening a PR that will be squash-merged, or configuring automated versioning/changelogs. Keywords — conventional commits, release-please, semver, feat/fix/chore, breaking change, changelog.

lguidolin/defense-in-depth-security

Use when handling untrusted input, secrets, authentication/authorization, or dependencies — or threat-modeling a new surface. Keywords — STRIDE, threat model, least privilege, secrets management, supply chain, dependency scanning, input validation, audit log, defense in depth.

lguidolin/designing-before-building

Use when starting a feature, fixing a non-trivial bug, or about to write implementation code — before any code exists. Symptoms you need this: "this is simple, I'll just code it", reaching for the editor before a design is approved, or an idea that hasn't been turned into a spec and plan.

lguidolin/engineering-constitution

Use when starting work in a project that follows the engineering constitution, orienting to its rules, or deciding which engineering practice applies to a task — spec writing, commits, testing, security, deploys, database, or UI work.

lguidolin/graphql-contract-testing

Use when writing a GraphQL query/mutation that the UI and a test will share, or building route/schema contract or smoke tests. Symptoms — copying a query into a test, a test asserting on query text, schema change that didn't break the UI build, or RLS/permission drift. Keywords — graphql-codegen, typed document, contract test, route smoke test.

lguidolin/init-repo-CI

Use when setting up a new repository with conventional commits, release-please, and CI automation, or when retrofitting an existing repository that lacks automated versioning and PR validation workflows.

lguidolin/interface-craft-and-accessibility

Use when building or styling UI — components, layouts, forms, design tokens — or making accessibility decisions. Keywords — a11y, WCAG, keyboard navigation, focus state, contrast, design system, minimalist UI, component reuse, ARIA, semantic HTML.

lguidolin/merge-gates-and-automation

Use when setting up or changing CI, pre-push hooks, or a task runner, or deciding what must pass before merge. Symptoms — tempted to put authoritative checks only in a local hook, skip CI, bypass with --no-verify, or unsure what gates a merge vs. runs locally.

lguidolin/observability-and-slos

Use when adding logging, metrics, tracing, health checks, SLOs, or alerting — or when building a service surface that needs to be operable and debuggable. Keywords — structured logs, OpenTelemetry, correlation id, RED metrics, liveness, readiness, SLI, SLO, error budget, alerting.

lguidolin/performance-and-scale

Use when working on hot paths, list endpoints, pagination, data-access in loops, or public interfaces/schemas. Symptoms — unbounded queries, N+1 access, no latency budget, optimizing without measuring, or changing an interface many consumers depend on. Keywords — pagination, N+1, Hyrum's Law, performance budget, bundle size.

lguidolin/postgres-postgraphile-rls-and-sql

Use when writing PostgreSQL, PostGraphile config, Row-Level Security policies, SQL schema files, or working on the Browser→App→PostGraphile→Postgres data path. Keywords — RLS, SECURITY DEFINER, search_path, pgSettings, grants, roles, GraphQL depth limit, query cost, statement_timeout, SQL file organization.

lguidolin/recording-decisions

Use when a design or architecture decision has been made and needs to be captured — writing a decision record or ADR, updating a decision index, noting a deferred idea, or superseding a past decision. Keywords — ADR, decision record, rationale, rejected alternatives, dependency index.

lguidolin/resilience-and-deploy-safety

Use when planning a deploy, designing a rollback, or responding to an incident or writing a postmortem. Keywords — deploy safety, rollback, immutable artifact, progressive delivery, canary, blast radius, incident response, blameless postmortem, error budget.

lguidolin/ship-it

Use when the user wants to ship work — push, PR, archive decision records, merge, and clean up. Handles the full lifecycle from committing final changes through post-merge cleanup including converting specs/plans to compact decision records.

lguidolin/tests-as-a-control

Use when writing or modifying tests, when a test breaks during a refactor, or when testing permission/role rules. Symptoms — tempted to edit a test to make it pass, testing only the happy path, a deny-test that started passing, flaky tests, or unsure what to assert.

lguidolin/zero-downtime-migrations

Use when changing a database schema where data must survive the change — adding/removing/renaming columns, constraints, indexes, or backfilling. Symptoms — a destructive migration bundled with a code deploy, a NOT NULL column with a backfill, a table-locking UPDATE, or a rename. Keywords — expand/contract, parallel change, backfill, NOT VALID, CREATE INDEX CONCURRENTLY, graphile-migrate.

Skills relacionados

steipete/sag

ElevenLabs text-to-speech with mac-style say UX.

community

steipete/oracle

Oracle CLI second-model review/debug/refactor/design with selected files, dry-run token checks, API or browser engine.

community

steipete/peekaboo

Capture and automate macOS UI with the Peekaboo CLI.

community

mattpocock/design-an-interface

Generate multiple radically different interface designs for a module using parallel sub-agents. Use when user wants to design an API, explore interface options, compare module shapes, or mentions "design it twice".

community

mattpocock/prototype

Build a throwaway prototype to flesh out a design — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route.

community

mattpocock/grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

community