Mejores prácticas de servicio web .NET para múltiples desarrolladores

votos
1

Tenemos un gran proyecto ASP.NET que consta de varios cientos de informes. Estamos en el proceso de mover todas las consultas SQL (ejecutándose en una base de datos Oracle) en tres servicios web. Los servicios web se clasifican por comando, selecciones y consultas de informes. Tenemos que implementar un subconjunto de nuestro proyecto usando un backend SQL * Server en varias ubicaciones que están desconectadas de Internet. Por lo tanto, tener todas las conexiones a la base de datos y las consultas en los servicios web hace que la aplicación sea manejable y podemos extraer el subconjunto de informes y no tener que modificar el código. El proyecto está bajo control de fuente usando el software Serena ChangeMan.

El problema es que tenemos varios programadores y todos necesitan consultar los archivos de servicios web para trabajar en sus artículos. Acabamos de implementar la ramificación, pero lentamente se está convirtiendo en una pesadilla. Tenemos entregas mensuales de producción y, a veces, los artículos que se supone que entran en la construcción mensual se retienen hasta el mes próximo. La fusión se ha convertido en un proceso manual.

Realicé búsquedas en Internet y me sorprende que no haya podido encontrar ninguna buena página web de arquitectura de servicios web de Buenas prácticas. Hay muchas empresas grandes que deben haber enfrentado estos problemas.

¿La mayoría de los grandes grupos de desarrollo usan ramificaciones? Leí que Visual Studio Team System Database Edition podría proporcionar un código estándar que permita a la aplicación conectarse a diferentes bases de datos. ¿Compraría Team System sería el mejor método? ¿O alguien sabe dónde puedo encontrar la documentación que nos ayudará a resolver estos problemas?

Gracias, Lorie

Publicado el 09/12/2008 a las 19:20
fuente por usuario
En otros idiomas...                            


3 respuestas

votos
2

Este problema parece ser bastante independiente del propósito del software. El problema aquí es que tienes una pequeña cantidad finita de archivos con los que trabajarán múltiples desarrolladores diariamente. No tengo experiencia con el software Serena ChangeMan ni TFS aparte de jugar con eso. Tengo experiencia con un par de sistemas de control de versiones que usan un modelo de fusión / confirmación: CVS y Subversion . Estos son excelentes sistemas de control de versiones gratuitas ampliamente utilizados.

Si no está familiarizado con el modelo de combinación / confirmación, la idea aquí es que ningún desarrollador individual puede "verificar" y bloquear un archivo para cambios. Todos pueden descargar y hacer cambios a cualquier archivo. Cuando sea el momento de enviar estos cambios a la base de datos del código fuente, el software del repositorio evitará una confirmación si otro desarrollador ha realizado cambios en el archivo. La nueva versión se descarga y, en la mayoría de los casos, los cambios se fusionan automáticamente con sus cambios. Vuelve a probar y luego compromete esa versión. Este modelo es muy exitoso y muy escalable.

Habiendo dicho todo eso, incluso el modelo de fusión / compromiso no puede resolver la pena de tener un pequeño número de archivos con muchos desarrolladores haciendo cambios en dichos archivos. Recomendaría dividir su funcionalidad en más servicios web. Tal vez en lugar de tres, servicios web monolíticos, podría crear tres grupos de servicios web relacionados. Creo que esto, junto con el uso de un sistema de control de versiones con merge / commit resolverá sus problemas.

Los servidores CVS y Subversion se ejecutan en Windows, Mac y Linux. Hay una cantidad de clientes para cada uno, disponible en varios sistemas operativos. Estos incluyen clientes independientes, complementos de Visual Studio y complementos de shell. Otra ventaja es que tanto CVS como Subversion están disponibles desde la línea de comandos, lo que hace que las secuencias de comandos (piense en compilación automatizada) sean bastante sencillas.

Respondida el 09/12/2008 a las 19:34
fuente por usuario

votos
1

¿Por qué no segmentar su lógica en archivos de clases individuales que cada desarrollador puede revisar?

Respondida el 09/12/2008 a las 22:05
fuente por usuario

votos
0

Usamos SOA, pero también usamos SVN, que está más orientado a la fusión. Tal vez considere un sistema de control de fuente diferente?

Respondida el 09/12/2008 a las 19:27
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more