Tenemos DevOps Vamos a despedir a todos los probadores

¿Es posible automatizar algo? Entonces despediremos a todos los probadores, por supuesto. ¿Por qué se necesitan ahora? No quedan pruebas "manuales". Justo después de todo?

Esta es una historia sobre el futuro de las pruebas en términos de DevOps. Habrá cifras concretas y conclusiones puramente prácticas, cómo resulta que los buenos especialistas siempre tienen trabajo. (¡O no hay trabajo! Mira la fotografía de Shakespeare y ten miedo, tu destino se decidirá ahora).



El material se basa en una transcripción del informe de Baruch jbaruch Sadogursky, Promotor defensor de JFrog. La versión de texto y el video del informe están debajo del corte.



Hola a todos! ¿Ves una cita de Shakespeare en la imagen de arriba? Este es Henry VI, la propuesta de matar a todos los abogados. Entiendes, desde entonces tenemos más formas vegetarianas para deshacernos de las profesiones equivocadas. No mataremos a nadie, solo tómalo y despide a todos.

Más precisamente, existe tal oportunidad. ¿Vamos a despedir a alguien? Hablemos .



Esta es Vasya Una mañana, viene al trabajo y pasa por la sala de reuniones principal. Y allí su jefe da la bienvenida a un nuevo consultor. Un consultor de eficiencia llega a la compañía y dice: "Haremos DevOps como en netflix *. Volamos específicamente a Silicon Valley para una conferencia, y allí nos dijeron cómo les iba en netflix ”.

* descargo de responsabilidad: Netflix se usa a menudo en este artículo como el ideal inalcanzable de DevOps. Este uso es una palabra familiar.

Una discusión sobre si Netflix realmente tiene los DevOps perfectos está más allá del alcance de este artículo (lo más probable es que no).

Instalan Spinnaker, luego lanzan Chaos Monkey y todo está automatizado. Y haremos esto y seremos muy efectivos.

El jefe pregunta, ¿qué pasa con los probadores? “Y aquí, como en Netflix, libertad y responsabilidad . Los desarrolladores escribirán las pruebas ellos mismos ".

Y luego Vasya se enferma, porque mira su tarjeta de presentación, y allí ...



Vasya comienza a preocuparse: la última vez que vino un consultor de eficiencia, su amigo, Natasha, que trabajaba como administrador del sistema, fue despedido. Porque en todas partes DevOps. Y luego se da cuenta de que pronto todo será muy malo.

Pero, por supuesto, Vasya se despierta.



Mi nombre es Baruch Sadogursky, soy promotor de desarrollo en JFrog. El editor de este artículo solicitó específicamente escribir un par de párrafos para que nadie dude de mi autoridad para decirnos cómo vamos a despedir a los evaluadores.

JFrog es una startup de Silicon Valley, nuestra última valoración fue de más de mil millones de dólares. Somos oficialmente unicornio y hacemos automatización de DevOps. Nuestros productos - Artifactory , Xray , Mission Control, etc. - herramientas para la automatización que convierte la planta de procesamiento de carne Omsk en netflix.

Yo mismo no soy un probador, así que, tal vez, diré algunas tonterías. En el programa de la conferencia, en el que se leyó originalmente este informe, hay una designación especial: una imagen con un cóctel molotov. Entonces, el orador llevará algún tipo de herejía, y la audiencia se quemará. Esto es sobre mi. En Twitter, soy @jbaruch . Como ya entendiste, soy un chico muy alegre, tengo que seguirlo con urgencia.

Tengo noticias para ti: el 80% de los desarrolladores escriben pruebas. Los desarrolladores están satisfechos con todo tipo de encuestas. Bueno, JetBrains está contento con el muy buen Informe del estado del ecosistema del desarrollador . Preguntan quién escribe pruebas unitarias.

• 59% escribe por su cuenta
• El 11% ve las pruebas unitarias en su código y no sabe de dónde provienen.

En total, el 70% de los desarrolladores utilizan pruebas unitarias. Esto es asombroso

Hubstaff realiza un estudio más profundo sobre las pruebas con la ayuda de desarrolladores, es un poco más antiguo: 2014. Según él:

• 85% de los desarrolladores escriben pruebas unitarias,
• 15% no;
• El 40% trabaja según la metodología de desarrollo basada en pruebas;
• buena cobertura: entre 34 y 66 entre el 31% de los desarrolladores.

La gran mayoría de los desarrolladores afirman que también prueban algo con bolígrafos. Mienten, por supuesto, pero las estadísticas son las siguientes.

Desde 2011, nuestra cita favorita es: "Toda empresa es una empresa de software" . Incluyendo, por supuesto, la fábrica de carne Omsk en la que trabaja Vasya. En todas partes hay software y todos en este software están tratando de ganar dinero. ¿Qué quieren las empresas? Reme el botín con una pala. ¿De dónde viene el dinero? De clientes satisfechos. ¿Qué quieren los clientes? Nuevas características ¿Y cuándo quieren nuevas funciones? Ahora!

El CEO del cómic, Dilbert, es el jefe jefe de Vasya. También escuchó todo tipo de informes interesantes. Él cree que si los clientes quieren nuevas funciones, entonces necesitan lanzar nuevas funciones con más frecuencia. Es lógico. Para hacer esto, reduzca la fricción en los equipos.

¿Debo liberar más a menudo? Por ejemplo, en 2017, Java cambió a lanzamientos más frecuentes, porque todos quieren funciones y, al parecer, necesitan ser lanzadas más rápido. Cada seis meses sale un nuevo Java. Pero nadie lo usa.

Recientemente tuvimos Joker, alojamos Java Puzzlers en él. Al principio, siempre preguntamos quién está en qué Java, para entender qué piezas del rompecabezas preguntar.

La imagen no ha cambiado: el 80%, o incluso más, todavía están en Java 8, que se lanzó hace cien años. Nadie toma el noveno, ni el décimo, ni el undécimo.



Para comprender por qué no lo están utilizando, debe comprender cómo tomamos una decisión sobre si tomar actualizaciones o no. Imaginemos cómo colocamos las actualizaciones: el sistema operativo, las aplicaciones, el navegador, lo que quieran.

¿Cómo ponemos actualizaciones?

Llega una notificación de que tenemos una actualización, instalemos un nuevo sistema operativo. ¿Queremos esto? ¿Hay algo útil allí, o tenemos una caja registradora que se ejecuta en Windows 98 Embedded, y no necesitamos nada más?

Si queremos esta actualización, la siguiente pregunta es cuán peligroso es. Una cosa es cuando Facebook se actualiza, y tenemos desplazamiento, y no podremos dar me gusta. Es otra cosa cuando el sistema de soporte vital está apagado en el hospital. Si no nos importan los riesgos, vamos a actualizar. Si hay riesgos, entonces la pregunta es confiar en el que está implementando la actualización.

Antes no había problemas con Apple: hay un nuevo sistema operativo, vamos a tomarlo. Era antes, y ahora tenemos miedo de ser actualizados, no existe una confianza anterior. Si confiamos, no hay problema, estamos actualizando. Si no confiamos, debe realizar una prueba.

Hacemos lo que se llama pruebas de aceptación. Aquí nos dicen: ha surgido un nuevo Java y, por ejemplo, somos Baidu. Highload, 100,500 servidores, nube, JVM en todas partes. Tomamos parte de los servidores, comenzamos a cambiar Java. Un grupo de ingenieros tiene que hacer algo y comprobarlo todo. Una vez cada tres años es normal, pero una vez cada seis meses ... ¿Estás jodido? Solo lo revisaremos durante seis meses. Por supuesto, no tomaremos esta su nueva Java.

Por lo tanto, si podemos verificar rápidamente, vale la pena actualizarlo. Pero si tiene que verificar durante mucho tiempo, puede omitir un par de versiones. No pasará nada si nos arrastramos de la octava versión inmediatamente a la duodécima.

El problema está en la confianza. Si no confiamos, la actualización será difícil. Si se resuelve el problema de confianza, no hay problemas con las actualizaciones. O tenemos una función, o nos importa un comino.

Toma Chrome Él, comenzando con alguna versión, actualiza sin preguntar a nadie. Los riesgos allí son pequeños, pero siguen ahí. Pero, por otro lado, confiamos en aquellos que escriben Chrome. La mayoría de las veces, cuando sale una nueva versión de Chrome, no hay nada allí. De hecho, no tenemos problemas con la confianza, y estamos en este camino.



Tenemos una actualización, los riesgos no son importantes, confiamos: actualizamos. Y no nos preguntarán si queremos o no, por lo tanto, siempre actualizaremos. Esto es exactamente lo que se está haciendo.

Imagine que netflix está lanzando una nueva actualización, y ahora podemos omitir no solo los subtítulos y los protectores de pantalla, sino también todos los lugares aburridos. Actualización genial? Genial ¿Lo queremos a él? Queremos ¿Funcionará? Lo más probable es que sí. En un caso extremo, iremos a YouTube, veremos los dibujos animados si netflix está roto.

La cuestión de la confianza es crítica. ¿Cómo lo resolvemos? La palabra "nosotros" significa los dos cofundadores de JFrog, Fred Simon (Fred Simon), Yoav Landman (Yoav Landman) y su humilde servidor. Escribimos un libro que aconseja cómo resolver este problema.

Digamos que convencimos a nuestro CEO, leyó Liquid Software y ahora comprende por qué necesita una actualización. Le pregunta al consultor cómo actualizaremos más a menudo. Ágil! DevOps! ¿Qué es DevOps?

Devops

Déjame contarte una pequeña teoría de lo que es DevOps, ya que ganamos dinero con eso. Echa un vistazo a la imagen, tuvimos estos grupos, equipos, departamentos:


Hay desarrolladores, hay Ops, administradores de sistemas que toman lo que escribieron los desarrolladores y los lanzan al producto. Y en el medio entre los desarrolladores de Ops, hay QA que están probando. Es decir, los desarrolladores se sentaron, escribieron, luego lo llevaron a los probadores, lo probaron, lo asignaron a los administradores del sistema y lo cargaron a las ventas. Para esto, teníamos departamentos separados.

El idioma ruso es hermoso: el departamento siempre está separado , esta es la raíz de la palabra. En inglés, este encanto no es, por lo tanto, estos diferentes departamentos se llaman silos . La mejor traducción de esta palabra al ruso fue dada por Anton Weiss, quien fue el mejor orador en DevOops . Él llama a los silos "pozos". Diferentes departamentos: pozos profundos. Para cargar algo de trabajo allí, debe bajar y luego sacar el trabajo de allí: levantarse. Es más conveniente hacer esto en grupos. ¿Cómo agrupamos las cosas que sacamos del pozo?

Naturalmente, en cubos. Es decir, tenemos tales "cubos de trabajo". Los desarrolladores escribieron algo en el pozo, lo cargamos en cubos, lo sacamos del pozo, llevamos los cubos a los probadores y se los bajamos al pozo.

Se realizan muchas acciones para transferir el trabajo entre diferentes pozos. Cuando agrupamos tareas para ahorrar en este trabajo, comenzamos a cargar estos depósitos. Por supuesto, cuanto más grande sea el depósito, más ahorraremos en este proceso de transferencia. Por lo tanto, los cubos se hacen grandes.

¿Cuál es el problema con los cubos grandes? El hecho de que se llenen por mucho tiempo. Por lo tanto, cuando tenemos características importantes que necesitan ser lanzadas con urgencia para la producción, porque hay una línea de clientes con dinero, no podemos hacer esto. Tenemos pozos, mejor recogemos más en un cubo. Por lo tanto, las características importantes están esperando todas las tonterías, siempre que tengamos suficiente para llenar esto bien. Esto es malo, como entiendes. Esto se resuelve por el hecho de que obtenemos y mezclamos todos estos pozos.

¡No es mi culpa! Simplemente tomé los tres colores originales, los puse uno encima del otro, y este color resultó. Ahora todos hacemos todo. Tenemos ingenieros que son Shvets, Reapers y Dyuras. Estos son Dev, QA y Ops. Escribió y probó el código, y luego lo puso todo en producción, como un unicornio.

¿Cuál es el problema de los unicornios? Que no existen. Y los que existen, han sido contratados por netflix. Por lo tanto, nos queda hacer la mezcla.

La mezcla

Tenemos una cultura común, objetivos comunes. Dejamos los pozos, ahora estamos todos juntos, pero aún tenemos una especialización profunda. Un desarrollador sigue siendo más un desarrollador que Ops, y un probador es más un probador que un desarrollador. Sin embargo, entienden todo. Entienden lo que están haciendo, por qué lo están haciendo y cómo funciona.

Es decir, tenemos personas en forma de T, "personas en la forma de la letra T".

Tienen una profunda especialización, saben muy bien lo que están haciendo. Ellos saben muy bien y todo lo demás también. Por ejemplo, los desarrolladores entienden un poco cómo probar correctamente, cómo los procesos de diseño en prod y así sucesivamente.

DevOps es:

• La cultura de lo que ahora tenemos objetivos comunes, entendemos lo que hacemos juntos.
• Automatización para lanzar más a menudo.

Velocidad y calidad

Hablemos de la suposición de que existe una relación inversa entre velocidad y calidad. En términos generales, cuanto más rápido lancemos, peor será la calidad. Y viceversa: si no tenemos prisa, tendremos tiempo para probar todo a fondo. ¡Tenemos una compensación!

Para entender si esta dependencia realmente existe, pasemos a los artículos científicos y hablemos sobre el informe del estado de DevOps de la organización DORA. Le recomiendo que eche un vistazo a este informe.

¿Cuánto puedes confiar en él? El informe dice que más de cinco mil personas fueron entrevistadas en cinco años, y en 2018 casi 2000 personas. Esta es una muestra muy grande, y sobre la base de tal cantidad, por ejemplo, se hacen pronósticos en las elecciones estadounidenses. Por lo tanto, se puede confiar en la investigación.

Además, Nicole Forsgren, que dirige DORA, a diferencia de nosotros, es científica, por lo que todo es serio allí. Veamos qué nos dice DORA sobre esta correlación inversa.

En primer lugar, dividieron a todos los encuestados en tres grupos: de bajo rendimiento, de rendimiento medio y de alto rendimiento.

Además, hay Elite. Esto es Netflix (en realidad no, vea el descargo de responsabilidad anterior).



Como puede ver, las proporciones están cambiando. Naturalmente, hace cinco años había muchos más artistas de bajo rendimiento, ahora hay muchos más artistas de alto rendimiento, porque ya estamos empezando a entender un poco lo que estamos haciendo.

Esto es de alguna manera extraño. Resulta que Medium se está probando con mangos más que Low. Por qué Sí, porque Low no prueba nada en absoluto.



Tienen una tendencia, un gráfico llamado curva J, que muestra la correlación o la correlación inversa entre velocidad y calidad. Y aquí todo es muy extraño. En algún momento, vemos la confirmación de esta correlación inversa. Es decir, cuanto más rápido lancemos, menor será la calidad.

Pero entonces la correlación no solo no es inversa, es directa. Cuanto más rápido lancemos, mejor será nuestra calidad. Digamos que somos medianos y probamos con plumas. No todo está mal, pero lentamente, porque creemos que si no tenemos prisa, probaremos todo mejor. Luego viene un consultor de DevOps y dice: “Eso es todo, ahora lo estamos automatizando. Y no necesitamos probadores. Todo está bien ".

Pero sin pruebas, es una tontería. Después de darnos cuenta de que, después de todo, hay que probar algo y que es necesario automatizarlo correctamente, comenzamos a automatizarlo correctamente y seguimos luchando por alcanzar alturas altísimas.



Esta falla, donde hay muchos errores, debe superarse correctamente. Cómo entrar, creo que no hay preguntas. La pregunta es cómo salir de eso.

Necesitamos responder a la pregunta de cómo vivir sin pruebas manuales. La respuesta es la misma que la cuestión de cómo vivir sin configurar servidores. Obviamente posible. ¿Qué está cambiando?

Anteriormente, teníamos un administrador del sistema que lanzó un producto para producción. Se sentó y esperó a que los desarrolladores terminaran de escribir. Después de eso, tomó este producto y fue a insertar el CD-ROM y pegar los cables. ¿Qué pasa con todos los demás en este momento? Todos los demás están esperando. Este es un cuello de botella, enchufe.



Resolvemos esto con la automatización adecuada. Automatizamos el proceso, tenemos una tubería preparada de antemano, y ahora el producto se implementa automáticamente tan pronto como termina de escribir. ¿Significa que ahora estas personas no son necesarias? No Esto significa que son necesarios, pero están haciendo otra cosa.

Lo mismo con las pruebas. Tenemos probadores que prueban el producto. Esperan hasta que escriben un producto. Escribió: es hora de probar. ¿Qué hacen los demás mientras hacen la prueba? No hacen nada, están esperando. ¿Cómo resolvemos esto?


De nuevo, la automatización correcta. Estamos construyendo un proceso. Él garantizará la calidad del producto. Podemos preparar este proceso por adelantado, y luego el producto se prueba automáticamente.

• Esto requiere, por ejemplo, equipos interfuncionales . Aquí nos levantamos de los pozos y nos sentamos juntos. Ahora tenemos un león acostado con una oveja, y el probador trabaja junto con el programador.
• Hacemos pruebas continuas . Es como una prueba automatizada, pero más inteligente.
• En el proceso de desarrollo, se realiza una "prueba cerebral" . Este es un término más correcto que "prueba manual", porque la prueba manual se trata del cerebro, no de las manos. Gracias por este término a mi gemelo en Facebook Alexey Vinogradov. Las pruebas cerebrales se producen durante el proceso de desarrollo. Tan pronto como aparece algo, ya puede verificar su flujo, ya puede comprender cómo funciona, ya puede comenzar a esbozar algunos casos de esquina, que luego automatizaremos.
• Ahora estamos siguiendo al desarrollador. Si no escribió la prueba al principio, podemos darle una bofetada. Este es el desarrollo impulsado por pruebas .
• La retroalimentación instantánea es importante. Deberíamos tener una tubería que nos diga inmediatamente tan pronto como algo se rompa. Porque tenemos que ir de inmediato y arreglarlo al instante.
• Participación en el diseño . Sucede que miras algo y piensas cómo probaremos ahora esta mierda. Pero perdón, ¿dónde estabas cuando todos decidieron que habría mierda? Vienes a la reunión y dices que no estás de acuerdo, debes hacerlo inconscientemente. Debe participar en el diseño para asegurarse de poder probarlo más tarde.
• Herramientas, arneses, soportes : lo que muchos de ustedes hacen hoy no irán a ninguna parte. Por el contrario, esto será más. En consecuencia, alguien debería escribir esto.
• Ingeniería del caos . Siempre soñaste con lanzar Chaos Monkey en producción, especialmente si tienes una red de cajeros automáticos en Windows 95. Esta es tu oportunidad.
• Y finalmente, debes enseñar a los ignorantes a diseñar pruebas . Decidimos que los desarrolladores al menos afirman que escriben pruebas. Ahora permítales escribir exámenes, solo nosotros debemos enseñarles cómo hacerlo. ¿Quién les enseñará, cómo saben cómo escribir exámenes? Solo tu. Nadie mas.

Queda por automatizar todo. De hecho, podemos automatizar las pruebas. El problema es que puedes automatizar cierta parte.


Todos ustedes conocen esta broma sobre cómo un probador ingresa a un bar, ordena cerveza, ordena 0 cervezas, ordena 99999999999 cerveza, ordena un lagarto, ordena -1 cerveza y ordena ... Esto es un error, porque debería ser asdfgh, no este mierda

Se automatiza fácilmente. Está claro que no hay problemas en los números en absoluto. Ponemos un aleatorizador, nos lo hace. Incluso un lagarto de hoy ya se puede generar allí. Esto es confuso, espero que hayas oído hablar de eso, porque lo leí ayer.



Pero luego llega el cliente, pregunta dónde está el baño y todo, el bar se quema, todos mueren y todo eso. Esto no puede ser automatizado. Bueno, como puedes, pero primero debes entender con la cabeza que el bar no solo es donde están las bebidas, sino también donde está el baño. Además, las posibilidades de que el cliente quiera ir al baño son ligeramente mayores que el hecho de que ordenará un lagarto. Por lo tanto, es más importante verificarlo, pero para esto necesita comprender el negocio, debe comprender el producto, y solo las personas con la cabeza pueden hacerlo.

, , , . DevOps. , . T- — , .

, - . « », , . , , , . , Selenium . , .

, .



— . , , . . , , Ops- , , , , , , , .



Developers in test — , , . , . , ; — , ; TDD , , , , . , , .



« ». , , , , , — . , , , , , , , , , , Continuous Testing .

end-to-end , . , , DevOps, .

, - , . , 70- : « DevOps, ». , , .

. -, , , , , . : ( EVP Engineering, SignalFx) , , .

70- . . , , . , . , , , , . , , , , — , netflix .

, , , , , , , , , . . , .

, . . « , », — , , .



«, — . — : , , , . , , , , , . . , - , . ? Artifactory , ?!».

, — , . , . ? !



DORA: , , , .



New Work. , New Work Low — 30%, Medium — 40%, High Elite — 50%. ( , Low) , , .

.

Heisenbug 2018 Moscow, — 17-18 Heisenbug. , . , ( ).