Imagine una situación fantástica: el director de la compañía decide implementar DevOps. Él mismo, sin la presión de los técnicos. Sin un ejemplo convincente de competidores. La administración misma reconoció que es imposible mejorar la calidad del producto, la previsibilidad, la transparencia y la repetibilidad de los procesos comerciales en el desarrollo e implementación de software sin las herramientas DevOps.
Presentado? ¿Funcionó? ¡Has superado con éxito la prueba para la imaginación más rica!
De hecho, por supuesto, esto no es así. Muy a menudo, la administración no depende de nuestras cosas de TI. Por lo tanto, tienes que convencer. Pero como?
Cuando se da un argumento para aumentar la cultura de comunicación entre programadores y administradores de sistemas, es fácil encontrarse con un argumento en contra: ¿no estás civilizado ahora o qué? O incluso pueden recordarle los costos en los que la compañía ya incurrió hace uno o dos años cuando se mudaron juntos a Agile. ¿Hay una característica en TI cada año que pueda avanzar en los procesos de una manera revolucionaria?
En cuanto a mejorar la calidad del producto, también puede tartamudear. Pero ten cuidado. Dado que la tarea de programar sin errores aún no se ha cancelado. Sí, no hay errores de ninguna manera, pero es por eso que la compañía tiene un "departamento completo de evaluadores", ¿verdad?
La previsibilidad de los procesos es generalmente un factor tan subjetivo, que es bastante difícil de justificar y evitar bromas sobre Wang y Nostradamus.
Además, si estamos hablando de una empresa típica, entonces, en una empresa así, lo más probable es que ya haya un equipo de TI establecido. Y este equipo en el viejo ritmo habitual (excepto Agile) ha estado trabajando juntos durante muchos años y apenas arde con el deseo (nuevamente) de cambiar algo. Todo se adapta a todos, excepto, por supuesto, el liderazgo. Lo que ve que en su software cualquier error se transmite constantemente, los términos de lanzamiento de nuevas versiones se modifican.
Por supuesto, se puede asumir una opción más cuando una persona llega a la empresa con experiencia en DevOps, representando claramente cuál es el problema y cómo se debe resolver. Y quién puede transmitir su opinión al liderazgo. Sin embargo, no esperemos un tío milagroso.
Y muchos rompen en esto. Comienzan a decir que nadie los apoya, que es imposible implementar nada en este pantano, y luego simplemente van a otra compañía, donde se repite el ciclo.
Resulta un círculo vicioso? No, solo poco a poco llegamos a la conclusión de que con un negocio solo necesita hablar en un idioma que él entienda, en el idioma del dinero. Para hacer esto, obtenemos la carta de triunfo principal de las piernas de manga ancha: la reducción del tiempo de comercialización. Necesitamos demostrar que gracias a DevOps, se lanzarán nuevas versiones del producto como hotcakes. Y dejemos el resto de los beneficios anteriores de la implementación de DevOps para la presentación final, que crearemos para el director, cuando todo salga bien. Muchos dirán que esto es demasiado obvio. No!
Necesitamos algo que nos lleve un mínimo de tiempo y recursos (después de todo, nadie permitirá cancelar los meses-hombre para la implementación de un determinado DevOps y no nos comprará servidores nuevos con urgencia), pero al mismo tiempo dará un resultado muy tangible (en realidad reducirá el tiempo necesario para -Mercado).
Primero necesita encontrar un cuello de botella, pero siempre es uno (el primer paso en la teoría de restricciones de Goldratt). Después de la implementación exitosa de Agile (y todo esto tiene sentido solo después de la implementación de Agile), en términos de desarrollo de software, todavía tienen que probar manualmente. Incluso con un grupo de manos libres, las pruebas de regresión pueden tomar de dos a tres semanas. Y por la forma en que los evaluadores "aman" realizar pruebas de regresión, lo sé todo.
Por lo tanto, hemos determinado que las pruebas son el cuello de botella. Entonces necesitas comenzar con su automatización. Muchos lo notarán: más fácil decirlo que hacerlo. Ya se han escrito millones de líneas de código, y es bueno que los programadores al menos cubran algo con pruebas unitarias. De hecho, no todo es tan aterrador como parece. La experiencia muestra que el 80% del resultado exitoso en forma de una disminución importante en el tiempo de comercialización se logra a través del 20% de los esfuerzos. Eso es lo que cuesta la automatización de pruebas en nuestro caso.
Absolutamente ley de Pareto, sí.
Y lo más importante, puede comenzar a probar la automatización antes de que la administración acuerde asignar recursos para la implementación de las partes restantes de DevOps. Un pequeño proyecto piloto que se puede hacer solo en una o dos semanas.
Pero al mismo tiempo, tal situación nos da la oportunidad de ganar una victoria espectacular y, lo más importante, rápida. Después de lo cual, teniendo una actitud positiva y la bendición del liderazgo, ya puede pedir dinero y recursos.
Para empezar, seguro, sus programadores ya están utilizando algún tipo de software de servidor para las compilaciones diarias. Puede ser TeamCity, Bamboo o Jenkins, no importa. Lo principal es que ya hay una parte de la automatización y debe usarse, y si no, es fácil implementarla en un día.
Primero necesita automatizar las pruebas de humo. ¿Pero cómo entender qué automatizar? Sí, solo mira lo que rompiste regularmente cuando publicas cambios en los últimos seis meses.
A continuación, debe crear varias pruebas para verificar el funcionamiento de los principales procesos empresariales. ¿Cómo identificarlos? Para preguntar a sus analistas / directores / representantes comerciales qué tipo de colapso, el director enojado se apresura a la oficina del programador y establece las tareas en voz alta.
Una semana, bueno, un máximo de dos para crear tales pruebas. El resultado es una respuesta muy rápida para errores globales.
Y aunque el proyecto está en modo de prueba de concepto, no es necesario que prepare la misma implementación automática del servidor para las pruebas y otros ajustes, sino que haga todo manualmente. Esta belleza se puede hacer con placer junto con los administradores.
Lo que esto conducirá no es difícil de adivinar. Los desarrolladores verán inmediatamente (y corregirán) sus errores. Los evaluadores se ahorrarán la rutina de realizar pruebas largas y tediosas para la regresión. Tendrán un par de días para probar solo aquellas partes del código que estaban sujetas a edición. Si exactamente. Y si no, vuelva al principio y hable nuevamente con analistas / directores / representantes comerciales sobre los procesos críticos del negocio.
Se eliminó el cuello de botella por el cual surgieron los frenos principales. Ahora todo lo que queda es lanzar algunas nuevas versiones en un entorno productivo, eliminar las estadísticas de "era / era" e ir con estos números a la gerencia. Beneficio!
Después de una victoria tan convincente, ya puede hablar sobre la automatización del despliegue de stands (al menos para las pruebas). A continuación, solicite fondos para el monitoreo y otras delicias de DevOps. Debe recordarse que los componentes restantes del sistema ya no tendrán un efecto sorprendente para las empresas.
Ejemplo de estudio
Al final del post, creo que sería apropiado dar un ejemplo de un proyecto completado con éxito para la implementación de DevOps, que fue implementado por nuestra empresa.
Un gran minorista tiene aproximadamente el 20% del negocio en una tienda en línea. Al mismo tiempo, es necesario reaccionar muy rápidamente a la situación del mercado y realizar los cambios necesarios en el software. Y a menudo Y de alta calidad. Cualquier jamba en el sitio puede afectar la conversión, los riesgos se expresan en dinero real.
Para reducir el tiempo de actualización y mejora de la calidad, se creó una plataforma de prueba automática especializada en la que se automatizaron las tareas de rutina para probar los cambios y la regresión del sitio web. Además, se construyó el proceso de interacción del grupo de pruebas automatizadas con los equipos de desarrollo. Esto permitió a los desarrolladores identificar y corregir de inmediato los defectos en el sistema actualizado, sin esperar la prueba de aceptación final.
Los representantes del minorista encontraron exitosa la experiencia y decidieron aplicarla a otros productos de software.
Y otro pequeño ejemplo, pero de la práctica de una gran compañía de seguros. Antes de la introducción de la automatización de pruebas, los lanzamientos se lanzaban cada seis meses. No porque el negocio lo exigiera, simplemente no funcionó con más frecuencia. Y el cliente solo quería. Entonces, dos meses después del inicio de la introducción de las herramientas de prueba automática, el equipo de TI cambió a versiones de dos semanas de lanzamientos de versiones.
Lo suficientemente significativo como para comenzar a hacer esto, ¿no?
Sergey Stramnov, arquitecto de preventa del Centro de soluciones de software de Jet Infosystems