Este es un problema común (y me gustaría que había leído antes) para todo el desarrollo, no sólo ASP.NET. Siendo uno de sus desarrolladores, mi equipo usa naturalmente BuildMaster internamente para todo el proceso de lanzamiento, y para la mayoría de los escenarios es gratis. Dentro de la herramienta, podemos realizar todas las construcciones estándar de CI para crear artefactos y luego configurar un proceso de automatización para implementar estos artefactos en cualquiera de los más de 40 servidores que tenemos alojados interna o externamente, según la aplicación o el entorno específico. .
Ya que menciona específicamente la implementación en diferentes entornos de prueba, este es un aspecto fundamental de la herramienta. La idea es modelar el flujo de trabajo del entorno (por ejemplo, Integración -> Control de calidad -> Producción) que ya tiene implementado y, esencialmente, promover una compilación desde el control de origen hasta la producción. La mayoría de las veces, es tan simple como agregar una acción de despliegue que despliega un artefacto en el entorno, otras veces puede ser mucho más complejo.
También se mencionan casualmente cambios en los archivos de configuración son parte de despliegue, que es otro componente incorporado a buildmaster. La idea que tuvimos fue usar la herramienta como el centro central para todos los archivos de configuración e implementaciones, asegurando así que los últimos cambios se apliquen automáticamente con una simple acción de "implementar archivos de configuración" en su plan de despliegue.
Una cosa que no mencionó con respecto a este proceso es el aspecto de implementación de la base de datos. La mayoría de las aplicaciones ASP.NET requieren una base de datos asociada, de lo contrario, podrían ser solo archivos HTML estáticos. Es crucial que el esquema de la base de datos se actualice a la versión de base de datos apropiada con cada implementación. No es de extrañar que haya un módulo dentro de BuildMaster que maneje esto también para usted. La idea es almacenar scripts DDL-DML dentro de la herramienta, y al ejecutar los scripts solo una vez por entorno, se asegura de que todas sus bases de datos en cada entorno estén actualizadas a medida que sus construcciones se despliegan a través de ellas. Otros scripts (por ejemplo, procedimientos almacenados, vistas, disparadores, etc.) son esencialmente archivos de código y, por lo tanto, pertenecen al control de fuente. Estas secuencias de comandos DROP-CREATE-CONFIGURE se pueden ejecutar todas y cada una de las veces con una simple acción de implementación.
Otra pieza del rompecabezas de implementación en la que la mayoría de los desarrolladores no piensan es la automatización de procesos. Muchos desarrolladores deben realizar aprobaciones o completar formularios de solicitud de cambio para realizar estos procesos manualmente. Nuevamente, todo esto está disponible como parte de la configuración automatizada del flujo de trabajo dentro de BuildMaster. Puede configurar bloqueadores que no permitan que la promoción indique el entorno de control de calidad a menos que hayan pasado todas las pruebas unitarias o bloquear la promoción al entorno de ensayo a menos que alguien del equipo de control de calidad apruebe la compilación y todos los problemas de la herramienta de seguimiento de problemas se resuelvan o cierren. ese lanzamiento particular.
Si bien me doy cuenta de que omití CC.NET de la respuesta, todas nuestras aplicaciones se crean y despliegan a través de BuildMaster para que ya no las necesitemos, aunque podríamos recoger fácilmente los artefactos de una ubicación de colocación e implementarlos en ambientes posteriores.
Hmm, aunque eso parece muy bueno ... no parece ayudar al escenario de la compilación automatizada (a menos que esté leyendo los documentos incorrectamente). –