Automazione del deploy

1. La filosofia: sviluppatore al controllo

Il nostro flusso principale è manuale, basato su workflow_dispatch:

on:
  workflow_dispatch:
    inputs:
      action:
        description: 'Azione da eseguire (Deploy o Validate)'
        required: true
        default: 'Validate'
      environment:
        description: 'Ambiente di destinazione'
        required: true
        default: 'develop'
      testLevel:
        description: 'Livello di test'
        required: true
        default: 'RunLocalTests'

Vantaggi:

• ✅ Controllo totale da parte dello sviluppatore
• ✅ Evita deploy automatici indesiderati
• ✅ Migliora la tracciabilità

2. Verifica della Pull Request e stato

Verifichiamo che la PR esista e sia pulita (CLEAN):

PR_STATE=$(gh pr list --head $GITHUB_REF_NAME --json state --jq '.[0].state')

Obiettivo: garantire che la modifica sia stata revisionata e sia integrabile senza conflitti.

3. Sincronizzazione e merge

- name: Merge target branch into current
  run: git merge origin/$TARGET_BRANCH

Questo assicura che testiamo sul codice aggiornato del branch di destinazione (es. develop).

4. Generazione intelligente del pacchetto delta

Perché il deploy incrementale?

Nei progetti grandi, distribuire tutta la metadata può essere estremamente lento. La nostra strategia delta distribuisce solo i componenti modificati, riducendo i tempi da ore a minuti.

Implementazione con sfdx-git-delta

# Crea pacchetti delta per metadata nuovi, modificati o rimossi
branch="$GITHUB_REF"
environment_branch="origin/$TARGET_BRANCH"
mkdir $CHANGE_SOURCE
sfdx sgd:source:delta --to="$branch" --from $(git merge-base "$branch" "$environment_branch") \
  --output changed-sources/ --generate-delta --source force-app/ --ignore scripts/CI/.deltaignore

# Verifica contenuto generato
echo "========== package.xml =========="
cat "changed-sources/package/package.xml"
echo "========== destructiveChanges.xml =========="
cat "changed-sources/destructiveChanges/destructiveChanges.xml"

File generati:

• package.xml: componenti aggiunti/modificati
• destructiveChanges.xml: componenti rimossi
• .deltaignore: file da omettere (statici, configurazioni CI)

Vantaggi:

• ⏩ Distribuisce solo ciò che è cambiato
• 🔎 Massima visibilità con package.xml
• ⚖️ Compatibile con .deltaignore
• 🚀 Evita effetti collaterali su componenti non correlati

5. Strategia di test selettivi con RunSpecifiedTests

Il problema: copertura vs velocità

Salesforce richiede il 75% di copertura media per produzione. Con RunLocalTests è basato sulla media globale, ma con RunSpecifiedTests ogni classe nel pacchetto deve raggiungere il 75% individualmente: un criterio più rigoroso che garantisce qualità.

Selezione intelligente dei test

1. Mappatura CSV Classi → Test

Class,TestClass
MyService,MyServiceTest
UserUtil,UserUtilTest
TriggerHandler,TriggerHandlerTest

2. Determinazione automatica dei test

- name: Get Apex Tests
  if: env.METADATA_CHANGES == 'yes'
  run: |
    TESTS="$INPUT_APEX_TESTS"
    BASE_PATH="scripts/CI/"
    folder_path="changed-sources/force-app/main/default/classes"
    
    if [ "$TEST_LEVEL" == "Run all specified tests" ]; then
      TESTS=$(node "${BASE_PATH}getAllTests.js" "$SKIP_TESTS")
    elif [ -z "$TESTS" ] && test -f "${BASE_PATH}getTestsToRun.js"; then
      TESTS=$(node "${BASE_PATH}getTestsToRun.js" "${folder_path}")
    fi
    
    echo "APEX_TESTS=$TESTS" >> $GITHUB_ENV

3. Comando di deploy con test specifici

sfdx force:source:deploy -u $TARGET_ORG -x changed-sources/package/package.xml \
  -l RunSpecifiedTests -r "$APEX_TESTS"

Vantaggi di RunSpecifiedTests:

• 📊 Criterio più severo: ogni nuova classe deve avere il 75% di copertura
• ⚡ Test più rapidi: solo i test rilevanti
• 🎯 Precisione: test specifici sui cambi effettivi
• 🛡️ Qualità: impedisce che codice a bassa copertura “passi” grazie alla media globale

Benefici aggiuntivi:

• 📊 Esecuzioni più veloci
• 🌐 Test indipendenti per pacchetto
• 🧳 Precisione sui cambi reali

6. Barriere di sicurezza aggiuntive

• checkDeploymentAllowed.sh: validazioni in base a orari, ambiente e regole aziendali.
• Ritenti sullo stato della PR:

while [ $attempt -le 3 ]; do
  pr_state=$(gh pr list --head $GITHUB_REF_NAME --json state --jq '.[0].state')
  [ "$pr_state" != "UNKNOWN" ] && break
  sleep 5; ((attempt++))
done

7. Monitoraggio continuo ed esecuzioni programmate

Esecuzioni complete periodiche

Anche se usiamo test selettivi per ciascun deploy, pianifichiamo verifiche complete:

# workflow: run_all_tests.yaml
schedule:
  - cron: '0 2 * * *'  # Ogni notte alle 2:00

Benefici:

• 🔄 Verifica continua dell’intera codebase
• 🚨 Rilevamento precoce di regressioni inattese
• 📊 Report aggiornato della copertura globale

8. Notifiche e chiusura del ciclo

Integrazione con strumenti di comunicazione

• 💬 Webhook Slack/Teams: notifiche automatiche di stato
• 🔗 Link diretti: a PR, esecuzione e log
• 📈 Metriche di copertura: report testuale con linee coperte

Auto-merge intelligente

• ✅ Merge automatico se il deploy ha successo
• 🔄 Allineamento dei branch senza intervento manuale
• 🚨 Allerte immediate in caso di errori

9. Risultati e metriche

Miglioramenti quantificabili

• Tempo di deploy: da ore a minuti
• Copertura del codice: 75% garantito per componente (non solo media)
• Qualità: criterio più rigoroso previene regressioni
• Efficienza: meno test eseguiti, maggiore precisione

Casi d’uso

• 🟢 Sviluppo: NoTestRun per velocità
• 🟡 Staging: RunSpecifiedTests per validazione
• 🔴 Produzione: RunSpecifiedTests obbligatorio

Conclusione

La nostra strategia combina velocità e qualità tramite:

📦 Deploy delta: solo i cambi rilevanti

🧪 Test selettivi: RunSpecifiedTests con criterio rigoroso del 75% per classe

🔄 Monitoraggio continuo: esecuzioni pianificate per verifica globale

🤖 Automazione intelligente: selezione automatica dei test via mappatura CSV

Questa pipeline CI/CD è una leva chiave della nostra cultura DevOps per Salesforce. Permette di consegnare con fiducia, fare audit con facilità e migliorare continuamente.

🚀 Automatizzata, ma sotto controllo.

💡 Veloce, ma sicura.

😎 Efficiente, ma trasparente.

---

Riferimenti

Configurazione basata sulle best practice Salesforce e strumenti della community come sfdx-git-delta per deploy incrementali e uso avanzato del parametro testLevel della Metadata API.