En este artículo quiero compartir mi experiencia de cómo resolvimos el problema de las tareas de "congelamiento" en nuestra empresa.
Trabajo en una startup que, como todas las startups, está experimentando una fase de crecimiento de 10 personas hace un año a 35 personas hoy, y el número de programadores durante este tiempo ha crecido de 5 a 25 personas y la mayoría de ellos llegaron en los últimos seis meses.
La estructura de la empresa, a pesar de su juventud, la llamaría anticuada, ya que nadie ha estado involucrado en los procesos de construcción. Con el crecimiento, nos dividimos en un equipo de desarrollo, un equipo de prueba y un equipo de desarrolladores, y todo funcionó más o menos.
El proceso de desarrollo, si se puede llamar un "proceso", fue así:
El trabajo del desarrollador terminó tan pronto como el código pasó la revisión del código y él lo mezcló en desarrollo.
El trabajo del probador terminó cuando él probó y smerzhil en la rama maestra.
Los Devops a veces hacían clic en el botón "Implementar para producir", luego de que el gerente del proyecto diario dijera: "No se han implementado durante mucho tiempo, ¿tal vez nos cancelarán hoy?"
Que bueno
- Una gran cantidad de automatización, por ejemplo, los estados en Jira se sincronizan con las etiquetas de sucursal en GitLab, una tarea en Jira se cierra después de una implementación para producir, el código se implementa automáticamente en entornos de prueba y preparación con una combinación en desarrollo y maestro respectivamente.
- Todo está cubierto de arriba abajo con pruebas.
- Los programadores escriben planes de prueba y prueban la funcionalidad principal.
Los problemas:
- Los probadores no pueden hacer nada durante una semana, porque las tareas se cuelgan en el estado code_review. Al final de la semana, los programadores aún hacen esta revisión y los probadores del lunes tienen mucho trabajo.
- Dado que después de la revisión del código, todo está solucionado en el desarrollo y si algo contiene un error, entonces no podemos implementar nada. Mientras un desarrollador corrige este error, otro puede apestar a otra característica que también contiene un error. Debido a esto, solíamos esperar una o dos semanas hasta que este brunch se estabiliza y el probador tiene tiempo para pisotearlo antes de que cualquiera de los desarrolladores se comprometa a desarrollar algo más.
- Implemente funciones en paquetes grandes, lo que agrega riesgos para probar o detectar algo deficientemente durante la implementación.
Describiré dos casos que nos dejaron en claro que es imposible trabajar más allá.
Entonces, por ejemplo, uno de los viernes tuvimos 15 brunches en el estado code_review, y el lunes todos cambiaron el estado a ready_for_test. Los probadores le dijeron al Daily cuánto nos aman. Y durante tres meses no pudimos terminar vendiendo, por varias razones, un par de características bastante grandes.
En primer lugar, descubrimos muchos code_review. Resultó que este problema puede resolverse simplemente gracias a las siguientes reglas:
- Solo tres tareas pueden estar en estado code_review. Esta es la regla más importante que no se puede violar.
- Si el programador ha finalizado el desarrollo y quiere traducir la tarea a code_review, busca ver si puede hacerlo (ver la regla 1).
- Si ya hay tres tareas en el estado code_review, primero ayuda a su colega a revisar el código. Y si en el proceso de revisión tiene comentarios o sugerencias para el cambio, entonces va a programar en pareja con un colega cuya tarea está revisando.
La idea principal es no dejar que el código se congele cuando ya está escrito, y proporcionar a los evaluadores un flujo uniforme de trabajo durante una semana.
Implementamos esto en una hora: nos reunimos, discutimos y fuimos a hacer una revisión y hacer programación de pares.
Si sucede que alguien olvida (y a veces alguien olvida) la primera regla, entonces la frase "Tenemos más de 3 PR en code_review" vuela inmediatamente a la sala de chat. Vamos a revisar !!! ". Al mismo tiempo, no hay una persona especial que se asegure de que no haya más de tres solicitudes de extracción, esto lo hacen los propios desarrolladores.
A pesar del hecho de que estos cambios impidieron que las tareas se congelaran, aún tuvimos problemas con las implementaciones y las fugas de errores en el desarrollo. Desde después de la revisión del código, siempre nos fusionamos en la rama de desarrollo, y se implementó automáticamente en el entorno de prueba para la prueba.
Esta solución era una especie de revisión, y luego era necesario realizar cambios básicos en los procesos.
Lo principal que decidimos hacer es mover las áreas de responsabilidad. Ahora, la compañía no tiene un equipo de desarrollo, un equipo de prueba o un equipo de desarrolladores independientes que transfieran las tareas entre sí y sean responsables solo de su parte.
Organizamos a los desarrolladores en varios equipos: uno para cada cliente, ya que tenemos un producto principal, pero está personalizado para cada cliente por un período de tiempo bastante largo (somos un híbrido de una empresa de productos y servicios). Ahora el envío de funciones al producto es responsabilidad del equipo. No hay equipos de prueba y devops familiares, pero hay QA como servicio y DevOps como servicio.
QA como servicio es un equipo que no prueba, pero asegura la calidad de los productos. Los ingenieros de control de calidad ayudan a los desarrolladores a escribir planes de prueba y participar en sesiones de prueba. Así que los liberamos de las pruebas manuales, y tuvieron tiempo para escribir pruebas de extremo a extremo y desarrollar herramientas para ayudar con las pruebas. También implementamos un sistema de monitoreo.
DevOps as a service es un equipo que desarrolla scripts de implementación, admite el trabajo de entornos de prueba y automatiza diversas tareas.
El nuevo proceso de desarrollo es este:
- Hay una tarea, del cliente, gerente de producto o uno de los mejores.
- En la etapa de planificación del sprint, lo llevamos al desarrollo.
- El desarrollador escribe el código en una rama separada para la tarea y cuando finaliza lo traduce al estado code_review.
- Uno de los colegas hace una revisión.
- Cuando la tarea ha pasado la revisión, el desarrollador fusiona en la rama con la tarea todo lo que se compromete a desarrollar e implementa esta rama en el entorno de prueba.
- Luego, planea una concentración que llamamos Test Session e invita a un ingeniero de control de calidad y colegas si es necesario.
- Un ingeniero de control de calidad verifica y refina el plan de prueba antes de la sesión de prueba.
- En la sesión de prueba, el desarrollador recorre todo el plan de prueba como una demostración. A veces, un plan de prueba se divide en partes y luego lo probamos en paralelo. Lo principal es que esto se hace en una sala separada para reuniones.
- Si después de probar los errores no se encontraron, entonces el desarrollador fusiona su código en la rama de desarrollo e inmediatamente en la rama maestra (esto es algo que aún no hemos cambiado, ya que todavía necesitamos actualizar los scripts de implementación). En el futuro planeamos dejar solo la rama maestra.
- Después de eso, el desarrollador comienza la implementación en la puesta en escena, solo para verificar que la implementación aún se ejecuta en un entorno idéntico al producto.
- Si todo está bien, despliéguelo inmediatamente al producto. La decisión de implementar o no la toma el equipo de desarrollo, pero QA tiene el derecho de detener las implementaciones si considera que se necesitan pruebas adicionales, o que es necesario esperar si es necesario para corregir algún error crítico en el producto.
Curiosamente, esta transformación lanzó algunos cambios adicionales, no en el proceso de desarrollo, sino en la planificación y cambió los temas de los que hablamos en el Daily.
Ahora porque el desarrollador es responsable de entregar la historia del usuario a la producción, en la planificación, comenzamos a escribir la historia del usuario de tal manera que cada uno sea independiente de los demás, y también podría implementarse de forma independiente, como una unidad desplegable. La historia de usuario se hizo más grande, pero se hizo más pequeña.
También en la planificación, no evaluamos el tiempo de desarrollo, sino que hablamos sobre cuándo planeamos implementar una característica.
En el Daily, no decimos que "he terminado el desarrollo", sino que decimos "hoy voy a implementar la función X" o "hoy estoy quitando el entorno de prueba, ¿quién tiene tiempo para ayudarme con la sesión de prueba?".
Como resultado, hemos desarrollado equipos de desarrollo independientes que poseen sus propios entornos de prueba y planean qué y cuándo implementar.