pratiques de développement recommandées pour travailler avec Siebel CRM?

Question

je travaillerai avec Siebel CRM bientôt, et je suis à la recherche de conseils sur l'utilisation des pratiques modernes de développement et les meilleures pratiques de l'entreprise.

Plus précisément, je voudrais des conseils sur les domaines suivants:

• Comment devons-nous mettre en place le contrôle de version (en particulier avec Subversion)? Quel type de structure devrait avoir notre référentiel? Comment devrions-nous gérer les branches et les tags?
• Comment peut-on faire des revues de code? Comment pouvons-nous les changements de configuration pairs d'examen effectués par Siebel Tools qui ne sont pas nécessairement « code »? Nous voulons examiner ces changements pour l'assurance de la qualité et le transfert des connaissances, ainsi que le respect des politiques de gestion du changement.
• Quel type de gestion du changement fonctionne bien avec Siebel? Comment pouvons-nous vérifier que seules choses énumérées dans notre journal des modifications sont effectivement changé quand nous faisons un nouveau Déployez?
• Comment automatiser les tests de notre application? unité teste même possible avec Siebel? J'ai vu une autre question suggérant QTP pour les tests web, mais y at-il d'autres options que le travail?
• Y at-il d'autres choses que nous pouvons faire pour mettre en œuvre des pratiques d'intégration continue avec nos efforts de développement Siebel?
• Quelles recommandations avez-vous pour les conventions de nommage et d'autres choses qui traditionnellement tombent sous les directives « style de codage »?
• Comment devons-nous séparer les rôles de développement de rôles Siebel Administrator? Quelle devrait être notre build / test / deploy regard du cycle comme?

Il est peu probable que je serai en mesure d'obtenir de nouveaux outils coûteux pour cela, mais s'il y a un outil payant qui offre un retour sur investissement très grande, ne hésitez pas à le mentionner.

Si vous avez d'autres recommandations dans ce sens, mais pas spécifiquement abordé par l'un de mes questions, ne hésitez pas à ajouter aussi.

Answer 1

  

    

Comment devons-nous mettre en place le contrôle de version (en particulier avec Subversion)?

  

utiliser les indications fournies dans la documentation Siebel Tools. Mais veuillez noter que Siebel ne construit pas à partir des fichiers dans SVN il ne sera utile comme outil d'archivage; vous ne pouvez pas gérer votre code ou la construction de SVN.

  

    

Quel type de structure devrait avoir notre référentiel? Comment devrions-nous gérer les branches et les tags?

  

code de développement Siebel ne se construit pas ou géré SVN donc c'est une chose assez inutile de le faire. Il suffit de noter la date à laquelle vous avez construit votre SRF et exporté votre repo et correspondance avec une étiquette ou une succursale dans SVN.

  

    

Comment peut-on faire des revues de code? Comment pouvons-nous les changements de configuration pairs d'examen effectués par Siebel Tools qui ne sont pas nécessairement « code »? Nous voulons examiner ces changements pour l'assurance de la qualité et le transfert des connaissances, ainsi que le respect des politiques de gestion du changement.

  

Utiliser les outils Siebel pour ce faire. Il a construit dans l'outil de contrôle sanitaire pour les erreurs évidentes (tous les devs devraient utiliser cette avant check-in) et un outil de diff (vous devrez vérifier contre une ancienne version du même objet - que vous pouvez faire glisser sur SVN si tu veux). J'automatiser normalement l'outil de vérification une fois par jour et passer en revue les journaux de sortie, et construire Automatiser à partir du serveur Siebel 5 fois par jour et rechercher des erreurs lors de la compilation. Diffs via SVN et un outil standard diff peut-être possible, mais les objets Siebel sont stockés sous forme de fichiers XML comme dans SVN et sont donc difficiles à lire parfois.

  

    

Quel type de gestion du changement fonctionne bien avec Siebel? Comment pouvons-nous vérifier que seules choses énumérées dans notre journal des modifications sont effectivement changé quand nous faisons un nouveau Déployez?

  

  

    

Comment automatiser les tests de notre application? unité teste même possible avec Siebel? J'ai vu une autre question suggérant QTP pour les tests web, mais y at-il d'autres options que le travail?

  

QTP est le moyen standard pour aller - vérifier sur le site Web d'Oracle pour d'autres fournisseurs qu'ils peuvent recommander. Vous pouvez également essayer Sikuli.

  

    

Y at-il d'autres choses que nous pouvons faire pour mettre en œuvre des pratiques d'intégration continue avec nos efforts de développement Siebel?

  

Pas vraiment.

  

    

Quelles recommandations avez-vous pour les conventions de nommage et d'autres choses qui traditionnellement tombent sous les directives « style de codage »?

  

Commander la section appropriée de Siebel Bookshelf pour les directives de nommage et les utiliser toujours.

  

    

Comment devons-nous séparer les rôles de développement de rôles Siebel Administrator?

  

Je ne sais pas ce que vous voulez dire.

  

    

Quelle devrait être notre build / test / deploy regard du cycle comme?

  

Construire une nouvelle SRF et exporter une nouvelle prise en pension de Dev une fois par nuit. Une fois que tout le travail de dev a été vérifié dans et tests unitaires sont fait prendre la prochaine SRF et Repo et pousser dans l'environnement de test. À ce stade de développement de logiciels normal, vous souhaitez ramifier votre SVN et continuer à se développer sur le tronc, mais Siebel est différent parce que vous ne pouvez pas construire à partir de SVN et vous ne pouvez pas restaurer facilement un tas de fichiers de SVN dans votre environnement de construction, de sorte que vous » re mieux pour faire des correctifs pour le test soit en dev (et mettre en pause le développement de dev ligne principale jusqu'à ce qui est fait) ou dans l'environnement de test, et faire backports laid à l'environnement de développement (qui est ce que la plupart des gens en fait). Construire une nouvelle SRF et exporter une nouvelle prise en pension de test une fois par nuit et une fois ce qui est bon,prendre une copie pour votre version de production. Essayez de coller aux cycles de pas plus de 4 semaines (1 semaine pour desing / prototypage 1 semaine pour dev, 1 semaine pour le test, 1 semaine pour des corrections de bugs et de déploiement.) - plus longtemps que cela, et les frais généraux de la planification deviendra trop grande.

Conseils pour une vie plus facile: Évitez eScript sauf dans les services aux entreprises (sinon il devient ingérable); utiliser tous les outils Siebel intégré au lieu de rouler-votre propre; essayez d'éviter toute fonctionnalité enroulable (il semble toujours une bonne idée, mais il détruit toujours la performance); maintenir le nombre d'écrans et de points de vue à un minimum absolu; ne pas créer des vues lorsque vous devriez être la construction des rapports à la place; assurez-vous toujours que les tables correspondent EIM et extensions de schéma que vous faites - même si vous ne l'utilisez EIM en ce moment; essayer de construire l'intégration des objets pour correspondre à votre schéma logique - ils sont toujours utiles (pour les services Web, la publication XML) et un enfer d'un emploi à construire après le fait; préfèrent les politiques de flux de travail sur les événements d'exécution; ne pas ajouter de nouvelles spécifications de tri ou de recherche sans index - jamais jamais jamais; ne font pas de liens par référence à la table LOV; toujours correctif; si le vendeur ne dit pas que vous pouvez faire quelque chose, jamais le faire.

Answer 2

Nous avons mis en place un ensemble d'outils d'intégration continue complète pour nos systèmes Siebel composé de Subversion, Hudson, Jira, Siebel ADM et des trucs auto-écrit tout en intégrant.

Cette helepd beaucoup, bien que Siebel "code source" n'est pas l'approche appropriée pour CI standard, par exemple, certains projets Java.

Et, OUI, il est possible de mettre vos fichiers - y compris SIF -. Dans votre dépôt Subversion et l'utiliser comme source pour vos déploiements

Je prévois de blog à ce sujet dans http://siebel-ci.blogspot.de/ -. Restez à l'écoute

Answer 3

SVN / CVS ne conviennent pas pour Siebel, quelques raisons d'être
a) les objets Siebel sont des objets db et SVN / CVS etc magasin sif équivalent des changements.
Ces changements sont impossibles à requête, sauf pour certaines requêtes de base.
b) L'intégration entre les outils Siebel et SVN est une intégration à couplage lâche.
L'intégration idéale devrait être avec le référentiel Siebel et des outils strictement lié.

Jetez un oeil à notre outil objet Ruche, il aborde un grand nombre des courtes allées d'un contrôle des fichiers en fonction de la version.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Objet Ruche a été à partir du sol spécifiquement pour le contrôle des versions Siebel, certaines de ses caractéristiques sont les suivantes:
1) Objet de référentiel similaire au référentiel Siebel qui stocke toute l'histoire de version.
Cela rend est très facile à des changements de la requête et des revues de code de conduite sur la base des changements
2) Une interface graphique basée sur un navigateur qui est similaire aux outils Siebel pour interroger l'historique des versions (peignage pas sif fichiers de modifications).
3) Intégration transparente - directement avec le référentiel intègre Siebel
. Aucune installation de désordre pour développeur invidual. 4) rapports puissants (en temps réel et par lots) pour identifier facilement les changements sur une période de temps.
5) Oracle Exa prêt certifié.