Salesforce: distribuzione tra ambienti (sandbox, live, ecc.)

Question

Stiamo valutando la possibilità di impostare un processo di distribuzione appropriato.

Da quello che ho letto sembrano esserci 4 metodi per farlo.

1. Copia Incolla & - Noi non vogliamo fare questo
2. Utilizzando il meccanismo di "pacchetto" integrato nella interfaccia Web Salesforce
3. Eclipse IDE Forza "Deploy al server" opzione
4. Ant Script (non ho ancora provato questo)

Qualcuno ha consigli sulla limitazione dei vari metodi.

È possibile includere tutto in un pacchetto di interfaccia Web?

Stiamo cercando di implementare i seguenti elementi:

• classi Apex

• Apex Trigger

• flussi di lavoro

• Email Templates

• MailMerge Templates - non riesco a trovare questi in Eclipse

• campi personalizzati

• impaginazione

• RecordTypes (non riesco a trovare questi in sito o Eclipse)

• Elementi PickList?

• SControls

Answer 1

vi consiglio il Force.com Migration Tool.

Per riferimento:

• Force.com Migration Tool Documentation
• Migration Tool Guide

Lo strumento di migrazione consente di utilizzare gli obiettivi formica di spostare la vostra metadati tra salesforce.com organzations.

Answer 2

Posso parlare di questa esperienza dolorosa recente.

Packaging: si tratta di un metodo molto vecchio che precede l'API dei metadati su cui si basano sia Ant che Eclipse. Nella nostra esperienza, l'unico vantaggio della confezione è la definizione del tuo progetto. Se stai usando Eclipse (cosa che facciamo, e lo consiglio), puoi definire il tuo progetto come basato su un particolare pacchetto.Finché ti ricordi di aggiungere nuovi componenti al tuo pacchetto, il tuo progetto si blocca insieme

Una cosa che ci ha delusi per un po ', btw, sono i molti usi del pacchetto. Abbiamo notato quanto segue:

Pacchetti installati: questi sono disponibili in versioni gestite e non gestite e sono davvero, nelle parole di un recente post sulle schede SFDC, per gli ISV di distribuire le loro cose in varie organizzazioni sconosciute "là fuori ". Sia i pacchetti gestiti che quelli non gestiti presentano limitazioni che li rendono inadatti e non necessari per l'implementazione dallo sviluppo alla produzione all'interno di un'organizzazione, o comunque in cui si sta effettuando lo sviluppo personalizzato e non si intende distribuire il codice su una base anonima di grandi dimensioni.

Pacchetti non installati: questo è ciò che viene visualizzato facendo clic su "Pacchetti" nell'interfaccia utente web. Questi, che a volte chiamiamo "pacchetti di sviluppo", sembrano essere solo un modo conveniente per mantenere insieme una definizione di progetto.

In ogni caso, la conclusione che sto arrivando è che il nostro team (sviluppo personalizzato, non un ISV) non ha bisogno di pacchetti in nessuna forma.

Le altre forme di distribuzione, sia Eclipse che Ant, si basano sull'API dei metadati. In teoria sono capaci di esattamente le stesse cose. In realtà sembrano complementari. Lo strumento di migrazione di Force.com, integrato nell'IDE di Force.com per Eclipse, semplifica la distribuzione che può essere (che non è molto) e offre una buona panoramica di ciò che intende distribuire. D'altra parte, abbiamo visto Ant fare alcune cose che l'IDE non poteva fare. Quindi probabilmente vale la pena di imparare entrambi.

Il processo verso il quale ci stiamo concentrando è mantenere tutti i nostri progetti in SVN e utilizzare la struttura SVN come definizione del progetto (Eclipse lavorerà con questo e lo rispetterà). E usiamo Eclipse e talvolta Ant per la migrazione. Nessuna apparente necessità di pacchetti ovunque.

A proposito, un'altra cosa da sapere: non tutti i componenti sono migrabili. Alcune cose devono essere riconfigurate a mano nell'ambiente di destinazione. Un esempio potrebbe essere il flusso di lavoro basato sul tempo. Anche le code e i gruppi devono essere creati a mano, penso. Allo stesso modo l'API dei metadati non può elaborare direttamente cancellazioni di campi, quindi se hai cancellato un campo nella tua fonte, devi cancellarlo a mano nella destinazione. Ci sono anche altri casi.

Speranza che è utile -

- Steve corsia

Answer 3

partire dalla primavera '09, i modelli di stampa unione non sono supportati nei metadati, ma tipi di record sono. Troverai i tipi di record come un elemento XML nel file per l'oggetto a cui appartengono. Tutto il resto del tuo elenco è supportato con una piccola eccezione. I valori di elenco di selezione per i campi standard non possono essere modificati in primavera '09. Resta sintonizzato per le novità sugli annunci di Summer '09.

Aggiornamento: picklists standard su oggetti standard sono ora esposti metadati (come di API V16): http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm

In caso contrario, la risposta di Steve Lane è abbastanza preciso. Il vantaggio dell'utilizzo di pacchetti non gestiti (quello che Steve chiama pacchetti non installati) è che quando si aggiungono i metadati a un pacchetto, i metadati da cui dipende verranno automaticamente aggiunti. Quindi è più facile afferrare un set completo di metadati contenenti tutte le sue dipendenze. Se si spostano ripetutamente i metadati da un'org (sandbox) a un'altra (produzione), l'approccio di Steve è probabilmente il modo migliore per andare e sicuramente il più comune oggi. Uso spesso pacchetti "sviluppatore" non gestiti per spostare qualcosa che ho sviluppato in un'org a un'altra organizzazione non correlata. Per il mio scopo, mi piace avere il pacchetto definito nell'organizzazione in contrapposizione a un progetto/SVN di Eclipse.Ma questo probabilmente non ha senso se si sta facendo lo sviluppo di team su molte dev/sandbox org e si sta già utilizzando SVN.

Jesper

Answer 4

Dalla documentazione:

Un pacchetto deve essere gestito per poter essere pubblicato pubblicamente su AppExchange, e di supportare gli aggiornamenti. Un'organizzazione può creare un singolo pacchetto gestito che può essere scaricato e installato da molte organizzazioni diverse. Differiscono dai pacchetti non gestiti in quanto alcuni componenti sono bloccati, consentendo il successivo aggiornamento del pacchetto gestito. I pacchetti non gestiti non includono componenti bloccati e non possono essere aggiornati. Inoltre, i pacchetti gestiti nascondono alcuni componenti (come Apex) sulle organizzazioni che sottoscrivono, in modo da proteggere la proprietà intellettuale dello sviluppatore.

Il vantaggio del pacchetto gestito è che consente di eseguire facilmente la versione e distribuire le cose tra più organizzazioni SFDC.

Answer 5

Un'altra opzione è quella di utilizzare Change Sets se si desidera spostare i metadati da una sandbox alla produzione.

Al momento non ci sono alcune limitazioni su come possono essere utilizzati insiemi di modifiche:

invio di un cambio fissato tra due organizzazioni richiede una distribuzione connessione. Attualmente, i set di modifiche possono essere inviati solo tra le organizzazioni affiliate a un'organizzazione di produzione, per esempio , un'organizzazione di produzione e una sandbox o due sandbox creati dalla stessa organizzazione.

Answer 6

Sono ancora in difficoltà con questo me stesso. Né l'IDE del Migration Tool hanno risolto i principali problemi che devo affrontare, che sono i seguenti:

1. pacchetti installati non possono essere impiegati per uno sviluppatore Org. Devi installare manualmente uno alla volta nella Dev Org.

   Se un pacchetto non può essere installato nella org (per esempio, perché richiede la password, come Marketo Sales Insight, o perché è stato deprecato, come Salesforce for Google Adwords) e la nostra applicazione ha dipendenze su di esso (come i riferimenti ai campi negli oggetti che appartengono al pacchetto ), quindi non saremo in grado di distribuire l'app.

   Soluzione: se un pacchetto non può essere installato manualmente in un Dev Org ogni sviluppatore avrà bisogno il proprio Developer Sandbox. Sandbox per sviluppatori aggiuntivi possono essere ordinati da Salesforce. (Il cliente deve essere disposto a pagare per loro, anche se ...)

2. Quando la sandbox viene aggiornata dalla produzione e abbiamo aggiornare il nostro progetto locale (che è collegato a SVN) dal server tutti i file aggiuntivi/codice che era in nel vecchio Sandbox ma non è in la produzione verrà spostata nella nuova Sandbox.

   Soluzione: tutte modifiche apportate in produzione devono essere replicati nella sandbox e le org sviluppatori. (una specie di dolore, ma non male ...)

Answer 7

In ogni distribuzione di produzione di Salesforce, l'API di metadati è una delle opzioni migliori per farlo. Ci sono strumenti che semplificano il lavoro. Dai un'occhiata a questo post: https://www.deploypkg.com/deploy-to-production/