Salesforce - Come Distribuire tra Ambienti (Sandbox, Live, ecc)

Question

Stiamo cercando in impostazione di un corretto processo di distribuzione.

Da quello che ho letto sembra che ci sia 4 metodi per fare questo.

1. Copia & Incolla -- non vogliamo fare questo
2. Utilizzando il "Pacchetto" meccanismo incorporato nella Salesforce Interfaccia Web
3. Eclipse Forza IDE "Distribuire al Server" opzione
4. Script Ant (l'ho provato ancora)

Qualcuno ha consigli in merito alla limitazione dei vari metodi .

Si può inserire il tutto in un Interfaccia Web pacchetto?

Stiamo cercando di distribuire i seguenti elementi:

• Classi Apex

• Trigger Apex

• I flussi di lavoro

• Modelli Di E-Mail

• MailMerge Modelli -- non riesco a trovare questi in Eclipse

• Campi Personalizzati

• Layout Di Pagina

• RecordTypes (non riesco a trovare questi nel Sito o Eclipse)

• Selezione di elementi?

• SControls

Answer 1

Vi consiglio il Force.com migrazione strumento .

Per riferimento:

• Force.com Migration Tool Documentation
• Migration Tool Guida

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 recente esperienza dolorosa.

Imballaggio:questo è un metodo molto vecchio che precede l'API dei metadati in cui sia Ant e Eclipse contare.Nella nostra esperienza, packaging unico vantaggio è nella definizione del tuo progetto.Se si utilizza Eclipse (che noi, e mi raccomando), è possibile definire il progetto in quanto basati su un particolare pacchetto.Come ricorderai per aggiungere nuovi componenti per il pacchetto, il progetto si blocca insieme

Una cosa che sconcertati noi per un po', btw, sono molti usi di pacchetto.Abbiamo rilevato il seguente:

I pacchetti installati:questi vengono gestiti e non gestiti sapori e sono davvero, nelle parole di un recente post sul SFDC commissioni, per gli Isv per distribuire la loro roba in vari unknown org "là fuori".Gestito e pacchetti hanno delle limitazioni che li rendono inadatti e non necessari per la distribuzione, dallo sviluppo alla produzione, all'interno di un'organizzazione, o in ogni caso in cui si sta facendo di sviluppo personalizzato e non ha intenzione di distribuire il codice di un grande anonimo base.

Non i pacchetti installati:questo è ciò che si vede quando si fa clic su "Pacchetti" nel web UI.Questi, che è a volte chiamata "pacchetti di sviluppo", sembra essere solo un modo conveniente per mantenere la definizione dei progetti insieme.

Comunque, la conclusione sto arrivando verso è che la nostra squadra (sviluppo personalizzato, non ISV) non ha bisogno di pacchetti in qualsiasi forma.

Le altre forme di distribuzione, sia Eclipse e Ant, fare affidamento sulle API dei Metadati.In teoria sono in grado di esattamente le stesse cose.In realtà sembrano essere complementari.Il Force.com strumento di migrazione, costruito nel Force.com IDE di Eclipse, distribuzione facile come può essere (che non è molto) e ti dà una bella occhiata a ciò che si intende distribuire.D'altra parte, abbiamo visto Ant fare alcune cose IDE potrebbe non.Quindi è probabilmente la pena di saperne di entrambi.

Il processo che stiamo virando verso è quello di mantenere tutti i nostri progetti in SVN, e utilizzare SVN struttura di definizione del progetto (Eclipse, questa e la rispetto).E noi utilizzare Eclipse e a volte Ant per la migrazione.Senza apparente necessità per i pacchetti ovunque.

A proposito, una cosa di essere a conoscenza di -- non tutti i componenti sono migrabili.Alcune cose devono essere riconfigurato manualmente nell'ambiente di destinazione.Un esempio potrebbe essere il momento flussi di lavoro basati su.Code e Gruppi anche bisogno di behand-creato, penso.Allo stesso modo le API dei metadati non può lavorare direttamente in campo le eliminazioni quindi, se avete cancellato un campo di origine, è necessario eliminare manualmente in target.Ci sono altri casi.

La speranza che è sempre utile

- Steve Lane

Answer 3

A partire dalla primavera '09, i modelli di stampa unione non sono supportati nei metadati, ma i tipi di record sono. Troverete i tipi di record come un elemento XML nel file per l'oggetto a cui appartengono. Tutto il resto sulla vostra lista è supportata con una piccola eccezione. valori Picklist per i campi standard non possono essere modificati nella primavera del '09. Restate sintonizzati per le notizie su Estate '09 annunci di nuove caratteristiche.

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 di utilizzare pacchetti non gestiti (quello che Steve chiama pacchetti non-installato) è che quando si aggiunge i metadati a un pacchetto, verrà automaticamente aggiunto i metadati dipende. Così è più facile per afferrare un set completo di metadati contenente tutte le sue dipendenze. Se si sta muovendo più volte i metadati da un org (sandbox) ad un altro (produzione), l'approccio di Steve è probabilmente il modo migliore per andare e certamente oggi più comune. Mi capita spesso di uso non gestiti pacchetti "developer" a muoversi qualcosa che ho sviluppato in un'org ad un altro org non correlato. Per il mio scopo, mi piace avere il pacchetto definito nella org al contrario di un progetto di Eclipse / SVN. Ma che, probabilmente, non ha senso se si sta facendo il team di sviluppo in molti / org sandbox dev e utilizzano già SVN.

Jesper

Answer 4

Un'altra opzione è quella di utilizzare Cambio Imposta se si desidera spostare meta-dati da una sandbox alla produzione.

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

  

L'invio di un cambiamento di set tra due organizzazioni richiede una distribuzione   connessione. Attualmente, insiemi di modifiche possono essere inviati solo tra   organizzazioni che sono collegate con un'organizzazione di produzione, per   esempio, un'organizzazione della produzione e una sandbox, o due sandbox   creata dalla stessa organizzazione.

Answer 5

Dalla documentazione:

Un pacchetto deve essere gestito per poter essere pubblicato pubblicamente su AppExchange, e di supportare gli aggiornamenti . Un'organizzazione in grado di creare un unico pacchetto di gestione che può essere scaricato e installato da molte organizzazioni diverse. Si differenziano dai pacchetti non gestiti in quanto alcuni componenti sono bloccati, permettendo il pacchetto è riuscito a essere aggiornato in seguito. pacchetti non gestiti non includono componenti bloccati e non possono essere aggiornati. Inoltre, pacchetti gestiti offuscare alcuni componenti (come Apex) sulla sottoscrizione organizzazioni, in modo da proteggere la proprietà intellettuale dello sviluppatore.

Advantage al pacchetto gestito sarebbe che permette di effettuare facilmente la versione e distribuire le cose tra più organizzazioni SFDC.

Answer 6

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

1. I pacchetti installati non può essere distribuito a un Developer Org . Devi installarli manualmente uno per uno nella Dev Org.

   Se un pacchetto non può essere installato nella org (per esempio perché richiede la password, come Marketo vendite Insight , o perché ha stato deprecato, come Salesforce per Google AdWords ) e la nostra applicazione ha le dipendenze su di esso (come riferimenti a campi in oggetti che appartengono alla pacchetto) allora non sarà in grado di distribuire l'applicazione.

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

2. Quando la sandbox viene aggiornata dalla produzione e abbiamo rinfrescare la nostra progetto locale (che è collegata al SVN) dal server di tutto ulteriori file / codice che era in nel vecchio Sandbox ma non è in la produzione sta per essere spostato nella nuova Sandbox.

   Soluzione : tutti modifiche apportate nella produzione devono essere replicati in Sandbox e Org sviluppatore. (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 messaggio: https://www.deploypkg.com/deploy-to-production/