¿Prácticas de desarrollo recomendadas para trabajar con Siebel CRM?

Es posible que pronto esté trabajando con Siebel CRM, y estoy buscando asesoramiento sobre el uso de prácticas de desarrollo modernas y mejores prácticas empresariales.

Específicamente, me gustaría recibir consejos sobre las siguientes áreas:

  • ¿Cómo deberíamos configurar el control de versiones (específicamente con Subversion)? ¿Qué tipo de estructura debería tener nuestro repository? ¿Cómo debemos manejar las twigs y las tags?
  • ¿Cómo podemos hacer revisiones de código? ¿Cómo podemos los cambios de configuration de revisión por pares realizados a través de Siebel Tools que no necesariamente tienen ningún "código"? Queremos revisar estos cambios para garantizar la calidad y la transferencia de conocimiento, así como el cumplimiento de las políticas de gestión del cambio.
  • ¿Qué tipo de gestión de cambios funciona bien con Siebel? ¿Cómo verificamos que solo las cosas que se enumeran en nuestro logging de cambios cambian realmente cuando hacemos un nuevo deployment?
  • ¿Cómo podemos automatizar las testings de nuestra aplicación? ¿Las testings unitarias son posibles con Siebel? Vi otra pregunta que sugería QTP para testings web, pero ¿hay otras opciones que funcionen?
  • ¿Hay otras cosas que podamos hacer para implementar prácticas de continuous integration con nuestros esfuerzos de desarrollo de Siebel?
  • ¿Qué recomendaciones tiene para nombrar convenciones y otras cosas que tradicionalmente se includeían en las pautas de "coding style"?
  • ¿Cómo deberíamos separar las funciones de desarrollo de las funciones de administrador de Siebel? ¿Cómo debería ser nuestro ciclo de compilation / testing / implementación?

No es probable que pueda get nuevas herramientas costosas para esto, pero si hay una herramienta paga que proporciona un gran retorno de la inversión, no dude en mencionarlo.

Si tiene otras recomendaciones en este sentido, pero que no se abordan específicamente con una de mis preguntas, siéntase libre de agregarlas también.

¿Cómo deberíamos configurar el control de versiones (específicamente con Subversion)?

utilice la guía proporcionada en la documentation de Siebel Tools. Pero tenga en count que Siebel no se comstack a partir de los files en SVN, por lo que solo será útil como herramienta de file; no puedes administrar tu código ni comstackr desde SVN.

¿Qué tipo de estructura debería tener nuestro repository? ¿Cómo debemos manejar las twigs y las tags?

El código de desarrollo de Siebel no está construido ni administrado en SVN, por lo que es una tarea bastante inútil. Simplemente tenga en count la date en que construyó su SRF y exportó su Repo y coincide con una label o bifurcación en SVN.

¿Cómo podemos hacer revisiones de código? ¿Cómo podemos los cambios de configuration de revisión por pares realizados a través de Siebel Tools que no necesariamente tienen ningún "código"? Queremos revisar estos cambios para garantizar la calidad y la transferencia de conocimiento, así como el cumplimiento de las políticas de gestión del cambio.

Usa Siebel Tools para hacer esto. Tiene una herramienta incorporada de "comprobación" para errores obvios (todos los desarrolladores deben usar esto antes de registrarse) y una herramienta de diferenciación (tendrá que comparar con una versión anterior del mismo object, que podría arrastrar desde SVN) si tu quieres). Normalmente, automatizo la herramienta de verificación una vez al día y reviso los loggings de salida, y automatizo la construcción desde el server de Siebel 5 veces al día y busco errores durante la compilation. Difiere a través de SVN y una herramienta de diferencias estándar podría ser posible, pero los objects Siebel se almacenan como files similares a XML en SVN y, por lo tanto, son difíciles de leer a veces.

¿Qué tipo de gestión de cambios funciona bien con Siebel? ¿Cómo verificamos que solo las cosas que se enumeran en nuestro logging de cambios cambian realmente cuando hacemos un nuevo deployment?

?

¿Cómo podemos automatizar las testings de nuestra aplicación? ¿Las testings unitarias son posibles con Siebel? Vi otra pregunta que sugería QTP para testings web, pero ¿hay otras opciones que funcionen?

QTP es el path estándar a seguir: consulte en el website de Oracle otros proveedores que pueden recomendar. También puedes probar Sikuli.

¿Hay otras cosas que podamos hacer para implementar prácticas de continuous integration con nuestros esfuerzos de desarrollo de Siebel?

Realmente no.

¿Qué recomendaciones tiene para nombrar convenciones y otras cosas que tradicionalmente se includeían en las pautas de "coding style"?

Consulte la sección correspondiente de Siebel Bookshelf para ver las pautas de nomenclatura actuales y utilícelas siempre.

¿Cómo deberíamos separar las funciones de desarrollo de las funciones de administrador de Siebel?

No estoy seguro de lo que quieres decir.

¿Cómo debería ser nuestro ciclo de compilation / testing / implementación?

Crea un nuevo SRF y exporta un nuevo Repo de Dev una vez por noche. Una vez que se haya registrado todo el trabajo de desarrollo y se hayan realizado las testings unitarias, tome la siguiente SRF y Repo e ingrese al entorno de testing. En este punto del desarrollo normal del software, ramificaría su SVN y continuaría desarrollándose en el tronco, pero Siebel es diferente porque no puede build desde SVN y no puede restaurar fácilmente una gran cantidad de files de SVN en su entorno de compilation, por lo que ' Es mejor hacer arreglos rápidos para probar en desarrollo (y poner en pausa el desarrollo de desarrollo de la línea principal hasta que esté hecho) o en el entorno de testing, y hacer feos backports en el entorno de desarrollo (eso es lo que la mayoría de la gente hace de hecho). Cree una nueva SRF y exporte una nueva Repo de Test una vez por noche y, una vez que esté bien, tome una copy para su versión de Producción. Intente seguir ciclos de no más de 4 semanas (1 semana para layout / creación de prototypes, 1 semana para desarrollo, 1 semana para testing, 1 semana para corrección de fallas e implementación) – más allá de eso y la sobrecarga de planificación se convertirá también estupendo.

Consejos para una vida más fácil: evite eScript, excepto en los services comerciales (de lo contrario, se vuelve inmanejable); utilice todas las herramientas integradas de Siebel en lugar de las suyas propias; trate de evitar cualquier funcionalidad roll-up (siempre parece una buena idea, pero siempre destruye el performance); mantener el número de pantallas y vistas a un mínimo absoluto; no construya vistas cuando debería crear informes en su lugar; siempre asegúrese de que las tablas EIM coincidan y las extensiones de esquema que realice, incluso si no usa EIM ahora mismo; intente crear Objetos de Integración para que coincidan con su esquema lógico; siempre son útiles (para web services, publicación en XML) y una tarea increíble después de los hechos; prefiera las políticas de flujo de trabajo sobre los events en time de ejecución; no agregue nuevas especificaciones de búsqueda o sorting sin índices, nunca; no haga enlaces de reference por reference a la tabla LOV; siempre parche; Si el vendedor no dice que puede hacer algo, nunca lo haga.

Hemos creado una cadena de herramientas completa de Integración Continua para nuestros sistemas Siebel que consiste en Subversion, Hudson, Jira, Siebel ADM y algunas cosas auto escritas que integran todo.

Esto ayudó mucho, aunque el "código fuente" de Siebel no es tan adecuado para los enfoques estándar de CI como, por ejemplo, un proyecto basado en Java.

Y, SÍ, es posible poner sus files, incluido SIF, en su repository de Subversion y usar esto como fuente para sus implementaciones.

Estoy planeando blog sobre esto en http://siebel-ci.blogspot.de/ – estad atentos.

SVN / CVS no son adecuados para Siebel, algunas razones son
a) Los objects Siebel son objects db y SVN / CVS, etc. almacenan sif equivalente a los cambios.
Estos cambios son imposibles de consultar a exception de algunas consultas básicas.
b) La integración entre las herramientas Siebel y SVN es una integración débilmente acoplada.
La integración ideal debería ser con el repository de Siebel y las herramientas inviduales.

Eche un vistazo a nuestra herramienta Object Hive que aborda muchas de las deficiencias de un control de versiones basado en files.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Object Hive ha sido desde cero específicamente para el control de versiones de Siebel, algunas de sus características son:
1) Repositorio basado en objects similar al repository de Siebel que almacena todo el historial de versiones.
Esto hace que sea muy fácil consultar cambios y realizar revisiones de código basadas en los cambios
2) Una GUI basada en browser que es similar a las herramientas de Siebel para consultar el historial de versiones (no se combinan los files sif para cambios).
3) Integración perfecta: se integra directamente con el repository de Siebel.
Sin installation complicada para el desarrollador personal. 4) Informes potentes (en time real y por lotes) para identificar fácilmente los cambios en cualquier período de time.
5) Oracle Exa-ready certificate.