Sviluppo agile con Dynamics CRM 2011

Question

Il mio team è responsabile di un sistema CRM di medie dimensioni (~ 1000 utenti). Attualmente il nostro CRM è costruito internamente su Java Servlet e stiamo passando a Microsoft Dyanmics CRM 2011. Dovremo fare molte personalizzazioni per soddisfare la nostra logica aziendale e i requisiti normativi.

Attualmente eseguiamo il rilascio bi-settimanale di funzionalità e correzioni di errori (scambia i vecchi file jar/jsp e scambia quelli nuovi). Le mie domande sono:

1. Con Dynamics CRM, come si farebbe qualcosa di simile? Soluzioni gestite?
   E se un utente effettuava personalizzazioni basate sulla v1 di una soluzione gestita distribuita, posso disinstallarla e installare una v2?
2. Come viene eseguito il controllo delle modifiche?
3. Quali sono le migliori pratiche e le cadute?

Sono molto nuovo nel mondo di Dynamics CRM quindi il tuo aiuto è molto apprezzato.

Answer 1

Questa è una discussione molto importante e non credo che sia la risposta migliore, dipenderà da ciò che si desidera e da come si lavora.Sono d'accordo con la maggior parte di Rickard detto, io vi darò alcuni link che mi aiutano molto stabilisco un processo di sviluppo:

1 e 3:

• http://gonzaloruizcrm.blogspot.pt/2012/01/managed-or-unmanaged-solutions-in-crm.html
• http://xrmconsultant.blogspot.pt/2011/11/crm-2011-solutions-problems-best.html
• http://channel9.msdn.com/posts/Merging-CRM-2011-Solutions
• http://www.dynamicscrmtrickbag.com/2011/05/28/dynamics-crm-2011-solutions-part-1/

2:

• http://intovsts.net/2012/12/28/integration-of-dynamics-crm-2011-solutions-with-tfs/
• http://community.dynamics.com/product/crm/crmtechnical/b/crmmusings/archive/2012/05/31/solution-packager-enable-source-control-for-solutions-in-crm-2011.aspx

Penso che si possa incontrato qui le informazioni utili per definire il vostro processo di sviluppo.

Answer 2

Se è necessario utilizzare le soluzioni gestite o non gestite, le soluzioni sono in discussione quindi non si otterrà una risposta "fai questo", o per essere più corretti forse si otterrà MOLTO "fare questo" che sarà diverso.

La mia esperienza è che è meglio utilizzare soluzioni non gestite per i sistemi che possiedi o gestisci e utilizzare le soluzioni gestite per i prodotti che vendi. La ragione per cui penso che sia abbastanza facile creare dipendenze tra soluzioni che le rendono difficili, se non impossibili, da rimuovere e in alcuni casi persino da aggiornare.

Non sarete in grado di disinstallare le soluzioni che hanno risorse a seconda di esse, tuttavia è possibile aggiornarle con una nuova versione.

Il controllo delle modifiche non è implementato nel sistema, quindi qualsiasi cosa necessaria deve essere gestita da qualche altra parte.

Questi sono i miei pensieri sull'argomento, probabilmente sentirete molto di più e sarei molto sorpreso se non differiscono. Ho trovato un articolo su MSDN che copre alcune delle tue domande.

Spero che questo aiuti.

Answer 3

1. Solo il mio modesto parere: va gestito a meno che non si sta sviluppando un prodotto stand-alone che si potrebbe desiderare di proteggere la sua integrità, quando installate dai clienti/utenti casuali, ecc Ma se si sta sviluppando/personalizzazione di un cliente specifico soluzione Non vedo alcun beneficio di andare gestiti. La mia esperienza è che probabilmente incontrerai problemi di dipendenza, ecc. Che ti faranno pentire della scelta di andare gestiti. Quindi, gestisci solo se stai pensando di vendere un prodotto isolato che devi proteggere in qualche modo.