Change set: dipendenze, limiti e buone pratiche

Un change set è un contenitore: la documentazione Salesforce usa l’immagine della valigia, “containers that are used to transport things from one place to another”. Ci metti dentro i metadati che hai costruito in sandbox — oggetti e campi custom, validation rule, page layout, Flow, report type — e li spedisci nell’org di destinazione. È lo strumento di deployment che un amministratore ha a disposizione senza scrivere una riga di codice e senza installare nulla, e per questo l’esame lo chiede: non come si clicca, ma cosa il change set sa fare e cosa non sa fare.

Le due metà dello stesso pacchetto

Il change set esiste in due forme, che sono lo stesso pacchetto visto dalle due org:

Due conseguenze che l’esame sfrutta. La prima: il change set si carica, non si tira. Chi lavora in produzione non può andare a prendersi il pacchetto dalla sandbox; qualcuno deve fare l’upload dalla sandbox. La seconda: la destinazione deve aver autorizzato la connessione. In Deployment Settings l’org che riceve abilita l’org che spedisce, e l’autorizzazione è direzionale: se vuoi anche il viaggio di ritorno, va abilitata anche lì.

C’è poi un confine che non si supera: i change set funzionano solo fra org imparentate, cioè “orgs that are affiliated with the same production environment” — produzione e le sue sandbox, o due sandbox della stessa produzione. Verso la sandbox di un cliente, verso una scratch org o verso un’org demo scollegata, il change set non è un’opzione: servono la Salesforce CLI con un manifest package.xml, un package, oppure strumenti di deployment che si connettono a org arbitrarie.

Le dipendenze non si portano dietro da sole

Questo è il punto dove la maggior parte dei deployment fallisce. Un change set contiene esattamente i componenti che ci hai messo. Se aggiungi una validation rule che legge un campo custom nuovo, e il campo non è nel change set, la validation rule arriva a destinazione e non trova nulla su cui appoggiarsi: il deploy fallisce con un errore di componente mancante.

L’outbound change set offre il pulsante View/Add Dependencies, che elenca i componenti correlati e ti permette di aggiungerli — ma sei tu a decidere di premerlo e a scegliere cosa includere. La documentazione lo dice senza giri di parole: il flusso tradizionale richiede “considerable time manually checking for dependencies so you don’t break the deployment”. Non è un automatismo, è una checklist.

E qui arriva il vincolo che rende costoso l’errore: dopo l’upload il pacchetto è bloccato. “If you forget one field, you must clone the package, create a new version, and start the upload process all over again.” Non esiste un “aggiungi un componente al change set che ho già caricato”. Se te ne accorgi guardando la lista dell’inbound change set prima di deployare, la mossa giusta non è deployare e rimediare dopo: è tornare in sandbox, clonare l’outbound change set, aggiungere il componente mancante e ricaricarlo. L’inbound rimasto a metà si abbandona.

Per questo esiste Validate: valida il deployment senza scrivere nulla nell’org di destinazione. È lo stesso principio del comando CLI sf project deploy validate, che “enables you to verify the results of tests that would be executed in a deployment, but doesn’t commit any changes”, seguito da sf project deploy quick entro una finestra limitata (la documentazione CLI parla di dieci giorni, a patto di non fare altri deployment nel frattempo). Validare prima costa pochi minuti e ti dice se le dipendenze reggono.

Metadati sì, record no

Il change set muove configurazione, non dati. È un deployment di soli metadati.

È il difetto che fa più male nelle release ripetute: se la tua automazione legge una tabella di parametri conservata come record di un oggetto custom, quei record non partono. Dopo ogni deployment qualcuno deve ricordarsi di esportarli dalla sandbox e ricaricarli in produzione con Data Loader — un passo manuale, quindi un passo che prima o poi si dimentica.

La risposta strutturale è cambiare dove vivono quei parametri: i custom metadata type sono metadati, non dati, e la documentazione lo dice esplicitamente — “change sets let you deploy your types and records from a sandbox”. Tipo e record viaggiano nello stesso pacchetto. Trasformare una tabella di configurazione da oggetto custom a custom metadata type elimina il passo manuale invece di ricordarselo meglio. Le alternative, quando i dati sono davvero dati, sono Data Loader o strumenti che muovono metadati e record insieme (con tetti propri sul numero di record, che cambiano nel tempo: non impararli a memoria).

Il Flow che arriva spento

Un caso specifico che vale una domanda intera. La documentazione è verbatim: “By default, change sets deploy flows as deactivated, even if the flow had an active version in the original sandbox.” Il change set include tutte le versioni del Flow, e in destinazione tocca a te verificare quale versione attivare.

Quindi: deployment concluso senza errori, utenti che segnalano che “non succede niente”, nessun log e nessun messaggio di errore. Non è un bug e non è un problema di permessi — è un Flow inattivo. Il passo post-deploy è aprire il Flow in produzione e attivare la versione giusta. Conviene includere nel change set anche i Flow test, così la verifica in destinazione è ripetibile.

Buone pratiche da mettere nello standard di team

• Costruisci in sandbox, non in produzione. Il change set presuppone che la modifica nasca altrove e arrivi verificata.
• Valida prima di deployare, e leggi la lista dei componenti dell’inbound: è l’ultimo momento in cui costa poco accorgersi di un buco.
• Un change set piccolo e coerente fallisce in modo leggibile; un pacchetto con settanta componenti eterogenei ti lascia a indovinare.
• Tieni un elenco dei passi manuali post-deploy: attivare i Flow, caricare i record di configurazione, assegnare i permission set. Il change set finisce, la release no.
• Attenzione ai profili: le impostazioni di profilo viaggiano solo per i componenti presenti nel change set. Conviene affidare l’accesso ai permission set, che si deployano come oggetti interi e si assegnano poi.

Trappole tipiche d’esame

• “Deployment riuscito” non vuol dire “funzionante”. Un Flow record-triggered attivo in sandbox arriva disattivato in produzione: nessun errore, nessun effetto. La risposta giusta è attivare la versione corretta, non ridistribuire.
• Componente mancante visto nell’inbound: si clona l’outbound, non si rattoppa. Dopo l’upload il pacchetto è bloccato; non esiste modo di aggiungere un componente a un change set già caricato, né di aggiungerlo dal lato inbound.
• View/Add Dependencies è un aiuto, non un automatismo. Le distrattrici che dicono “il change set include automaticamente i componenti dipendenti” sono false.
• I record non sono metadati. Se la domanda parla di tabelle di tariffe, mapping o parametri conservati come record di oggetto custom, il change set non li porta: o Data Loader a ogni release, o li trasformi in custom metadata type, che invece viaggiano tipo e record insieme.
• La connessione è direzionale e fra org imparentate. Si carica dall’origine verso una destinazione che ha autorizzato la connessione; verso una scratch org o l’org di un’altra azienda il change set semplicemente non esiste come strada.
• Validare non è deployare. Validate non scrive nulla nell’org di destinazione: serve a scoprire gli errori, non a completare la release.