Empfohlene Entwicklungspraktiken für Siebel CRM zu arbeiten?

Question

ich kann bald mit Siebel CRM arbeiten, und ich bin auf der Suche nach Beratung über den Einsatz moderner Entwicklungsmethoden und Unternehmen Best Practices.

Insbesondere würde Ich mag Beratung zu den folgenden Bereichen:

• Wie sollten wir die Versionskontrolle (speziell mit Subversion) einrichten? Welche Art von Struktur sollte unser Repository? Wie sollten wir Branches und Tags umgehen?
• Wie können wir tun, Code-Reviews? Wie können wir Peer-Review-Konfigurationsänderungen durch Siebel Tools, das jeden „Code“ nicht unbedingt haben? Wir wollen diese Änderungen für die Qualitätssicherung und Wissenstransfer sowie die Einhaltung der Change-Management-Richtlinien überprüfen.
• Welche Art von Change Management funktioniert gut mit Siebel? Wie überprüfen wir, dass nur in unserem Änderungsprotokoll aufgeführt Dinge tatsächlich geändert werden, wenn wir einen neuen deploy tun?
• Wie können wir die Prüfung unserer Anwendung automatisieren? Testet Einheit sogar möglich, mit Siebel? Ich sah eine andere Frage was darauf hindeutet, QTP für Web-Tests, sind aber noch andere Möglichkeiten, dass die Arbeit?
• Gibt es noch andere Dinge, die wir tun können, Continuous Integration Praktiken mit unseren Siebel Entwicklungsanstrengungen umzusetzen?
• Welche Empfehlungen haben Sie für Tagungen und andere Dinge zu benennen, die traditionell unter „Codierung Stil“ Richtlinien fallen würde?
• Wie sollten wir die Entwicklung Rollen von Siebel Administrator Rollen trennen? Was sollte unser Build / Test / deploy Zyklus aus?

Es ist nicht wahrscheinlich, dass ich in der Lage sein würde keine neue teueren Werkzeuge für diese zu erhalten, aber wenn es ein bezahltes Werkzeug ist, das wirklich großes ROI bietet, fühlen Sie sich frei, es zu erwähnen.

Wenn Sie entlang dieser Linien andere Empfehlungen, aber nicht ausdrücklich von einem meiner Fragen angesprochen, können Sie das auch hinzuzufügen.

Answer 1

  

    

Wie sollten wir die Versionskontrolle (speziell mit Subversion) einrichten?

  

, um die Führung in der Dokumentation für Siebel-Tools zur Verfügung gestellt verwenden. Bitte beachten Sie jedoch, dass Siebel baut sich nicht von den Dateien in SVN so wird es nur als Archiv-Tool nützlich sein; Sie können Ihren Code oder Build von SVN nicht verwalten.

  

    

Welche Struktur sollte unser Repository? Wie sollten wir Branches und Tags umgehen?

  

Siebel Entwicklung Code in SVN nicht gebaut oder verwalten so ist dies ein ziemlich nutzlos, was zu tun. beachten Sie einfach das Datum, dass Sie Ihre SRF gebaut und exportiert Ihre Repo und Spiel mit einem Tag oder Niederlassung in SVN.

  

    

Wie können wir tun, Code-Reviews? Wie können wir Peer-Review-Konfigurationsänderungen durch Siebel Tools, das jeden „Code“ nicht unbedingt haben? Wir wollen diese Änderungen für die Qualitätssicherung und Wissenstransfer sowie die Einhaltung der Change-Management-Richtlinien überprüfen.

  

Mit Siebel Werkzeuge, dies zu tun. Es hat sich in ‚Überprüfung‘ Tool für offensichtliche Fehler (alle Devs sollte diese, bevor sie einchecken verwenden) einen eingebauten und ein Diff-Tool (Sie werden gegen eine ältere Version des gleichen Objekts überprüfen müssen - was Sie von SVN in die Länge ziehen könnte falls Sie es wollen). Ich automatisieren normalerweise das Prüfwerkzeug einmal pro Tag und die Ausgabeprotokolle überprüfen und automatisieren Build von der Siebel-Server 5 mal am Tag und sucht Fehler bei der Kompilierung. Diffs über SVN und ein Standard-Diff-Tool könnte möglich sein, aber die Siebel-Objekte werden als XML-Dateien wie in SVN gespeichert und sind so hart, manchmal zu lesen.

  

    

Was für ein Change-Management funktioniert gut mit Siebel? Wie überprüfen wir, dass nur in unserem Änderungsprotokoll aufgeführt Dinge tatsächlich geändert werden, wenn wir einen neuen deploy tun?

  

  

    

Wie können wir die Prüfung unserer Anwendung automatisieren? Testet Einheit sogar möglich, mit Siebel? Ich sah eine andere Frage was darauf hindeutet, QTP für Web-Tests, sind aber noch andere Möglichkeiten, dass die Arbeit?

  

QTP ist der normale Weg zu gehen - die Prüfung auf der Oracle-Website für andere Anbieter, dass sie empfehlen können. Sie könnten auch Sikuli versuchen.

  

    

Gibt es noch andere Dinge, die wir tun können, Continuous Integration Praktiken mit unseren Siebel Entwicklungsanstrengungen umzusetzen?

  

Nicht wirklich.

  

    

Was Empfehlungen haben Sie für Tagungen und andere Dinge zu benennen, die traditionell unter „Codierung Stil“ Richtlinien fallen würde?

  

Zur Kasse in dem entsprechenden Abschnitt von Siebel Bücherregal für aktuelle Benennungsrichtlinien und verwenden diese immer.

  

    

Wie sollten wir die Entwicklung Rollen von Siebel Administrator Rollen trennen?

  

Nicht sicher, was Sie meinen.

  

    

Was sollte unser Build / Test / deploy Zyklus aus?

  

Erstellen Sie eine neue SRF und exportieren Sie eine neue Repo von Dev einmal pro Nacht. Sobald alle dev Arbeit wurde überprüft-in und Unit-Tests werden bei der nächsten SRF und Repo und Push in die Testumgebung durchgeführt nehmen. An diesem Punkt in der normalen Software-Entwicklung würden Sie Ihre SVN verzweigen und weiter auf dem Stamm entwickeln, sondern Siebel ist anders, weil Sie nicht aus dem SVN bauen können, und Sie können eine ganze Menge von Dateien aus dem SVN in der Build-Umgebung, so dass Sie nicht leicht wiederherstellen‘ erneut am besten Hot Fixes für Test entweder in dev zu machen (und Pause Hauptstrecke dev Entwicklung bis das geschehen ist) oder in der Testumgebung, und tun hässlich updates in die Entwicklungsumgebung (das ist, was die meisten Leute tatsächlich tun). Erstellen Sie eine neue SRF und exportieren Sie eine neue Repo von Test-einmal pro Nacht und einmal so gut ist,Snap eine Kopie für Ihre Produktionsfreigabe. Versuchen Sie, Zyklen von nicht mehr als 4 Wochen bleiben (1 Woche für desing / Prototyping 1 Woche für Entwickler, 1 Woche für Test, 1 Woche für Fehlerkorrekturen und Bereitstellung.) - mehr als das, und der Aufwand für Planung wird werden groß.

Tipps für ein leichteres Leben: eScript Vermeiden Sie außer in Business Services (sonst wird es unüberschaubar); Verwenden Sie alle Siebel integrierten Tools statt Roll Ihre eigenen; versuchen, eine Roll-up-Funktionalität zu vermeiden (es scheint immer wie eine gute Idee, aber es zerstört Leistung immer); halten, die Anzahl der Bildschirme und Ansichten auf ein Minimum; keine Ansichten bauen, wenn Sie Berichte stattdessen bauen werden sollten; stellen Sie sicher, dass immer EIM Tabellen übereinstimmen und Schemaerweiterungen, die Sie machen - auch wenn Sie jetzt nicht EIM verwenden; versuchen, Integration zu bauen Objekte Ihr logisches Schema passen - sie immer nützlich sind (für Web-Services, XML-Publishing) und ein Höllenjob zu bauen nach der Tat; Workflow-Policies über Laufzeit Events bevorzugen; fügen Sie keine neue Art oder Such Spezifikationen ohne Indizes - jemals jemals jemals; nicht durch Verweise auf die LOV-Tabelle machen; immer Patch; wenn der Verkäufer nicht sagt, dass man etwas tun kann, es nie tun.

Answer 2

Wir haben eine komplette Continuous Integration Toolchain für unsere Siebel-Systeme ein, die aus Subversion, Hudson, Jira, Siebel ADM und einige selbstgeschriebene Sachen Integration alles.

Dieses helepd viel, obwohl Siebel „Quellcode“ ist nicht als geeignet für Standard CI Ansätze wie, sagen wir, einige Java-basierte Projekt.

Und, ja, es ist möglich, Ihre Dateien abgelegt werden - einschließlich SIF -. In der Subversion-Repository und dies als source für Ihre Einsätze

Ich plane darüber bloggen in http://siebel-ci.blogspot.de/ -. Stay tuned

Answer 3

SVN / CVS sind nicht geeignet für Siebel, ein paar Gründe dafür sind
a) Siebel-Objekte sind db Objekte und SVN / CVS etc store SIF Äquivalent der Änderungen.
Diese Änderungen sind nicht zu Abfrage mit Ausnahme einiger Grund Abfragen.
b) Die Integration von Siebel Tools und SVN ist eine lose gekoppelte Integration.
Die ideale Integration mit der Siebel-Repository und invidual Tool sein sollte.

Werfen Sie einen Blick auf unserem Werkzeug Objekt Hive es greift viele der Unzulänglichkeiten einer Datei auf Basis der Versionskontrolle.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Objekt Hive wurde von Grund auf speziell für Siebel Versionskontrolle, einige seiner Funktionen sind:
1) Object Based Repository ähnlich wie Siebel Repository, dass speichert alle Versionsgeschichte.
Dies macht ist sehr einfach zu Abfrage Änderungen und Verhaltenskodices Bewertungen auf der Grundlage der Änderungen
2) Eine Browser-basierte GUI, die Siebel-Tool Abfrage für Versionsverlauf ähnlich ist (kein Kamm SIF-Dateien für Änderungen).
3) Nahtlose Integration - direkt integriert mit dem Siebel Repository
. Keine unordentliche Installation für invidual Entwickler. 4) Leistungsfähige Reporting (Echtzeit- und Batch) auf einfache Weise Änderungen über einen beliebigen Zeitraum zu identifizieren.
5) Oracle Exa-ready zertifiziert.