En mi empresa (inicio de la industria web de 3 años de edad), tenemos problemas frecuentes con el equipo del producto que dice "¡aaaah, esto es un parche de crisis ahora!" (¿no todos?)
Esto tiene un impacto en la productividad (y la moral) del personal de ingeniería, incluido en sí mismo. La gerencia ha pasado algún tiempo pensando en cómo reducir la frecuencia de estas solicitudes en el mismo día y ha encontrado la solución que vamos a lanzar cada semana. (Anteriormente habíamos estado haciendo uno cada dos semanas, que generalmente se deslizaba por un par de días más o menos).
Hay 13 desarrolladores y 6 probadores locales / 9 en alta mar; La teoría es que solo 4 desarrolladores (y todos los probadores) trabajarán en versiones pares, a menos que surja un trabajo que realmente requiera cierta experiencia específica de uno de los otros desarrolladores. Cada ciclo contendrá dos días de trabajo de desarrollo y dos días de trabajo de control de calidad (más 1 día de alcance / clasificación / ...).
Mis preguntas son:
(a) ¿Alguien tiene experiencia con esta duración del ciclo de lanzamiento?
(b) ¿Alguien ha oído hablar de esta duración del ciclo de liberación incluso cuando se intenta?
(c) Si (a) o (b), ¿cómo demonios lo haces funcionar? (También se agradecen las dificultades que se deben evitar, etc.).
(d) ¿Cómo podemos minimizar el daño si este esfuerzo falla?
fuente
Respuestas:
Ciertamente puede entregar cada semana, o incluso con más frecuencia. Por el momento, generalmente lanzamos cada dos semanas, pero no es inusual implementar la funcionalidad cuando llega algo sin previo aviso de uno de nuestros socios que sería irrelevante si esperamos el próximo ciclo. En algún momento de los próximos meses, me gustaría que pasemos a la entrega continua (los artículos se lanzan tan pronto como sea posible una vez que están 'listos') como estándar, pero aún no tenemos la confianza suficiente para hacerlo. lejos.
Lo fundamental es que necesita que su sitio web esté fuertemente cubierto por pruebas automatizadas, tanto pruebas unitarias como pruebas de aceptación de extremo a extremo / especificaciones ejecutables. Por implicación, esto también significa que su compilación está completamente automatizada. En el nivel de aceptación, utilizamos Robot Framework, que es excelente para construir rápidamente un conjunto de pruebas mantenible gracias a su enfoque de palabras clave. Para ver y sentir, nuestro probador en el sitio realiza algunas verificaciones rápidas, pero también tenemos un par de personas en India que realizan una verificación más exhaustiva en diferentes navegadores (hay sitios que ayudan con este tipo de cosas al tomar capturas de pantalla para usted, por ejemplo, BrowserLab )
No automatizamos completamente la implementación (el último paso requiere intervención manual, esta es una decisión consciente para nosotros), pero automatizamos todas las cosas, como garantizar que se usen las conexiones correctas de la base de datos, etc., con ciclos de implementación cortos Sería demasiado fácil cometer un error con este tipo de cosas.
Hay un buen libro reciente sobre entrega continua que tal vez desee consultar, lo he leído pero aún no lo he revisado en detalle. Sin embargo, lo que he leído hasta ahora concuerda bien con nuestras experiencias: Entrega continua: lanzamientos de software confiables a través de la automatización de compilación, prueba e implementación
En resumen, necesita un equipo altamente disciplinado, un alto nivel de automatización y, lo más importante de todo, un alto grado de confianza en esa automatización. Para mí, parece que cambiar a ciclos semanales en su caso puede ser un error: los parches de crisis sugieren otros problemas y debe trabajar para eliminarlos. Incrementar el ritmo podría empeorar la situación ...
fuente
Si está continuamente en modo de "liberación de crisis", diría que sería más prudente dar un paso atrás y reevaluar su código y su proceso. Obviamente, hay algún tipo de falla allí que se sigue repitiendo.
Si bien puede no ser del todo posible hacer esto en una verdadera escala de producción, pero probablemente valdría la pena tener al menos un miembro senior y algún otro subconjunto de desarrolladores y evaluadores dedicados a esta evaluación.
El "enfoque de 4 en un momento" no me parece un ganador claro. Eso significa un cambio de contexto constante, lo que significa mucha menos eficiencia.
Recuerde, si se apura constantemente para hacer cambios, es mucho más probable que cometa errores en esos cambios y rompa algo más mientras lo hace.
fuente
Los ciclos de lanzamiento de menos de una semana ciertamente se han logrado en la industria del software. Emplean la técnica llamada entrega continua (también llamada implementación continua ).
Hay una compañía que lanza 50 veces al día. Esta publicación de blog describe cómo lo hacen .
fuente
Parece que tu gestión es campeona del mundo ... ¿por qué no invertir en tu espíritu de equipo? Verá que los problemas desaparecerán por sí mismos.
(a) + (b) En mi humilde opinión, según el tamaño de su equipo, debería ser de dos semanas como máximo. Una semana funcionará para espectáculos individuales o equipos muy pequeños (como 2 o 3).
(c) + (d) Pero independientemente del tamaño de su equipo o proyecto, una de las primeras cosas que hago es automatizar la construcción y la implementación. Ahorro días si no semanas de trabajo al hacerlo en los primeros días de un proyecto.
Sus implementaciones deben hacerse con un solo clic. Desde el origen hasta la puesta en escena, luego desde la puesta en escena hasta la producción. Hay muchas herramientas para hacer esto posible. Desde ant / nant hasta cosas súper pesadas como Automated Build Studio .
Todo se puede automatizar desde la implementación de archivos hasta la actualización de la base de datos, incluidas copias de seguridad, notificaciones, informes, ...
fuente