In che modo più sviluppatori possono lavorare efficientemente su un'applicazione force.com?

Question

La società per cui lavoro è la costruzione di un'applicazione force.com gestita come integrazione con il servizio che forniamo.

Abbiamo problemi a lavorare contemporaneamente sullo stesso set di file a causa degli strumenti scadenti forniti con il plugin di Force.com Eclipse. Se 2 sviluppatori stanno lavorando sullo stesso file, a uno viene dato un messaggio che non può salvare - una volta che si unisce deve forzare manualmente il plugin per spingere le sue modifiche al server e fare clic su 2 "Sei proprio sicuro?" messaggi.

Fondamentalmente, lo strumento fa un lavoro scadente di fusione in cambiamenti e forza i minuti di lavoro ogni volta che lo sviluppatore vuole salvare se un'altra persona ha modificato il file su cui sta lavorando.

Attualmente stiamo lavorando su questo fondamentalmente 'bloccando' singoli file consentendo ai colleghi di sapere chi sta modificando un file.

Sembra che ci debba essere un modo migliore in questo giorno ed età. Qualcuno sa di un set di strumenti diverso che potremmo usare, elaborare potremmo cambiare o qualsiasi cosa possiamo fare per rendere tutto più semplice?

Answer 1

Quando lavoro con la piattaforma Force.com, la mia organizzazione attuale ha scoperto che un certo numero di approcci diversi può funzionare a seconda della situazione. Usiamo tutti il ​​plugin Eclipse Force.com senza problemi e abbiamo trovato le seguenti configurazioni per funzionare bene.

Abbiamo un sistema di controllo della versione centralizzato che distribuiamo dall'utilizzo di una serie di comandi ant per un'istanza dell'organo di sviluppo. Quindi, a seconda dell'ambito del lavoro, lo separiamo in blocchi con ogni sviluppatore che ha la propria organizzazione di sviluppo e unendo le modifiche e testandole regolarmente o lavorando in un'unica organizzazione di sviluppo insieme (che se si hanno 2 sviluppatori non dovrebbero essere problema principale) che consente di avere un'integrazione quasi istantanea.

Se si sta tentando di lavorare sullo stesso file, si dovrebbe comunque programmare la coppia, ma se si lavora insieme su due componenti di un sistema simile, la condivisione della stessa organizzazione può consentire lo sviluppo in modo rapido e flessibile di creando lo scheletro del sistema che desideri utilizzare e poi ritagliando individualmente i dettagli.

Ho usato entrambi i metodi in modo estensivo e, dico, funzionano molto bene a seconda della situazione.

Answer 2

Non ho familiarità con force.com, ma non è possibile utilizzare il controllo del codice sorgente e trascinare tutti i file da force.com nel repository. Quindi potresti fare tutto il tuo lavoro e unire le tue modifiche alla linea principale. Quindi quando è necessario spingere la linea principale su force.com?

Answer 3

Ogni sviluppatore potrebbe lavorare in sandbox sviluppo separato (se si dispone di enterprise edition, penso che 10 sandbox con piena config & quantità limitata di dati sono inclusi nella quota?). Di volta in volta dovresti unire le tue modifiche (lo strumento diff da qualsiasi sistema di controllo della versione dovrebbe essere sufficiente) e testarle nell'ambiente di integrazione. La catena di sviluppo-> integrazione-> test di sistema-> Q & A-> produzione può essere utile anche per altri motivi.

È possibile utilizzare un trucco separato da considerare se, ad esempio, 2 ragazzi lavorano sullo stesso trigger. L'ho imparato sul corso "DEV 401" per sviluppatori.

1. Spostare tutta la logica in classi. Sul serio. Saranno più semplici anche per il test unitario.
2. Aggiungere campo personalizzato (elenco di selezione a selezione multipla) a Oggetto utente. I valori dovrebbero essere uguali a ciascuna caratteristica separata su cui le persone stanno lavorando. Può contenere fino a 500 valori, quindi dovresti essere sicuro.
3. Per account utente dello sviluppatore 1 impostare "feature1" nell'elenco di selezione. Imposta "feature2" per l'altro ragazzo.
4. Nel trigger scrivere uno if che verifica la presenza di ciascun valore di elenco di selezione e immette o lascia la chiamata alla classe rilevante. Questo spreca 1 query ma sei sicuro che verrà chiamato solo il codice che desideri.
5. Ogni sviluppatore continua a lavorare nel proprio file di classe.
6. Per il test di integrazione di entrambe le funzioni è sufficiente impostare il multiselect per contenere entrambe le funzioni.

Ho trovato questo trucco particolarmente utile quando il codice di un altro utente si è rivelato non ottimale e ha mangiato troppe risorse. Ho appena disabilitato la sua funzione sul mio account utente e ho continuato a lavorare.

Questo trucco può essere applicato anche alle pagine Visualforce (se è possibile dividerle in componenti).

Se non si vuole perdere interrogazione - utilizzare una logica del tipo "nome dell'utente contiene X";)

Answer 4

Date un'occhiata alla "Guida allo sviluppo del ciclo di vita: lo sviluppo delle imprese sulla piattaforma Force.com" . Puoi trovarlo su developer.force.com documentation page.

Answer 5

Abbiamo avuto/hanno lo stesso identico problema, abbiamo un team di 10 sviluppatori che lavorano su un'applicazione force.com che ha un sacco di classi apice (> 300) e pagine VF (> 300).

abbiamo iniziato a utilizzare Plug-in Eclipse, ma l'ho trovato:

1. troppo lento di lavoro al di fuori degli Stati Uniti ogni volta che un salvataggio è chiamato prende> 5 sezioni
2. a molti si fondono le questioni con un team di 10 sviluppatori

Successivamente abbiamo provato a sviluppare nelle nostre singole sandbox e quindi a unire il codice. Questo è ok per un piccolo progetto, ma quando hai molti file e hai bisogno di modifiche da inserire tra le sandbox diventa impossibile gestirle come l'unica cosa peggiore degli strumenti di sviluppo di force.com, sono gli strumenti di deployment/build di force.coms. Nessuna automazione è tutto manuale. Neanche un modo semplice per spostare i dati tra sandbox.

Il nostro terzo approccio consisteva nel modificare tutte le pagine VF e il codice Apex nel browser. (non usando il loro editor incorporato che compare nella metà inferiore della pagina perché è buggato e lento) ma usando semplicemente l'Editor regolare sotto setup> develop> Apex classes. Questo ha funzionato bene. Per completare questo abbiamo anche avuto un lavoro programmato che avrebbe scaricato tutto il nostro codice e salvato nel nostro repository SVN. Abbiamo anche creato uno strumento che ci consente di fare clic su una cartella sul desktop e comprimerlo dal suo contenuto e distribuirlo come risorse statiche per noi.

Tuttavia questo approccio ha ancora le sue scorciatoie, cioè è lento e doloroso sviluppare nel cloud, la loro idea (di Salesforce) di sviluppo come servizio è pazzesca. Inoltre non abbiamo un vero SCM, ma lo facciamo solo come backup.

La linea di fondo è force.com è un CRM e non una piattaforma di sviluppo, se è possibile? corri, fuggi, allontanati da esso il più velocemente possibile. Usarlo per qualcosa a parte un CRM è più un problema quindi vale la pena. Anche il loro slogan "Nessun software" mi fa ridere ogni volta

Answer 6

Si potrebbe prendere in considerazione l'idea di lavorare su risorse e pagine statiche separate e quindi fare attenzione quando si modificano oggetti, classi ecc. Se la maggior parte del vostro sviluppo avviene sul codice lato client (pagina, staticresource, componente/app di illuminazione) voi potrebbe essere interessato a questo progetto: https://github.com/bvellacott/salesforce-build. In ogni caso suggerisco caldamente di usare il controllo della versione. Se non su un server, almeno localmente sul tuo computer, nel caso in cui i tuoi colleghi sovrascrivano il tuo lavoro.