prácticas recomendadas de desarrollo para trabajar con Siebel CRM?

Question

Me pueden estar trabajando con Siebel CRM pronto, y estoy en busca de asesoramiento sobre el uso de prácticas modernas de desarrollo y mejores prácticas empresariales.

En concreto me gustaría asesoramiento en las siguientes áreas:

• ¿Cómo debemos configurar el control de versiones (en concreto con Subversion)? ¿Qué tipo de estructura debe tener nuestro repositorio? ¿Cómo debemos manejar las ramas y etiquetas?
• ¿Cómo podemos hacer revisiones de código? ¿Cómo podemos mirar los cambios de configuración de revisión realizadas a través de las herramientas de Siebel, que no necesariamente tienen ningún "código"? Queremos revisar estos cambios para asegurar la calidad y la transferencia de conocimientos, 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 podemos verificar que sólo las cosas que figuran en nuestro registro de cambios son en realidad cambian cuando hacemos un nuevo despliegue?
• ¿Cómo podemos automatizar las pruebas de nuestra aplicación? Está probando incluso posible unidad con Siebel? Vi otra pregunta que sugiere plan de ahorro para las pruebas web, pero ¿hay otras opciones que el trabajo?
• ¿Hay otras cosas que podemos hacer para implementar prácticas de integración continua con nuestros esfuerzos de desarrollo de Siebel?
• ¿Qué recomendaciones tienes para convenciones de nombres y otras cosas que caerían tradicionalmente bajo las directrices de "estilo de codificación"?
• ¿Cómo debemos separar funciones de desarrollo de las funciones de administrador de Siebel? ¿Cuál debe ser nuestra construcción / prueba / mirada ciclo de despliegue como?

No es probable que voy a ser capaz de obtener cualquier nuevas herramientas costosas para esto, pero si hay una herramienta de pago que ofrece realmente un gran retorno de la inversión, no dude en mencionarlo.

Si usted tiene otras recomendaciones a lo largo de estas líneas, pero no se aborda específicamente por una de mis preguntas, no dude en añadir que también.

Answer 1

  

    

¿Cómo debemos configurar el control de versiones (en concreto con Subversion)?

  

utilizar la orientación proporcionada en la documentación de Siebel Tools. Pero Tenga en cuenta que Siebel no construye a partir de los archivos de SVN por lo que sólo será útil como una herramienta de archivo; no se puede gestionar su código o acumulación de SVN.

  

    

¿Qué tipo de estructura debe tener nuestro repositorio? ¿Cómo debemos manejar las ramas y etiquetas?

  

código de desarrollo de Siebel no se construye o se gestiona en el SVN así que esto es una cosa bastante inútil hacer. Sólo tenga en cuenta la fecha en que se construyó su SRF y exportó su Repo y combinar con una etiqueta o una rama en el SVN.

  

    

¿Cómo podemos hacer revisiones de código? ¿Cómo podemos mirar los cambios de configuración de revisión realizadas a través de las herramientas de Siebel, que no necesariamente tienen ningún "código"? Queremos revisar estos cambios para asegurar la calidad y la transferencia de conocimientos, así como el cumplimiento de las políticas de gestión del cambio.

  

El uso de Siebel herramientas para hacer esto. Se ha construido en la herramienta de 'comprobación' de errores obvios (todos los desarrolladores deben utilizar esto antes de que el check-in) y una herramienta de diferencias (que tendrá que comprobar en contra de una versión anterior del mismo objeto - que se podía arrastrar fuera del SVN si tu quieres). Normalmente automatizar la herramienta de comprobación de una vez al día y revisar los registros de salida, y construir a automatizar desde el servidor Siebel 5 veces al día y buscar errores durante la compilación. Diffs vía SVN y una herramienta de diferencias norma podría ser posible, pero los objetos de Siebel se almacenan como archivos XML como 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 podemos verificar que sólo las cosas que figuran en nuestro registro de cambios son en realidad cambian cuando hacemos un nuevo despliegue?

  

  

    

¿Cómo podemos automatizar las pruebas de nuestra aplicación? Está probando incluso posible unidad con Siebel? Vi otra pregunta que sugiere plan de ahorro para las pruebas web, pero ¿hay otras opciones que el trabajo?

  

QTP es la manera estándar para ir - verificación en el sitio web de Oracle para otros proveedores que puedan recomendar. También puede probar Sikuli.

  

    

¿Hay otras cosas que podemos hacer para implementar prácticas de integración continua con nuestros esfuerzos de desarrollo de Siebel?

  

En realidad no.

  

    

¿Qué recomendaciones tienes para convenciones de nombres y otras cosas que caerían tradicionalmente bajo las directrices de "estilo de codificación"?

  

Pedido la sección correspondiente de Siebel Estante por instrucciones de nomenclatura actual y utilizar estos siempre.

  

    

¿Cómo debemos separar funciones de desarrollo de las funciones de administrador de Siebel?

  

No está seguro de lo que quiere decir.

  

    

¿Qué debe nuestra construcción / prueba / mirada ciclo de despliegue como?

  

Construir una nueva SRF y exportar una nueva operación de Dev una vez por noche. Una vez que todo el trabajo de desarrollo ha sido comprobado en las pruebas unitarias y se hizo dar el siguiente SRF y Repo y empuje en el entorno de prueba. En este punto en el desarrollo normal del software que le ramifican su SVN y seguir desarrollando en el tronco, pero Siebel es diferente porque no se puede construir a partir de SVN y no se puede restaurar fácilmente una gran cantidad de archivos de SVN en su entorno de construcción, por lo que' re mejor esfuerzo para hacer las correcciones urgentes para la prueba ya sea en dev (y hacer una pausa en el desarrollo dev línea principal hasta que se hace) o en el entorno de prueba, y hacer backports feas para el entorno de desarrollo (que es lo que la mayoría de la gente hace, de hecho). Construir una nueva SRF y exportar una nueva operación de prueba una vez por la noche y una vez que eso es bueno,sacar una copia para su versión de producción. Trate de cumplir con los ciclos de no más de 4 semanas (1 semana para diseño / creación de prototipos de 1 semana para dev, 1 semana para la prueba, 1 semana para la corrección de errores y de implementación.) - por más tiempo que eso y los gastos generales de la planificación será demasiado grande.

Consejos para una vida más fácil: Evitar eScript excepto en Servicios comerciales (de lo contrario se vuelve inmanejable); utilizar todo el Siebel herramientas integradas en vez de rodar-su propio; tratar de evitar cualquier funcionalidad enrollable (que siempre parece una idea buena pero siempre destruye el rendimiento); mantener el número de pantallas y vistas a un mínimo absoluto; no construya vistas en las que debe ser la construcción de informes en su lugar; Siempre asegúrese de que las tablas EIM coinciden y extensiones de esquema que se hace - incluso si usted no utiliza EIM en este momento; tratan de construir objetos de integración para que coincida con el esquema lógico - que siempre son útiles (para los servicios web, la publicación XML) y un gran trabajo para construir después del hecho; prefieren Políticas de flujo de trabajo más eventos en tiempo de ejecución; no añada nuevas especificaciones de ordenación o búsqueda sin índices - siempre siempre siempre; no hacer enlaces por referencia a la tabla de lista de valores; parche siempre; Si el vendedor no dice que se puede hacer algo, nunca lo haría.

Answer 2

Hemos establecido un completo conjunto de herramientas de integración continua para nuestros sistemas Siebel consistentes en Subversion, Hudson, Jira, Siebel ADM y algunas cosas auto-escrita integrar todo.

Esta helepd mucho, a pesar de Siebel "código fuente" no es tan adecuado para CI estándar se aproxima como, por ejemplo, algún proyecto basado en Java.

Y, sí, es posible poner sus archivos - incluyendo SIF -. En su repositorio de Subversion y utilizar esto como fuente para sus despliegues

Estoy pensando en un blog acerca de esto en http://siebel-ci.blogspot.de/ -. Manténgase en sintonía

Answer 3

SVN / CVS no son adecuados para Siebel, algunas de las razones de ser
a) los objetos son objetos de Siebel db / SVN y CVS, etc tienda de SIF equivalente de los cambios.
Estos cambios son imposibles de consulta a excepción de algunas consultas básicas.
b) La integración entre herramientas Siebel y SVN es una integración de estructura flexible.
La integración ideal debe ser con el repositorio Siebel y herramientas invidual.

Tome un vistazo a nuestra herramienta objeto de la colmena que aborda muchas de las idas corto de unos archivos de control de versiones base.
http://www.enterprisebeacon.com/siebel_version_control_tool.html
Objeto de la colmena ha sido desde cero específicamente para el control de versiones de Siebel, algunas de sus características son:
1) Sobre la base de objetos de repositorio similar al repositorio de Siebel que almacena toda la historia de la versión.
Esto hace que sea muy fácil de cambios de conducta de consulta y revisiones de código en base a los cambios
2) Una interfaz gráfica de usuario basada en navegador que es similar a las herramientas de Siebel para consultar el historial de versiones (sin peinar SIF archivos de cambios).
3) La integración perfecta - directamente se integra con el repositorio de Siebel
. Ninguna instalación desordenado para el desarrollador invidual. 4) la presentación de informes de gran alcance (en tiempo real y por lotes) para identificar fácilmente los cambios a través de cualquier período de tiempo.
5) Oracle Exa-listo certificado.