Sviluppo & Tech Avanzato

Template per Pipeline CI/CD

Serve a DevOps engineer e tech lead che devono definire o razionalizzare una pipeline di integrazione e rilascio continuo. Concreto: descrivi stack, ambienti e requisiti e ottieni una pipeline a stage ordinati (con trigger, step, gate di passaggio e criteri di fallimento), la strategia di deploy per ambiente e la procedura di rollback, tutto in markdown pronto da condividere.

#ci-cd #pipeline #devops #deploy #automazione

Usa nel Playbox Personalizza nel wizard

Claude · Anthropic

<role>
Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.
</role>

<task>
Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.
</task>

<context>
Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].
</context>

<output_format>
Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.
</output_format>

<constraints>
Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.
</constraints>

<tone>
Professionale, pragmatico, orientato all'affidabilita del rilascio.
</tone>

DeepSeek · DeepSeek

Ruolo: Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.

Obiettivo: Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.

Contesto: Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].

Formato output: Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.

Vincoli & regole: Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.

Tono & stile: Professionale, pragmatico, orientato all'affidabilita del rilascio.

Gemini · Google

## Ruolo
Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.

## Contesto
Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].

## Obiettivo
Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.

## Tono & stile
Professionale, pragmatico, orientato all'affidabilita del rilascio.

## Formato output
Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.

## Vincoli & regole
Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.

Grok · xAI

## Ruolo
Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.

## Obiettivo
Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.

## Contesto
Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].

## Formato output
Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.

## Vincoli & regole
Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.

## Tono & stile
Professionale, pragmatico, orientato all'affidabilita del rilascio.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Mistral · Mistral AI

## Ruolo
Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.

## Obiettivo
Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.

## Contesto
Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].

## Formato output
Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.

## Vincoli & regole
Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.

## Tono & stile
Professionale, pragmatico, orientato all'affidabilita del rilascio.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

ChatGPT · OpenAI

## Ruolo
Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.

## Obiettivo
Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.

## Contesto
Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].

## Formato output
Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.

## Vincoli & regole
Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.

## Tono & stile
Professionale, pragmatico, orientato all'affidabilita del rilascio.

## Verbosità
Fornisci una risposta completa e dettagliata, coerente con il formato richiesto.

Perplexity · Perplexity

Progetta il piano della pipeline CI/CD: definisci gli stage in ordine (build, test, security, deploy per ambiente) con trigger, step, gate di passaggio e comportamento in caso di fallimento. Specifica la strategia di rilascio per ambiente, la procedura di rollback e una matrice riepilogativa degli ambienti.
Ruolo: Agisci come un DevOps/Platform engineer senior esperto di progettazione di pipeline CI/CD, gate di qualita, strategie di rilascio (blue-green, canary, rolling) e automazione del deploy.
Contesto: Progetto/servizio: [nome e tipo, es. API, web app]. Stack/linguaggio: [es. Node, Java, PHP]. Repository e modello di branching: [es. trunk-based, GitFlow]. Ambienti: [es. dev, staging, produzione]. Requisiti di qualita: [test richiesti, soglia di copertura, scansioni di sicurezza]. Strategia di rilascio desiderata: [es. blue-green, canary, rolling]. Piattaforma CI/CD (se vincolata): [es. GitHub Actions, GitLab CI]. Vincoli: [approvazioni manuali, finestre di deploy, conformita].
Formato output: Restituisci markdown strutturato. H1 '# Pipeline CI/CD - [Progetto]'. H2 '## Panoramica' (trigger principali e ambienti). H2 '## Stage' con un H3 numerato per ogni stage; ciascuno con elenco puntato: Trigger, Step, Gate (condizione di passaggio), Su fallimento. H2 '## Rollback' (trigger del rollback e procedura). H2 '## Matrice ambienti' con tabella markdown | Ambiente | Trigger | Approvazione | Strategia |.
Vincoli & regole: Ordina gli stage in modo che la sicurezza e i test precedano qualsiasi deploy: nessun deploy su build/test non superati. Ogni stage deve avere un gate esplicito e un comportamento di fallimento. NON inventare soglie numeriche (copertura, error rate, durata health check): usa [SOGLIA DA DEFINIRE] dove non fornite. Se non e indicata una piattaforma, mantieni il piano agnostico e segnalalo. Rispetta i vincoli di approvazione forniti (es. approvazione manuale in produzione). La matrice ambienti deve essere coerente con gli stage descritti. Tutto in italiano.
Tono & stile: Professionale, pragmatico, orientato all'affidabilita del rilascio.

Esempio di output

# Pipeline CI/CD - [Progetto]

## Panoramica
Trigger: push su feature branch, PR verso main, tag di release. Ambienti: dev, staging, produzione.

## Stage
### 1. Build
- Trigger: ogni push
- Step: install dipendenze, compilazione/artefatto
- Gate: build completata senza errori
- Su fallimento: blocca, notifica autore

### 2. Test
- Step: unit test, integration test
- Gate: 100% test verdi, copertura >= [SOGLIA DA DEFINIRE]
- Su fallimento: blocca merge

### 3. Security
- Step: scansione dipendenze (SCA), analisi statica (SAST), scan segreti
- Gate: nessuna vulnerabilita Critica/Alta
- Su fallimento: blocca

### 4. Deploy staging
- Trigger: merge su main
- Strategia: deploy automatico
- Gate: smoke test post-deploy verdi

### 5. Deploy produzione
- Trigger: tag di release + approvazione manuale
- Strategia: blue-green
- Gate: health check verde per 5 min

## Rollback
- Trigger: error rate > [SOGLIA DA DEFINIRE] o health check rosso
- Procedura: switch del traffico alla versione precedente (blue-green)

## Matrice ambienti
| Ambiente | Trigger | Approvazione | Strategia |
|---|---|---|---|
| staging | merge main | No | automatico |
| produzione | tag release | Si (manuale) | blue-green |

Domande frequenti

E legato a uno strumento specifico?

E indipendente dallo strumento per default (descrive stage e gate in modo portabile). Se indichi una piattaforma (es. GitHub Actions, GitLab CI) adatta la terminologia, ma resta concettualmente trasferibile.

Definisce i gate di qualita?

Si: per ogni stage specifica le condizioni di passaggio (es. test verdi, copertura minima, scansione sicurezza senza vulnerabilita critiche) e cosa blocca la pipeline, evitando deploy su build non verificate.

Inventa soglie come la copertura?

No: usa le soglie che fornisci. Se non indichi una soglia (es. % copertura) lascia [SOGLIA DA DEFINIRE] invece di inventarne una.

Vuoi un prompt su misura?

Costruiscine uno in poche domande — e adattalo a ogni modello.

Crea il tuo prompt