¿Cuáles son las mejores prácticas en la implementación continua?

Yo sugeriría:

• Instalar con un botón
• Buenas pruebas automatizadas, para cada confirmación, cada candidato y después de la implementación
• Buenas pruebas de rendimiento de los candidatos y monitoreo del sistema implementado.
• Buena supervisión del comportamiento, por lo que puede decir (por ejemplo) que el registro de nuevos usuarios se abandonó después de una implementación

blekko no implementa continuamente nuestra base de datos interna, solo nuestro front-end. Para esto, necesitamos

• Cada demonio en el sistema debe reiniciarse independientemente y tener su propia versión de todas las bibliotecas de código +

Finalmente, debe mantener los ojos abiertos para las cosas que cambian para peor en el proceso general: ¿Las fallas intermitentes de las pruebas están causando problemas? ¿Tiene demasiados escapes de errores que causan demasiado impacto en los usuarios? ¿Sus codificadores son demasiado valientes o temerosos? Estos problemas pueden aparecer en una escala de tiempo de semana a mes, y debes estar atento para detectarlos antes de que te lastimen.

La implementación continua se trata de implementar pequeños cambios con frecuencia y configurar un ciclo de retroalimentación de los clientes a la ingeniería.

Todos los aspectos de implementación de un proceso de implementación continuo exitoso provienen de la identificación de errores y fallas que experimentan los clientes y luego de establecer mecanismos para evitar que las fallas vuelvan a ocurrir, al tiempo que se garantiza que los mecanismos no aumenten el tamaño de cada cambio implementado.

A finales de 2005, el proceso de IMVU podría definirse como código de verificación con frecuencia, empujar a producción, hacer clic en el sitio para asegurarse de que no haya nada roto. No es un proceso inusual para un equipo de ~ 4 ingenieros que trabajan en una aplicación web, pero aún contenía los elementos esenciales del “despliegue continuo”.

A medida que el uso del sitio y el equipo de ingeniería crecieron, agregamos procesos e infraestructura adicionales. Lo primero que agregamos fue un conjunto de pruebas. Escribimos la primera prueba porque nuestra aplicación cliente tenía un error que hacía que se bloqueara si el servidor devolvía un documento XML con formato incorrecto, y la primera prueba simplemente verificó que estaba bien formado. Una cosa simple, pero evitó 1-2 interrupciones del sitio por mes.

Este es un excelente ejemplo de cómo algo que será complicado para un equipo grande (múltiples tipos de pruebas para detectar diferentes clases de errores, corredores de prueba paralelos para mantener los tiempos de implementación en 5-10 minutos, protocolos para manejar fallas de prueba intermitentes, etc.) Puede comenzar como algo simple.

Otra área importante para la implementación continua es el monitoreo de la experiencia del cliente. Una vez más, comenzar de manera simple y agregar complejidad en respuesta a fallas reales es el camino a seguir. En IMVU comenzamos con un conjunto de gráficos que monitorean la métrica de la máquina (CPU y carga) y un sistema de alerta que verifica los tiempos de respuesta del servidor, entre otras cosas. Ambos son proxys imperfectos para la experiencia del usuario final, pero un lugar fácil para comenzar. Con el tiempo, agregamos gráficos y alertas adicionales sobre las métricas comerciales (por ejemplo, ingresos por minuto por método de pago, registros por minuto por canal) con una lógica de alerta cada vez más complicada ( http://www.evanmiller.org/poisso …).

Una tercera área importante para la implementación continua que reduce el riesgo de las implementaciones. La forma más sencilla de reducir el riesgo es asegurarse de que todos cometan código con frecuencia (también conocido como trabajo en pequeños lotes http: //www.startuplessonslearned …). Un pequeño cambio de código será mucho más fácil de revertir y depurar, que una gran característica desarrollada en el transcurso de semanas. Una segunda forma de reducir el riesgo es garantizar que tanto las implementaciones como las reversiones sean rápidas y confiables. Esto se vuelve más difícil a medida que aumenta el número de máquinas que se implementan: en IMVU creamos software para mantener múltiples versiones de la aplicación en todas las máquinas y cambiar entre ellas en cuestión de segundos.