Una modifica fatta direttamente in produzione è un esperimento condotto sugli utenti veri. Per evitarlo, Salesforce dà a ogni cliente delle copie dell’org di produzione — le sandbox — e più di un veicolo per spostare la configurazione (i metadata) da un ambiente all’altro: i change set, i pacchetti distribuiti via AppExchange (managed e unmanaged) e gli strumenti basati su Metadata API. L’esame quasi mai ti chiede come si clicca: ti chiede quale ambiente per quale fase e quale veicolo per quale rotta, e costruisce i distrattori sulle scelte che sembrano equivalenti e non lo sono.
Le sandbox: cosa copia ciascuna
| Tipo | Cosa copia | A cosa serve |
|---|---|---|
| Developer | solo metadata, nessun dato di produzione, spazio dati minimo | sviluppo individuale, una per persona |
| Developer Pro | solo metadata, capacità dati maggiore | integrazione del lavoro di più persone, QA, training con dati caricati a mano |
| Partial Copy | metadata più un campione dei dati di produzione, scelto da un sandbox template | user acceptance testing, integration testing, training |
| Full | replica della produzione: tutti i metadata e tutti i dati, allegati compresi | performance testing, load testing, staging e prova del cutover |
Due letture vanno tenute distinte. La prima è cosa contiene l’ambiente: solo Partial Copy e Full portano dati di produzione, e solo la Full li porta tutti. La seconda è cosa ti autorizza a concludere: Trailhead attribuisce performance test, load test e staging alla sola Full, perché sono le uniche misure che hanno senso su un volume di dati realistico. Una prova di durata su un campione non dice niente sulla produzione.
Non sono sandbox, e l’esame le mette volentieri fra le opzioni, due cose che non discendono dalla produzione: la Developer Edition org (un org gratuito e vuoto, buono per provare un pacchetto) e la scratch org (un ambiente effimero, costruito da sorgente, orientato allo sviluppo con Salesforce DX). Nessuna delle due si «rinfresca» da produzione, perché non c’è niente da cui rinfrescarsi.
Sui tempi di refresh vale una cautela: le pagine ufficiali non concordano fra loro (una dà un giorno per tutti i tipi, un’altra cinque giorni per la Partial Copy e ventinove per la Full). Impara l’ordine — Developer e Developer Pro si rigenerano di frequente, Partial Copy meno, Full molto meno — e non la cifra: la finestra di refresh della Full è il motivo per cui si pianifica quando rifarla, non un numero da recitare.
La pipeline di un rilascio
Il modello che Trailhead descrive assegna un ambiente a ogni fase: una Developer sandbox per ciascuna persona per costruire; una Developer Pro condivisa dove confluisce e si integra il lavoro di tutti; una Partial Copy per lo UAT, perché gli utenti hanno bisogno di vedere dati che riconoscono; una Full per il training e per la prova generale prima del go-live; poi la produzione.
Su Partial Copy e Full il sandbox template decide quali oggetti e quanti record vengono copiati: è lo strumento con cui si tiene sotto controllo il contenuto di un ambiente di collaudo. Sui dati copiati esistono add-on come Data Mask (anonimizza i dati sensibili) e la funzione di seed per popolare una sandbox che nasce vuota: sono capacità aggiuntive e recenti, nominale con prudenza e non dare per scontato che siano incluse nell’edition del cliente.
Un refresh non è una fusione
È la trappola operativa che l’esame ama di più. Fare il refresh di una sandbox significa ributtarla via e rifarla da una copia corrente della produzione: la configurazione non ancora rilasciata che vive solo in quella sandbox non sopravvive. Se una sandbox condivisa contiene settimane di lavoro non ancora deployato e serve portarci dentro anche una modifica fatta in produzione, il refresh è la risposta sbagliata. La risposta giusta è muovere quella singola modifica verso la sandbox — un change set da produzione verso la sandbox, oppure rifacendola a mano — e tenere il refresh per quando la sandbox è vuota di lavoro utile.
Il corollario: i change set non viaggiano in una sola direzione. Dalla sandbox alla produzione e dalla produzione alla sandbox sono entrambe rotte legittime.
I tre veicoli per i metadata
| Change set | Unmanaged package | Managed package | |
|---|---|---|---|
| Rotta ammessa | solo fra org legate alla stessa produzione (una produzione e le sue sandbox, o due sandbox della stessa produzione) | qualunque org, anche senza parentela | qualunque org |
| Cosa porta | solo metadata, nessun record | solo metadata | metadata, protetti da un namespace |
| Nel target | componenti normali, modificabili | componenti normali, modificabili, e consumano i limiti di app, tab e oggetti | non visibili né modificabili, e non consumano quei limiti |
| Aggiornamento | non esiste: si rifà un altro change set | si disinstalla e reinstalla una nuova versione | il provider può aggiornarlo, anche in push |
| Chi lo usa | l’amministratore, dentro il proprio org e le sue sandbox | chi deve spostare metadata fra org non parenti, o isolarli per farne emergere le dipendenze | i partner che distribuiscono e licenziano un’app |
Il flusso del change set è quello che conosci: in Setup si stabilisce prima una deployment connection (Deployment Settings), poi si costruisce un outbound change set, si aggiungono le dipendenze — a mano, perché il sistema le suggerisce ma non le garantisce — si fa l’upload, si aspetta, e nell’org di destinazione si distribuisce l’inbound change set. Dopo l’upload il pacchetto è bloccato: se hai dimenticato un campo, cloni e ricominci. E un change set aggiunge o sostituisce, non cancella: rimuovere un componente dal target è un’operazione separata.
Quando le due org non sono parenti — tipicamente dopo un’acquisizione, due produzioni distinte senza alcuna sandbox in comune — il change set non è un’opzione lenta, è un’opzione impossibile: non esiste connessione da stabilire. Lì servono un unmanaged package (o gli strumenti Metadata API / Salesforce CLI). L’unmanaged package si usa anche come lente diagnostica: aggiungendoci i componenti, il sistema tira dentro i metadata dipendenti e ti mostra legami che non avevi previsto.
Il managed package è l’altra faccia: nasce da un org di packaging con un namespace registrato che viene prefissato a ogni componente (FinanceX__EnhancedAccount__c) e che non è più modificabile dopo la creazione. In cambio il fornitore aggiorna la sua app senza che tu disinstalli niente, e il codice resta suo. Come amministratore tu non lo crei: lo installi, scegliendo l’accesso per Admins Only, All Users o Specific Profiles, e — regola scritta in chiaro nella documentazione — lo provi prima in una sandbox o in una Developer Edition org, mai direttamente in produzione. Nota di attualità: la pagina Trailhead che confronta i due tipi di pacchetto oggi è scritta intorno ad AgentExchange, il marketplace per le azioni agentiche; la distinzione managed/unmanaged è la stessa, ma il nome che vedi in una domanda potrebbe essere l’uno o l’altro.
Trappole tipiche d’esame
- «Lo UAT è passato, quindi siamo pronti». Lo UAT firmato in Partial Copy non dice nulla su tempi e volumi: per provare il cutover end-to-end e misurare quanto dura serve la Full, l’unica con i dati di produzione al completo. Se lo scenario contiene le parole performance, load o staging, l’ambiente è la Full.
- Change set fra org senza parentela. Il change set richiede una deployment connection fra org legate alla stessa produzione. Fra due produzioni distinte (dopo una fusione, per esempio) la risposta è un unmanaged package o la Metadata API, non «un change set più grande».
- Refresh usato come sincronizzazione. Il refresh ricrea la sandbox da produzione e butta via il lavoro non rilasciato. Per portare in sandbox una modifica fatta in produzione si usa un change set in quella direzione.
- Managed e unmanaged scambiati sui limiti. Il contenuto di un managed package non consuma i limiti di app, tab e oggetti e non è modificabile; quello unmanaged li consuma ed è modificabile. È la coppia di affermazioni su cui si costruiscono le domande «scegline due».
- «Aggiorno l’unmanaged package». Non si aggiorna: si disinstalla e reinstalla. Solo il managed riceve upgrade dal provider.
- Il change set porta anche i dati. No: è solo metadata. I record di configurazione (custom settings, custom metadata popolati come dati, record di riferimento) si spostano con Data Loader o con strumenti dedicati, ed è un passo del piano di rilascio che si dimentica.