Consigliato pratiche di sviluppo per lavorare con Siebel CRM?

Question

I può essere lavorato con Siebel CRM presto, e sto cercando consigli su come utilizzare moderne pratiche di sviluppo e le best practice aziendali.

In particolare vorrei consigli sulle seguenti aree:

• Come dovremmo impostare il controllo di versione (in particolare con Subversion)? Che tipo di struttura deve avere nostro repository? Come dovremmo gestire i rami ei tag?
• Come possiamo fare le revisioni del codice? Come possiamo Peer Review modifiche di configurazione effettuate tramite Siebel Tools che non necessariamente hanno alcun "codice"? Vogliamo rivedere questi cambiamenti per la garanzia della qualità e il trasferimento di conoscenze, così come la conformità con le politiche di gestione del cambiamento.
• Che tipo di gestione del cambiamento funziona bene con Siebel? Come si fa a verificare che solo cose elencate nel nostro registro delle modifiche sono in realtà modificate quando facciamo un nuovo deploy?
• Come possiamo automatizzare i test della nostra applicazione? Sta testando anche possibile unità con Siebel? Ho visto un'altra domanda che suggerisce QTP per i test web, ma ci sono altre opzioni che il lavoro?
• Ci sono altre cose che possiamo fare per implementare pratiche di integrazione continua con i nostri sforzi di sviluppo Siebel?
• Quali raccomandazioni avete per le convenzioni di denominazione e le altre cose che tradizionalmente rientrare nel campo di linee guida "stile di codifica"?
• Come dovremmo separare i ruoli di sviluppo da ruoli Siebel di amministratore? Quale dovrebbe essere il nostro build / test / deploy ciclo di assomigliare?

Non è probabile che sarò in grado di ottenere qualunque nuovi strumenti costosi per questo, ma se c'è uno strumento a pagamento che offre davvero grande ROI, sentitevi liberi di parlarne.

Se avete altre raccomandazioni in questo senso, ma non specificamente indirizzata da uno dei miei domande, sentitevi liberi di aggiungere anche quello.

Answer 1

  

    

Come dovremmo impostare il controllo di versione (in particolare con Subversion)?

  

utilizzare le indicazioni fornite nella documentazione per Siebel Tools. Ma tieni presente che Siebel non costruisce dai file in SVN quindi sarà utile solo come uno strumento di archiviazione; non è possibile gestire il proprio codice o costruire da SVN.

  

    

Che tipo di struttura deve avere nostro repository? Come dovremmo gestire i rami ei tag?

  

Siebel codice di sviluppo non è costruito o gestito in SVN quindi questa è una cosa abbastanza inutile da fare. Appena nota la data in cui avete costruito la vostra SRF ed esportati tuo Repo e match con un tag o un ramo in SVN.

  

    

Come possiamo fare le revisioni del codice? Come possiamo Peer Review modifiche di configurazione effettuate tramite Siebel Tools che non necessariamente hanno alcun "codice"? Vogliamo rivedere questi cambiamenti per la garanzia della qualità e il trasferimento di conoscenze, così come la conformità con le politiche di gestione del cambiamento.

  

Usa Siebel strumenti per farlo. Esso è dotato di uno strumento di 'controllo' per ovvi errori (tutti gli sviluppatori dovrebbero utilizzare questo prima del check-in) e uno strumento diff (sarà necessario controllare contro una versione precedente dello stesso oggetto - che si potrebbe trascinare fuori di SVN se vuoi). Io di solito ad automatizzare la strumento di controllo una volta al giorno e rivedere i registri di uscita, e automatizzare costruire dal server Siebel 5 volte al giorno e cercare gli errori durante la compilazione. Diffs via SVN e uno strumento di diff standard potrebbe essere possibile, ma gli oggetti Siebel vengono memorizzati come file in SVN XML-like e così sono difficili da leggere a volte.

  

    

Che tipo di gestione del cambiamento funziona bene con Siebel? Come si fa a verificare che solo cose elencate nel nostro registro delle modifiche sono in realtà modificate quando facciamo un nuovo deploy?

  

  

    

Come possiamo automatizzare i test della nostra applicazione? Sta testando anche possibile unità con Siebel? Ho visto un'altra domanda che suggerisce QTP per i test web, ma ci sono altre opzioni che il lavoro?

  

QTP è il modo standard per andare - controllo sul sito web di Oracle per gli altri fornitori che si può raccomandare. Si potrebbe anche provare Sikuli.

  

    

Ci sono altre cose che possiamo fare per implementare pratiche di integrazione continua con i nostri sforzi di sviluppo Siebel?

  

Non proprio.

  

    

Quali raccomandazioni avete per le convenzioni di denominazione e le altre cose che tradizionalmente rientrare nel campo di linee guida "stile di codifica"?

  

Controlla la sezione appropriata di Siebel Bookshelf per le linee guida di denominazione corrente e utilizzare questi sempre.

  

    

Come dovremmo separare i ruoli di sviluppo da ruoli Siebel di amministratore?

  

Non sei sicuro di quello che vuoi dire.

  

    

Che cosa dovrebbe il nostro build / test / deploy ciclo di assomigliare?

  

Crea un nuovo SRF ed esportare un nuovo Repo da Dev una volta una notte. Una volta che tutto il lavoro dev è stata controllata in e unit test sono fatto prendere la successiva SRF e Repo e spingere nell'ambiente di test. A questo punto nello sviluppo di software normale che ci si diramazione tua SVN e continuare a sviluppare sul tronco, ma Siebel è diverso perché non si può costruire da SVN e non si può facilmente ripristinare un sacco di file da SVN nel vostro ambiente di sviluppo, in modo da' ri meglio per rendere hot fix per il test sia in dev (e mettere in pausa lo sviluppo dev mainline fino che si fa), o in un ambiente di prova, e fare brutti backport per l'ambiente di sviluppo (che è quello che la maggior parte delle persone in effetti). Costruire una nuova SRF ed esportare un nuovo Repo da test una volta una notte e una volta questo è un bene,scattare una copia per il rilascio di produzione. Cercare di attenersi a cicli di non più di 4 settimane (1 settimana per desing / prototipazione 1 settimana per dev, 1 settimana per prova, 1 settimana per correzioni di bug e di distribuzione.) - più di quello e il sovraccarico di pianificazione diventerà troppo grande.

Suggerimenti per una vita più facile: Evitare eScript tranne che nei servizi alle imprese (altrimenti diventa ingestibile); utilizzare tutte le Siebel built-in strumenti invece di rotolare-proprio; cercare di evitare qualsiasi funzionalità di roll-up (sembra sempre come una buona idea, ma distrugge sempre prestazioni); mantenere il numero di schermi e vista un minimo assoluto; non costruire vista quando si dovrebbe essere la creazione di report, invece; sempre fare in modo che le tabelle EIM partita e estensioni dello schema che si fanno - anche se non si utilizza EIM in questo momento; cercano di costruire oggetti di integrazione per abbinare il vostro schema logico - sono sempre utili (per i servizi web, editoria XML) e un inferno di un lavoro per costruire dopo il fatto; preferire Politiche flusso di lavoro più di run-time Eventi; non aggiungere nuovi ordinamento o di ricerca specifiche senza indici - mai mai mai; non fare link da parte di-riferimento alla tabella LOV; cerotto sempre; se il venditore non dice che si può fare qualcosa, non farlo.

Answer 2

Abbiamo istituito una completa integrazione toolchain continuo per i nostri sistemi Siebel, comprensivi di Subversion, Hudson, Jira, Siebel ADM e alcune cose di sé scritta integrando tutto.

Questa helepd molto, anche se Siebel "codice sorgente" non è adatto per CI standard di approcci come, ad esempio, qualche progetto basato su Java.

E, sì, è possibile mettere i file - tra cui SIF -. Nel repository Subversion e usare questo come sorgente per le distribuzioni

ho intenzione di blog su questo in http://siebel-ci.blogspot.de/ -. rimanete con noi

Answer 3

SVN / CVS non sono adatti per Siebel, un paio di motivi essendo
a) gli oggetti Siebel sono oggetti db e SVN / CVS ecc vendite SIF equivalente dei cambiamenti.
Questi cambiamenti sono impossibili da interrogare ad eccezione di alcune query di base.
b) L'integrazione tra strumenti di Siebel e SVN è un'integrazione flessibile.
L'integrazione ideale dovrebbe essere con il repository Siebel e gli strumenti invidual.

Date un'occhiata al nostro strumento oggetto Hive affronta molte delle carenze di un file di controllo di versione based.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Oggetto Hive è stato da zero appositamente per Siebel controllo delle versioni, alcune delle sue caratteristiche sono:
1) Oggetto In base repository simile a repository Siebel che memorizza tutte cronologia delle versioni.
In questo modo è molto facile da cambiamenti di query e le revisioni del codice di condotta in base alle modifiche
2) Una GUI basata su browser che è simile a strumenti di Siebel di query per la cronologia delle versioni (senza pettinatura SIF file per le modifiche).
3) Integrazione - direttamente integra con il repository Siebel
. Nessuna installazione disordinato per lo sviluppatore invidual. 4) di reporting potente (in tempo reale e batch) per identificare facilmente le modifiche oltre qualsiasi periodo di tempo.
5) Oracle Exa-ready certificata.