Mejores prácticas para la implementación de aplicaciones web .NET

Question

Trabajo en un lugar que considera que es una buena idea implementar el código directamente desde Team Foundation Server (TFS) en producción. Es casi imposible convencerlos de que esta es una mala idea porque pueden culpar al programador por verificar su código.

TFS no siempre es transparente acerca de lo que está haciendo. Como podrias saber. Y es posible verificar inadvertidamente sus cambios.

Quiero venderlos en algo mejor que esto, excepto que no sé lo que es. No debo utilizar las palabras clave de Google correctas, porque mientras una página o un enlace habla sobre la implementación, no habla de la implementación como parte de un ciclo de software. IE, "mejores prácticas en la implementación de .NET" hablará sobre publicar desde su proyecto, configuraciones de IIS, etc.

Tiene que haber una manera mejor. Código de congelación? ¿Codificación de código? ¿No hay alguna forma de implementar parte de la aplicación a la vez en lugar de toda la aplicación web?

Answer 1

¿Has echado un vistazo al TFS deployer? Lo he usado en uno de nuestros clientes y funciona de manera brillante. Funciona sobre el principio de capturar y actuar el evento planteado por TFS sobre el cambio de calidad de construcción en TFS. Una vez que se captura el evento, el servicio de despliegue TFS le proporciona la ruta de la ubicación de colocación y el usuario que cambió la calidad de construcción. La identidad del usuario le brinda la oportunidad de construir su matriz de seguridad y permisos a su alrededor, y la ubicación de colocación es útil si desea obtener el implementador y desplegar la construcción. Si es totalmente compatible con power shell, cmd y wix. Eche un vistazo a esta publicación de blog =>http://geekswithblogs.net/TarunArora/archive/2011/05/21/tfs-deployerndash-automate-deployments.aspx Estoy implementando tanto la web como la base de datos con el implementador de TFS, totalmente automatizado y registrado. Déjame saber si puedo proporcionar más detalles,

HTH Cheers, Tarun se han tomado

Answer 2

mejores prácticas para la implementación (OMI)

• copias de seguridad de base de datos/sitio web
• Todo está escrito: no se conecta manualmente a la base de datos para agregar en esa columna adicional
• Ya ha probado la implementación en un área de ensayo (en una copia de los datos en vivo)
• Tiene un plan de reversión (incluso si solo restaura las bases de datos)
• La implementación es repetible: debe contener todos los archivos necesarios para configurar el sitio según esa versión, no solo los archivos que cambiado
• Libera la misma compilación en cada entorno, no compila una nueva versión del código al pasar de la etapa a la producción
• Versión del servidor de compilación, no de una máquina de desarrollo individual, de esa manera debería sé el mismo sin importar quién haga la liberación.
• Cuanto menor sea el cambio que está liberando viven menos que pueden salir mal, la liberación debería ocurrir a menudo y que debe ser fácil

Técnicamente no hay nada malo con la liberación directamente de TFS a la producción, siempre y cuando' he probado suficientemente el código en el camino.

El entorno ideal que una gran cantidad de desarrolladores sueño de tener más o menos así

• Desarrollador cheques en código
• servidor de compilación agarra el código, asegura que se construye, ejecuta pruebas de toda la unidad
• El servidor de compilación implementa el código en una máquina de prueba y ejecuta pruebas automáticas
• Si todo se aprueba, el código se envía en vivo

Por supuesto, no hay muchas casas de desarrollo que tengan suficientes unidades/pruebas automatizadas en su lugar que se sientan seguras empujándolas en vivo tan rápidamente.

TFS Deployer hace mucho de su trabajo en segundo plano, la mayoría de la gente ni siquiera tendrá que saber que no es una característica de TFS. También se puede integrar en gran medida con todas las características de compilación y prueba para garantizar que la calidad del código sea buena desde el principio.

Código de congelación es una mala idea, no desea que sus recursos de desarrollo tengan un tiempo de inactividad en el que no puedan tocar el código. En su lugar, debería buscar una estrategia de ramificación que funcione para usted. Hay muchos por ahí, pero aquí está el principal 3 que se me ocurre:

• basada en la calidad - usted guarda una rama de Dev, uno para la estadificación y uno para la producción. A medida que el código pasa cada conjunto de pruebas, fusiona manualmente sus conjuntos de cambios en la siguiente rama. Esto también significa que puede corregir fácilmente un error en la producción sin liberar nuevos cambios que aún no están listos.

• Basado en versión - Hace todos los desarrolladores en la rama principal, cuando una versión está completa, la ramifica y solo toca esa rama para hacer correcciones de errores. Esto también le permite corregir los errores en vivo (o en cualquier otra versión que pueda estar respaldando) sin tener que revelar un nuevo código no probado.

• Característica basada - todo el desarrollo ocurre en nuevas ramas, una vez que se completa se fusiona de nuevo en el tronco. El tronco es la única rama que se libera.

Recomendaría que no se bifurquen hasta que se necesite la derivación. Mucha gente no sabe que puedes ramificar desde un conjunto de cambios específico/fecha. Esto significa que, si sabe cuándo se realizó un lanzamiento, puede ramificarlo cuando necesite aplicar una corrección de error, luego vuelva a fusionarlo en el tronco. Por supuesto, requiere mucha más disciplina al momento de la publicación, ya que siempre debe saber qué conjunto de cambios se está ejecutando en el servidor.

Por supuesto que podría estar leyendo su publicación de forma incorrecta, quizás no esté solicitando las mejores prácticas en materia de implementación, pero realmente le pregunto cómo hacer que su gerente crea que las cosas deben probarse antes de que se publiquen. Si es así, tienes un problema mucho más grande. Los desarrolladores (normalmente) no son buenos evaluadores, ciertamente no por algo que codificaron. Si no cuenta con probadores y procesos dedicados para hacer cumplir las pruebas unitarias y las pruebas automáticas, entonces realmente debería considerarlas primero.