¿Cuáles son algunas buenas estrategias para permitir que las aplicaciones implementadas sean corregibles?

Question

En un mundo ideal, nuestros procesos de desarrollo serían perfectos, lo que daría lugar a lanzamientos regulares que se probaron tan exhaustivamente que nunca sería necesario "reparar" una aplicación en ejecución.

Pero, lamentablemente, vivimos en el mundo real, y a veces los errores se nos escapan y no crían sus cabezas feas hasta que ya estamos ocupados codificando en el próximo lanzamiento. Y el error debe corregirse Ahora. No como parte de la próxima publicación programada. No esta noche cuando el tráfico se apaga. Ahora.

¿Cómo se puede hacer frente a esta necesidad? Realmente puede ir en contra de las buenas prácticas de diseño, como la refacturación de su código en bibliotecas de clase discretas.

El marcado manual y los procedimientos almacenados en un servidor de producción pueden ser una receta para desastres, pero también pueden evitar desastres.

¿Cuáles son algunas buenas estrategias para el diseño de aplicaciones y las técnicas de implementación para encontrar un equilibrio entre las necesidades de mantenimiento y las buenas prácticas de codificación?

Answer 1

[A pesar de que probamos mucho antes de divulgar,] Lo que hacemos es la siguiente:

Nuestro SVN se ve así:

/repo/trunk/ 
/repo/tags/1.1 
/repo/tags/1.2 
/repo/tags/1.3 

Ahora cada vez que nos liberamos, creamos una etiqueta que eventualmente verifique en producción. Antes de que hagamos la producción, hacemos etapas que son [menos servidores pero] prácticamente iguales a la producción. Las razones para crear una "etiqueta" incluyen que algunas configuraciones de nuestra aplicación en el código de producción son levemente diferentes y cometer esos cambios. Y luego pagar en el clúster de producción.

Ahora cuando necesitamos hotfix problema, lo solucionamos en etiquetas/x primero y luego svn update de la etiqueta y estamos bien. A veces pasamos por etapas, con algunos problemas (por ejemplo, correcciones menores/triviales como la ortografía) que pasamos por alto.

Lo único que debe recordar es aplicar todos los parches desde tags/x hasta trunk.

Si tiene más de un servidor, Capistrano es extremadamente útil para ejecutar todas esas operaciones.

Answer 2

Una estrategia es utilizar en gran medida los archivos de configuración externa de estilo declarativo para los diferentes componentes.

ejemplos de esto: cartografía

• acceso de base de datos/relacional de objetos a través de una herramienta como IBatis/IBatis.NET
• Logging a través de una herramienta como JLog/NLog
• La inyección de dependencia a través de una herramienta como Spring/Spring.NET

De esta manera, a menudo puede mantener los componentes clave separados en partes discretas, corrija una aplicación en ejecución sin recompilar y use el control de fuente sin problemas (particularmente en comparación con los procedimientos almacenados, que generalmente requieren un esfuerzo manual para controlar la fuente).

Answer 3

Dividimos nuestro código en código de marco y personalizaciones de negocios. Las clases de personalización de negocios se cargan usando un cargador de clases separado y tenemos una herramienta para enviar cambios a una instancia de producción en ejecución. cada vez que necesitamos un cambio en cualquier clase lo cambiamos y lo enviamos a una instancia en ejecución. la instancia en ejecución rechazará el cargador de clases anterior y usará un nuevo ataque de cargador de clases para cargar las clases nuevamente. Esto es similar a la implementación en caliente de JBoss EJB.