Communitygithub.com

lguidolin/cloud-delivery-aks

À utiliser lors du déploiement sur Kubernetes ou Azure Kubernetes Service (AKS), de la configuration de secrets cloud, de la mise en place de déploiements progressifs/canary, d'environnements éphémères par PR, ou de sondes de santé k8s. Mots-clés — Kubernetes, AKS, Key Vault, Argo Rollouts, Flagger, canary, blue-green, liveness, readiness, PodDisruptionBudget, HPA, rollback, GHCR.

Qu'est-ce que cloud-delivery-aks ?

Cette compétence définit le mécanisme de livraison spécifique à Kubernetes/AKS, avec un accent sur la sécurité des déploiements et une passerelle de vérification. Elle est conçue pour se charger uniquement lorsque la tâche implique k8s/AKS, garantissant que les projets sans déploiement cloud (par exemple, Docker Compose local uniquement) ne voient jamais ce contenu. Les règles de livraison incluent l'utilisation d'images immuables identifiées par leur digest de contenu, promues inchangées à travers les environnements, des environnements éphémères par PR dans leurs propres espaces de noms, un gating de santé Kubernetes avec sondes liveness/readiness/startup, un déploiement progressif (canary/blue-green) via Argo Rollouts ou Flagger avec analyse métrique automatisée, et un rollback de première classe via la redéploiement du digest précédent. Le pipeline CI construit l'image et publie son attestation de provenance, puis la promeut sans modification. Les secrets sont gérés via Azure Key Vault (Secrets Store CSI driver ou sealed secrets), et la configuration est fournie par l'environnement. Les règles de promotion incluent la vérification de l'arbre git pour garantir la reproductibilité, avec des modes de passerelle d'approbation "enforced" (examinateurs requis) ou "advisory" (déclenchement manuel). Les décisions architecturales sont justifiées pour éviter les reconstructions par environnement et assurer la cohérence.

Compatible avec~Claude Code~Codex CLI~Cursor
npx skills add https://github.com/lguidolin/agent-skills/tree/main/skills/cloud-delivery-aks
Voir l'original→Voir toutes les compétences

Demander à votre IA préférée

Ouvre une nouvelle conversation avec cette compétence d'agent déjà préchargée.

OpenAIChatGPTClaudeClaudeGeminiGeminiGrokGrokPerplexityPerplexityDeepSeekDeepSeek

Documentation

Cloud Delivery sur AKS

Aperçu

Mécanisme de livraison pour Kubernetes/Azure. Met en œuvre la sécurité de déploiement et la passerelle de vérification sur AKS. Conçu pour être spécifique à la pile — cette compétence ne se charge que lorsqu'une tâche implique k8s/AKS, de sorte que les projets sans déploiement cloud (par exemple, Docker Compose local uniquement) ne voient jamais ce contenu.

Règles de livraison

  • Le développement local exécute la pile complète via Docker Compose, une commande, complet — une exigence de première classe.
  • Les images sont construites en CI → GHCR, identifiées par leur digest de contenu, puis promues inchangées de l'aperçu à la préproduction jusqu'à la production. Jamais reconstruites par environnement.
  • Environnements d'aperçu éphémères par PR. Chaque PR déploie dans son propre espace de noms isolé sur AKS pour examen, détruit lors de la fusion/fermeture. Le bac d'intégration ; peu coûteux à créer et à détruire.
  • Gating de santé Kubernetes. Chaque charge de travail définit des sondes liveness, readiness et startup (câblées aux points de terminaison dans observability-and-slos), une stratégie de mise à jour progressive avec maxUnavailable/maxSurge bornés, et un PodDisruptionBudget. Utilisez un HPA pour la charge.
  • Livraison progressive vers la production. Canary ou blue-green via Argo Rollouts / Flagger avec analyse métrique automatisée liée aux SLOs ; un canary échoué s'annule automatiquement.
  • Le rollback est de première classe et répété. Les images immuables adressées par digest rendent le rollback un redéploiement du digest précédemment bon (kubectl rollout undo / annuler le déploiement). Vérifié avant que les modifications risquées ne soient livrées.
  • Les migrations sont une étape de pipeline séparée et ordonnée, sûre pour l'extension (voir zero-downtime-migrations), exécutée avant le code qui en dépend — jamais regroupé dans le pod qui a besoin du nouveau schéma.
  • La CI est la passerelle : lint, vérification de type, vérifications de contrat, tests, scans de sécurité s'exécutent sur chaque modification, et bloquent la fusion en mode enforced. La CI construit également l'image et publie son attestation de provenance, puis promeut ce digest inchangé.
  • Parité dev/prod et configuration depuis l'environnement. Secrets depuis Azure Key Vault (via Secrets Store CSI driver ou sealed secrets) — jamais dans les images ou les .env commités. Ports/config depuis l'environnement. Les outils de dev uniquement (pgTAP, exécuteurs de tests) ne sont jamais livrés dans les images de production.

Le Pipeline

NiveauDéclencheurEnvironnementDigest
aperçuPR ouverte / synchronisationns éphémère preview-<app>-pr-<N>construit ici, étiqueté sha-<pr-head>
stagingfusion sur mainns persistant stagingre-étiquetage du digest d'aperçu comme sha-<merge>
productionpublication de version + approbationns productiondigest du parent du commit de version

Pourquoi le commit parent. Le commit de version de release-please ne modifie que CHANGELOG.md et le manifeste, donc son arbre n'est jamais celui que staging a fait tremper — tout ce que l'aperçu a construit pour la PR de version elle-même n'a jamais été promu au-delà de l'aperçu. Son parent est la dernière fusion de fonctionnalité, qui est exactement ce que staging a validé, tant que release-please maintient sa branche de version à la pointe de main (son comportement par défaut). Dériver le digest de git plutôt que de l'état du cluster en direct maintient la promotion reproductible.

Sécurité du re-étiquetage. La fusion squash produit un SHA de commit différent et, si main a bougé pendant que la PR était ouverte, un arbre différent. Deux gardes :

  • Exiger "branches à jour avant la fusion" — un sous-ensemble de la règle des vérifications de statut requises — de sorte que l'arbre squash soit égal à l'arbre tête de PR par construction. Cette garde nécessite la protection de branche, donc elle n'existe qu'en mode enforced ; un projet en mode advisory a la comparaison d'arbre ci-dessous comme seule garde, et doit s'attendre à ce que le chemin de reconstruction soit routinier plutôt qu'exceptionnel.
  • Vérifier plutôt que supposer : comparer git rev-parse <merge>^{tree} par rapport à l'arbre tête de PR. Égaux → re-étiqueter. Inégaux → reconstruire au SHA de fusion. Ce n'est pas la reconstruction par environnement que les Règles de livraison interdisent : un arbre inégal signifie que le contenu lui-même diffère de ce que l'aperçu a validé, donc il n'y a aucun artefact à promouvoir réutilisable — et l'image reconstruite entre dans staging en tant que nouveau candidat plutôt qu'en tant que promotion. Notez ce qui est abandonné lorsque ce chemin est emprunté : cette image n'a jamais été examinée dans un environnement d'aperçu, donc "l'image livrée est l'image examinée" ne tient pas pour elle. Staging est alors sa première validation, pas sa seconde.

Le re-étiquetage est une opération de pointeur — pas de reconstruction, pas de pull :

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

L'attestation reste liée au SHA tête de PR, donc enregistrer le mappage tête→fusion dans l'enregistrement de déploiement ; la configuration de l'image ne peut pas être modifiée sans reconstruction.

La passerelle d'approbation — une propriété, deux mécanismes :

ModeMécanisme
enforcedEnvironnement GitHub production avec examinateurs requis
advisoryUn job workflow_dispatch de promotion ; l'exécuter est la décision

Référence rapide

PréoccupationMécanisme
SecretsKey Vault → CSI driver ; pivotés ; jamais dans l'image
Santésondes liveness + readiness + startup ; readiness vérifie les vraies dépendances
Déploiement sûrcanary/blue-green, contrôlé par SLO, annulation automatique en cas d'échec
Rollbackredéploiement du digest précédemment bon ; répété avant les livraisons risquées
Environnement par PRespace de noms isolé, détruit lors de la fusion
Schémaétape séparée ordonnée, sûre pour l'extension, avant le code
PromotionRe-étiqueter le digest ; jamais reconstruire par environnement
ApprobationExaminateurs d'environnement (enforced) ou envoi manuel (advisory)

Pourquoi c'est isolé : tous les spécificités Azure/k8s vivent ici derrière un déclencheur spécifique à la pile. Un projet local uniquement ou sur un autre cloud substitue sa propre compétence de livraison ; les principes (artefact immuable, déploiement réversible + progressif, migrations découplées) proviennent de resilience-and-deploy-safety.

Raisonnement complet : Article XIX de la constitution, regroupé dans 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 associés

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