Communitygithub.com

lguidolin/cloud-delivery-aks

Use quando for necessário implantar no Kubernetes ou Azure Kubernetes Service (AKS), configurar segredos na nuvem, configurar rollout progressivo/canário, ambientes efêmeros por PR ou probes de saúde do k8s. Palavras-chave: Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canário, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

O que é cloud-delivery-aks?

Este skill implementa um mecanismo de entrega robusto e seguro para Kubernetes no Azure (AKS), seguindo práticas de deploy progressivo, rollback imutável e geração de ambientes efêmeros por Pull Request. Ele é ativado apenas quando o contexto envolve Kubernetes/AKS, garantindo que projetos locais (como Docker Compose) nunca vejam este conteúdo. As principais características incluem: imagens imutáveis identificadas por digest de conteúdo, promoção de imagens sem reconstrução entre ambientes (preview, staging, produção), canário ou blue-green com análise automatizada de SLOs via Argo Rollouts/Flagger e rollback automatizado. O skill também lida com segredos do Azure Key Vault (via Secrets Store CSI driver), probes de saúde (liveness, readiness, startup), PodDisruptionBudget, HPA, e uma pipeline de CI que executa lint, typecheck, testes e scans de segurança, publicando a imagem com atestado de proveniência. A entrega é controlada por um gate de aprovação (revisores obrigatórios no ambiente 'production' para modo 'enforced', ou dispatch manual para modo 'advisory'). Migrações de banco de dados são tratadas como uma etapa separada e ordenada, executada antes do código que as utiliza, garantindo zero downtime. O skill enfatiza a paridade entre dev e produção, com configurações provenientes do ambiente e ferramentas de dev nunca empacotadas em imagens de produção.

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

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentação

Entrega na Nuvem no AKS

Visão Geral

O mecanismo de entrega para Kubernetes/Azure. Implementa segurança de deploy e o portão de verificação no AKS. Específico por stack por design — este skill só é carregado quando uma tarefa envolve k8s/AKS, então projetos sem deploy em nuvem (por exemplo, Docker Compose apenas local) nunca veem este conteúdo.

Regras de Entrega

  • Desenvolvimento local executa o stack completo via Docker Compose, um comando, abrangente — um requisito de primeira classe.
  • As imagens são construídas na CI → GHCR, identificadas por digest de conteúdo, e então promovidas inalteradas de preview → staging → produção. Nunca reconstruídas por ambiente.
  • Ambientes de preview efêmeros por PR. Cada PR é implantado em seu próprio namespace isolado no AKS para revisão, destruído ao fazer merge/fechar. O berço de testes de integração; barato de criar e destruir.
  • Gating de saúde do Kubernetes. Cada workload define probes de liveness, readiness e startup (conectadas aos endpoints em observability-and-slos), uma estratégia de rolling update com maxUnavailable/maxSurge limitados, e um PodDisruptionBudget. Use um HPA para carga.
  • Entrega progressiva para produção. Canário ou blue-green via Argo Rollouts / Flagger com análise de métricas automatizada vinculada a SLOs; um canário que falha aborta automaticamente.
  • Rollback é de primeira classe e ensaiado. Imagens imutáveis e endereçadas por digest tornam o rollback um redeploy do digest anteriormente bom (kubectl rollout undo / abortar o rollout). Verificado antes que mudanças arriscadas sejam enviadas.
  • Migrações são uma etapa separada e ordenada da pipeline, segura para expansão (veja zero-downtime-migrations), executada antes do código que depende delas — nunca agrupada no pod que precisa do novo schema.
  • A CI é o portão: lint, typecheck, verificações de contrato, testes, scans de segurança executados em cada mudança, e bloqueiam o merge no modo enforced. A CI também constrói a imagem e publica seu atestado de proveniência, e promove esse digest inalterado.
  • Paridade dev/prod e configuração a partir do ambiente. Segredos do Azure Key Vault (via Secrets Store CSI driver ou sealed secrets) — nunca em imagens ou .env commitados. Portas/config a partir do ambiente. Ferramentas exclusivas de dev (pgTAP, runners de teste) nunca são enviadas em imagens de produção.

A Pipeline

TierGatilhoAmbienteDigest
previewPR aberto / sincronizadons efêmero preview-<app>-pr-<N>construído aqui, tag sha-<pr-head>
stagingmerge na mainns persistente stagingretag do digest de preview como sha-<merge>
produçãorelease publicado + aprovaçãons productiondigest do parent do commit do release

Por que o commit pai. O commit de release do release-please altera apenas CHANGELOG.md e o manifesto, então sua árvore nunca é aquela que staging absorveu — o que o preview construiu para o próprio PR de release nunca foi promovido além do preview. Seu pai é o último merge de feature, que é exatamente o que staging tem validado, desde que o release-please mantenha seu branch de release na ponta da main (seu comportamento padrão). Derivar o digest do git em vez do estado ativo do cluster mantém a promoção reproduzível.

Segurança do retag. Squash-merge produz um SHA de commit diferente e, se a main se moveu enquanto o PR estava aberto, uma árvore diferente. Duas proteções:

  • Exigir que "branches estejam atualizados antes de fazer merge" — um subconjunto da regra de verificações de status obrigatórias — para que a árvore do squash seja igual à árvore head do PR por construção. Esta proteção precisa de proteção de branch, então existe apenas no modo enforced; um projeto no modo advisory tem a comparação de árvore abaixo como sua única proteção, e deve esperar que o caminho de reconstrução seja rotineiro em vez de excepcional.
  • Verificar em vez de assumir: compare git rev-parse <merge>^{tree} com a árvore head do PR. Iguais → retag. Diferentes → reconstruir no SHA do merge. Isso não é a reconstrução por ambiente que as Regras de Entrega proíbem: uma árvore diferente significa que o conteúdo em si difere do que o preview validou, então não há artefato promovível para reutilizar — e a imagem reconstruída entra no staging como um candidato novo , não uma promoção. Observe o que é sacrificado quando este caminho é tomado: essa imagem nunca foi revisada em um ambiente de preview, então "a imagem enviada é a imagem revisada" não se aplica a ela. Staging é então sua primeira validação, não a segunda.

O retag é uma operação de ponteiro — sem reconstrução, sem pull:

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

O atestado permanece vinculado ao SHA head do PR, portanto registre o mapeamento head→merge no registro de deploy; a configuração da imagem não pode ser editada sem reconstruir.

O portão de aprovação — uma propriedade, dois mecanismos:

ModoMecanismo
enforcedAmbiente GitHub production com revisores obrigatórios
advisoryUm job workflow_dispatch promote; executá-lo é a decisão

Referência Rápida

AssuntoMecanismo
SegredosKey Vault → driver CSI; rotacionados; nunca na imagem
Saúdeprobes liveness + readiness + startup; readiness verifica dependências reais
Rollout segurocanário/blue-green, gate por SLO, aborto automático em falha
Rollbackredeploy do digest anteriormente bom; ensaiado antes de envios arriscados
Ambiente por PRnamespace isolado, destruído no merge
Schemaetapa separada ordenada, segura para expansão, antes do código
PromoçãoRetag do digest; nunca reconstruir por ambiente
AprovaçãoRevisores de ambiente (enforced) ou dispatch manual (advisory)

Por que isso é isolado: todos os específicos do Azure/k8s vivem aqui atrás de um gatilho específico do stack. Um projeto local-only ou de nuvem diferente substitui seu próprio skill de entrega; os princípios (artefato imutável, deploy reversível + progressivo, migrações desacopladas) vêm de resilience-and-deploy-safety.

Raciocínio completo: Artigo XIX da constituição, agrupado em 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.

Habilidades Relacionadas

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