Analicemos por qué las herramientas de CI y la CI son cosas completamente diferentes.
Qué dolor pretende resolver CI, de dónde surgió la idea, cuáles son las últimas confirmaciones de que funciona, cómo entender que tiene una práctica y no solo Jenkins instalado.
La idea de hacer un reportaje sobre Integración Continua surgió hace un año, cuando iba a entrevistas y buscaba trabajo. Hablé con entre 10 y 15 empresas, solo una de ellas pudo responder claramente qué es la CI y explicar cómo se dieron cuenta de que no la tenían. El resto decía tonterías ininteligibles sobre Jenkins :) Bueno, tenemos Jenkins, ¡compila, CI! Durante el informe, intentaré explicar qué es realmente la Integración Continua y por qué Jenkins y herramientas similares tienen una relación muy débil con esto.
Entonces, ¿qué te viene a la mente cuando escuchas la palabra CI? La mayoría de la gente pensará en Jenkins, Gitlab CI, Travis, etc.
Incluso si lo buscamos en Google, nos dará estas herramientas.
Si está familiarizado con las preguntas, inmediatamente después de enumerar las herramientas, le dirán que CI es cuando crea y ejecuta pruebas en una solicitud de extracción para una confirmación.
¡La Integración Continua no se trata de herramientas, ni de ensamblajes con pruebas en una rama! La Integración Continua es la práctica de integración muy frecuente de código nuevo y para utilizarla no es en absoluto necesario cercar Jenkins, GitLab, etc.
Antes de descubrir cómo es un CI completo, primero profundicemos en el contexto de las personas que lo idearon y sintamos el dolor que intentaban resolver.
¡Y resolvieron el dolor de trabajar juntos como equipo!
Veamos ejemplos de las dificultades que enfrentan los desarrolladores cuando desarrollan en equipos. Aquí tenemos un proyecto, una rama maestra en git y dos desarrolladores.
Y se pusieron a trabajar como todos estaban acostumbrados desde hacía mucho tiempo. Tomamos una tarea en el gran esquema de las cosas, creamos una rama de funciones y escribimos el código.
Uno terminó la función más rápido y la fusionó con el maestro.
El segundo necesitó más tiempo, se fusionó después y acabó en conflicto. Ahora, en lugar de escribir las funciones que la empresa necesita, el desarrollador dedica su tiempo y energía a resolver conflictos.
Cuanto más difícil sea combinar su función con un maestro común, más tiempo le dedicaremos. Y lo mostré con un ejemplo bastante simple. Este es un ejemplo en el que solo hay 2 desarrolladores. Imagínese si 10, 15 o 100 personas en una empresa escriben en un repositorio. Te volverás loco por resolver todos estos conflictos.
Hay un caso ligeramente diferente. Tenemos un maestro y algunos desarrolladores haciendo algo.
Crearon una ramita.
Uno murió, todo estuvo bien, pasó la tarea.
Mientras tanto, el segundo desarrollador entregó su tarea. Digamos que lo envió para revisión. Muchas empresas tienen una práctica llamada revisión. Por un lado, esta práctica es buena y útil, por otro lado, nos frena en muchos sentidos. No entraremos en eso, pero aquí hay un gran ejemplo de a lo que puede conducir una historia con una mala crítica. Ha enviado una solicitud de extracción para su revisión. El desarrollador no tiene nada más que hacer. ¿Qué empieza a hacer? Comienza a asumir otras tareas.
Durante este tiempo, el segundo desarrollador hizo algo más.
El primero completó la tercera tarea.
Y después de mucho tiempo, su opinión fue puesta a prueba y está tratando de llegar a un acuerdo. Entonces, ¿qué está pasando? Atrapa una gran cantidad de conflictos. ¿Por qué? Porque mientras su solicitud de extracción estaba en la revisión, muchas cosas ya habían cambiado en el código.
Además de la historia con conflictos, hay una historia con comunicaciones. Mientras su hilo está pendiente de revisión, mientras espera algo, mientras trabaja en una función durante mucho tiempo, deja de rastrear qué más está cambiando en el código base de su servicio. Quizás lo que intentas resolver ahora ya se resolvió ayer y puedes tomar algún método y reutilizarlo. Pero no verás esto porque siempre estás trabajando con una rama obsoleta. Y esta rama obsoleta siempre hace que tengas que resolver un conflicto de fusión.
Resulta que si trabajamos en equipo, es decir, no una persona husmeando en el repositorio, sino entre 5 y 10 personas, cuanto más tiempo no agreguemos nuestro código al maestro, más sufriremos porque, en última instancia, necesitamos algo y luego fusionarlo. Y cuantos más conflictos tengamos y cuanto más antigua sea la versión con la que trabajemos, más problemas tendremos.
¡Hacer algo juntos es doloroso! Siempre nos estorbamos el uno al otro.
Este problema se detectó hace más de 20 años. Encontré la primera mención de la práctica de Integración Continua en Programación Extrema.
Extreme Programming es el primer marco ágil. La página apareció en 96. Y la idea era utilizar algún tipo de prácticas de programación, planificación y otras cosas, para que el desarrollo fuera lo más flexible posible, para que pudiéramos responder rápidamente a cualquier cambio o requerimiento de nuestros clientes. Y empezaron a afrontar esto hace 24 años: si haces algo durante mucho tiempo y al margen, le dedicas más tiempo porque tienes conflictos.
Ahora analizaremos la frase “Integración Continua” individualmente. Si lo traducimos directamente, obtenemos una integración continua. Pero no está muy claro cuán continuo es; es muy discontinuo. Pero tampoco es muy evidente cuánta integración tiene.
Y es por eso que ahora les doy citas de Programación Extrema. Y analizaremos ambas palabras por separado.
Integración: como ya dije, nos esforzamos por garantizar que cada ingeniero trabaje con la versión más reciente del código, por lo que se esfuerza por agregar su código con la mayor frecuencia posible a una rama común, para que sean ramas pequeñas. Porque si son grandes, fácilmente podemos quedarnos estancados con conflictos de fusión durante una semana. Esto es especialmente cierto si tenemos un ciclo de desarrollo largo, como una cascada, donde el desarrollador se ausentó durante un mes para eliminar alguna característica importante. Y estará estancado en la etapa de integración durante mucho tiempo.
La integración es cuando tomamos nuestra rama y la integramos con la maestra, la fusionamos. Existe una opción definitiva cuando somos desarrolladores de transbase, en la que nos esforzamos por garantizar que escribimos inmediatamente en el maestro sin ramas adicionales.
En general, la integración significa tomar su código y arrastrarlo al maestro.
¿Qué se entiende aquí por la palabra “continuo”, lo que se llama continuidad? La práctica implica que el desarrollador se esfuerza por integrar su código lo más rápido posible. Este es su objetivo al realizar cualquier tarea: convertir su código en maestro lo más rápido posible. En un mundo ideal, los desarrolladores harían esto cada pocas horas. Es decir, tomas un pequeño problema y lo fusionas con el maestro. Todo esta bien. Esto es por lo que te esfuerzas. Y esto debe hacerse de forma continua. Tan pronto como haces algo, inmediatamente lo pones en el master.
Y el desarrollador que hace algo es responsable de lo que hizo para que funcione y no rompa nada. Aquí es donde suele salir la historia de prueba. Queremos ejecutar algunas pruebas en nuestro compromiso, en nuestra fusión, para asegurarnos de que funciona. Y aquí es donde Jenkins puede ayudarte.
Pero con las historias: hagamos pequeños cambios, dejemos que las tareas sean pequeñas, creemos un problema e inmediatamente intentemos integrarlo de alguna manera en el maestro; ningún Jenkins ayudará aquí. Porque Jenkins solo te ayudará a ejecutar pruebas.
Puedes prescindir de ellos. Esto no te hará daño en absoluto. Porque el objetivo de la práctica es medir con la mayor frecuencia posible para no perder una gran cantidad de tiempo en conflictos en el futuro.
Imaginemos que por alguna razón estamos en 2020 sin Internet. Y trabajamos localmente. No tenemos Jenkins. Esto esta bien. Aún puedes seguir adelante y crear una sucursal local. Escribiste algo de código en él. Completamos la tarea en 3-4 horas. Cambiamos a master, hicimos un git pull y fusionamos nuestra rama allí. Listo. Si haces esto con frecuencia, felicidades, ¡tienes Integración Continua!
¿Qué evidencia hay en el mundo moderno de que vale la pena gastar energía? Porque en general es difícil. Si intentas trabajar así, entenderás que parte de la planificación ahora se verá afectada, tendrás que dedicar más tiempo a descomponer las tareas. Porque si lo haces hombre... entonces no podrás llegar a un acuerdo rápidamente y, en consecuencia, te meterás en problemas. Ya no tendrás práctica.
Y será caro. No será posible trabajar inmediatamente a partir de mañana utilizando la Integración Continua. A todos les llevará mucho tiempo acostumbrarse, les llevará mucho tiempo acostumbrarse a descomponer las tareas, les llevará mucho tiempo acostumbrarse a rehacer la práctica de revisión, si tienen una. . Porque nuestro objetivo es que hoy se derrita. Y si haces una revisión dentro de los tres días, entonces tienes problemas y la Integración Continua no te funciona.
Pero, ¿tenemos ahora alguna evidencia relevante que nos diga que invertir en esta práctica tiene sentido?
Lo primero que me vino a la mente fue State of DevOps. Este es un estudio que los chicos han estado realizando durante 7 años. Ahora lo hacen como una organización independiente, pero bajo la dirección de Google.
Y su estudio de 2018 mostró una correlación entre las empresas que intentan utilizar sucursales de corta duración que se integran rápidamente, se integran con frecuencia y tienen mejores indicadores de rendimiento de TI.
¿Cuáles son estos indicadores? Estas son 4 métricas que toman de todas las empresas en sus cuestionarios: frecuencia de implementación, tiempo de espera para los cambios, tiempo para restaurar el servicio, tasa de fallas en los cambios.
Y, en primer lugar, existe esta correlación: sabemos que las empresas que miden con frecuencia tienen métricas mucho mejores. Y tienen una división de empresas en varias categorías: son empresas lentas que producen algo lentamente, de rendimiento medio, de alto rendimiento y de élite. La élite son Netflix, Amazon, que son súper rápidos, hacen todo de forma rápida, hermosa y eficiente.
La segunda historia, que ocurrió hace apenas un mes. Technology Radar tiene un excelente artículo sobre Gitflow. Gitflow se diferencia de todos los demás en que sus ramas son duraderas. Hay ramas de lanzamiento que duran mucho tiempo y ramas de características que también duran mucho tiempo. Esta práctica en Technology Radar se ha trasladado a HOLD. ¿Por qué? Porque la gente enfrenta el dolor de la integración.
Si su sucursal vive por mucho tiempo, se atasca, se pudre y comenzamos a pasar más tiempo tratando de hacerle algún tipo de cambio.
Y recientemente, el autor de Gitflow dijo que si su objetivo es la integración continua, si su objetivo es ejecutar con la mayor frecuencia posible, entonces Gitflow es una mala idea. Agregó por separado al artículo que si tiene un backend donde puede esforzarse por lograr esto, entonces Gitflow es superfluo para usted, porque Gitflow lo ralentizará, Gitflow le creará problemas con la integración.
Esto no significa que Gitflow sea malo y no deba usarse. Es para otras ocasiones. Por ejemplo, cuando necesita admitir varias versiones de un servicio o aplicación, es decir, cuando necesita soporte durante un largo período de tiempo.
Pero si habla con personas que apoyan dichos servicios, escuchará mucho dolor por el hecho de que esta versión era 3.2, que era hace 4 meses, pero esta solución no estaba incluida y ahora, para poder hacerlo, necesitas hacer muchos cambios. Y ahora están atascados de nuevo, y han estado jugueteando durante una semana tratando de implementar alguna característica nueva.
Como señaló correctamente Alexander Kovalev en el chat, correlación no es lo mismo que causalidad. Esto es cierto. Es decir, no existe una conexión directa de que si tienes Integración Continua, entonces todas las métricas serán excelentes. Pero existe una correlación positiva: si uno es uno, lo más probable es que el otro también lo sea. No es un hecho, pero lo más probable es que. Es sólo una correlación.
Parece que ya estamos haciendo algo, parece que ya nos estamos fusionando, pero ¿cómo podemos entender que todavía tenemos Integración Continua, que nos fusionamos con bastante frecuencia?
Jez Humble es el autor de Handbook, Accelerate, el sitio web de entrega continua y el libro Entrega continua. Ofrece esta prueba:
- El código del ingeniero llega al maestro todos los días.
- Para cada confirmación, ejecuta pruebas unitarias.
- La construcción en el maestro cayó, se arregló en unos 10 minutos.
Sugiere utilizar una prueba como esta para asegurarse de tener suficiente práctica.
Esto último me parece un poco controvertido. Es decir, si puedes solucionarlo en 10 minutos, entonces tienes Integración Continua, suena un poco extraño, en mi opinión, pero tiene sentido. ¿Por qué? Porque si te congelas con frecuencia, significa que tus cambios son pequeños. Si un pequeño cambio significa que su compilación maestra no funciona, entonces puede encontrar un ejemplo rápidamente porque el cambio es pequeño. Aquí tenías una pequeña combinación, entre 20 y 30 líneas cambiaron. Y, en consecuencia, podrá comprender rápidamente cuál fue el motivo, ya que los cambios son pequeños, tiene un área muy pequeña para buscar el problema.
E incluso si nuestro estímulo se desmorona después del lanzamiento, entonces si practicamos la Integración Continua, nos resultará mucho más fácil actuar, porque los cambios son pequeños. Sí, esto afectará la planificación. Esto dolerá. Y, probablemente, lo más difícil en esta práctica es acostumbrarse a dividir las tareas, es decir, cómo hacerlo para que puedas tomar algo y hacerlo en unas horas y al mismo tiempo aprobar una revisión, si tú tienes uno. La revisión es un dolor aparte.
Las pruebas unitarias son solo un asistente que le ayuda a comprender si su integración fue exitosa y si no hubo ningún problema. En mi opinión, esto tampoco es del todo obligatorio, porque ese no es el objetivo de la práctica.
Esta es una breve introducción a la Integración Continua. Eso es todo lo que hay en esta práctica. Estoy listo para preguntas.
Voy a resumir brevemente de nuevo:
- La integración continua no es Jenkins, no es Gitlab.
- Esto no es una herramienta, es una práctica en la que fusionamos nuestro código en el maestro con la mayor frecuencia posible.
- Hacemos esto para evitar el enorme dolor que surge con las fusiones en el futuro, es decir, experimentamos un poco de dolor ahora para no experimentar más en el futuro. Ese es todo el punto.
- En el lateral hay comunicación a través de código, pero rara vez veo esto, pero también fue diseñado para eso.
preguntas
¿Qué hacer con las tareas no descompuestas?
Descomponer. ¿Cuál es el problema? ¿Puedes dar un ejemplo de que haya una tarea y no esté descompuesta?
Hay tareas que no se pueden descomponer de la palabra "completamente", por ejemplo, aquellas que requieren una experiencia muy profunda y que, de hecho, se pueden resolver en el transcurso de un mes para lograr algún resultado digerible.
Si lo entiendo correctamente, ¿hay alguna tarea grande y compleja cuyo resultado será visible solo en un mes?
Sí, eso es correcto. Sí, será posible evaluar el resultado no antes de un mes.
Bien. En general esto no es un problema. ¿Por qué? Porque en este caso, cuando hablamos de ramitas, no estamos hablando de una ramita con una característica. Las características pueden ser grandes y complejas. Pueden afectar a una gran cantidad de componentes. Y quizás no podamos hacerlos completamente en una sola rama. Esto esta bien. Sólo necesitamos desglosar esta historia. Si una función no está completamente lista, esto no significa que algunas partes de su código no se puedan fusionar. Agregaste, digamos, migración y hay algunas etapas dentro de la función. Digamos que tiene una etapa: realizar una migración, agregar un nuevo método. Y ya puedes medir estas cosas todos los días.
Bien. ¿Cuál es el punto entonces?
¿Cuál es el punto de matar cosas pequeñas todos los días?
Sí.
Si rompen algo, lo ves enseguida. Tienes un trozo pequeño que se ha roto algo, te resulta más fácil arreglarlo. La cuestión es que fusionar una pequeña pieza ahora es mucho más fácil que fusionar algo grande en unas pocas semanas. Y el tercer punto es que otros ingenieros trabajarán con la versión actual del código. Verán que se han agregado algunas migraciones aquí y luego ha aparecido algún método que quizás también quieran usar. Todos verán lo que está sucediendo en su código. Es por estas tres cosas que se hace la práctica.
¡Gracias, el problema está cerrado!
(Oleg Soroka) ¿Puedo añadir? Dijiste todo correctamente, solo quiero agregar una frase.
Так.
Con la integración continua, el código se fusiona en una rama común no cuando la función está completamente lista, sino cuando la compilación deja de fallar. Y puedes comprometerte a dominar con seguridad tantas veces al día como quieras. El segundo aspecto es que si por alguna razón no puedes dividir la tarea mensual en tareas durante al menos tres días, me quedo en silencio durante unas tres horas, entonces tienes un gran problema. Y el hecho de que no tengas Integración Continua es el menor de estos problemas. Esto significa que tiene problemas con la arquitectura y cero prácticas de ingeniería. Porque incluso si se trata de una investigación, en cualquier caso debe formularse en forma de hipótesis o de un ciclo.
Hablamos de 4 métricas que distinguen a las empresas exitosas de las rezagadas. Todavía tenemos que vivir para ver estas 4 métricas. Si su tarea promedio tarda un mes en completarse, entonces me centraría primero en esta métrica. Primero lo bajaría a 3 días. Y después de eso comencé a pensar en Continuo.
¿Le entendí correctamente al pensar que, en general, no tiene sentido invertir en prácticas de ingeniería si alguna tarea tarda un mes en completarse?
Tienes Integración Continua. Y existe un tema tal que en 10 minutos puedes corregirlo o revertirlo. Imagina que lo implementaste. Además, incluso tiene una implementación continua, la implementó para estimular y solo entonces notó que algo salió mal. Y necesita revertirlo, pero ya ha migrado su base de datos. Ya tienes el esquema de la base de datos de la próxima versión, además, también tenías algún tipo de copia de seguridad y los datos también se escribieron allí.
¿Y qué alternativa tienes? Si revierte el código, ya no podrá funcionar con esta base de datos actualizada.
La base solo avanza, eso sí.
Las personas que tienen malas prácticas de ingeniería probablemente tampoco hayan leído el grueso libro sobre... ¿Qué hacer con la copia de seguridad? Si restauras desde una copia de seguridad, significa que pierdes los datos que has acumulado durante ese momento. Por ejemplo, trabajamos durante tres horas con la nueva versión de la base de datos, los usuarios se registraron allí. Rechazas la copia de seguridad anterior porque el esquema no funciona con la nueva versión, por lo que has perdido a estos usuarios. Y están descontentos, lo juran.
Para dominar toda la gama de prácticas que respaldan la Integración Continua y la Entrega Continua, no basta con aprender a escribir... En primer lugar, puede haber muchos, no será práctico. Además, existen muchas otras prácticas como Scientific. Existe tal práctica, GitHub la popularizó en un momento. Esto es cuando tienes código antiguo y código nuevo ejecutándose al mismo tiempo. Aquí es cuando creas una característica sin terminar, pero puede devolver algún valor: ya sea como una función o como una API Rest. Ejecuta tanto el código nuevo como el código antiguo y compara la diferencia entre ellos. Y si hay una diferencia, registra este evento. De esta manera, sabrá que tiene una nueva función lista para implementar sobre la anterior si no ha tenido una discrepancia entre las dos durante un tiempo determinado.
Hay cientos de prácticas de este tipo. Sugeriría comenzar con el desarrollo de transbase. No está 100% en Integración Continua, pero las prácticas son las mismas, uno no puede vivir bien sin el otro.
¿Dio el desarrollo de transbase como un ejemplo donde se pueden ver prácticas o sugiere que las personas comiencen a utilizar el desarrollo de transbase?
Échale un vistazo, porque no podrán utilizarlo. Para poder utilizarlos es necesario leer mucho. Y cuando una persona pregunta: "¿Qué hacer con una función que lleva un mes?", significa que no ha leído sobre el desarrollo de transbase". No lo recomendaría todavía. Aconsejaría centrarse únicamente en el tema de cómo dividir correctamente arquitectónicamente las tareas grandes en otras más pequeñas. Ésta es la esencia de la descomposición.
La descomposición es una de las herramientas del arquitecto. Primero hacemos análisis, luego descomposición, luego síntesis y luego integración. Y así nos sale todo. Y todavía necesitamos crecer hacia la Integración Continua a través de la descomposición. Las preguntas surgen en la primera etapa, y ya estamos hablando de la cuarta etapa, es decir, cuanto más a menudo hagamos integración, mejor. Todavía es demasiado pronto para hacer esto; sería bueno cortar su monolito primero.
Necesitas dibujar varias flechas y cuadrados en algún diagrama. No se puede decir que ahora mostraré el diagrama arquitectónico de una nueva aplicación y mostraré un cuadrado, dentro del cual hay un botón verde para la aplicación. En cualquier caso, habrá más cuadrados y flechas. Cada diagrama que vi tenía más de uno. Y la descomposición, incluso a nivel de representación gráfica, ya se está produciendo. Por tanto, los cuadrados se pueden independizar. Si no, tengo grandes preguntas para el arquitecto.
Hay una pregunta en el chat: “Si una revisión es obligatoria y lleva mucho tiempo, ¿tal vez un día o más?”
Tienes problemas con la práctica. La revisión no debería durar un día o más. Esta es la misma historia de la pregunta anterior, sólo que un poco más suave. Si una revisión dura un día, lo más probable es que se produzca un cambio muy grande. Esto significa que es necesario hacerlo más pequeño. En el desarrollo de Transbase, que recomendó Oleg, hay una historia llamada revisión continua. Su idea es que hagamos una solicitud de extracción tan pequeña a propósito, porque nos esforzamos por fusionarnos constantemente y poco a poco. Y entonces la solicitud de extracción cambia una abstracción o 10 líneas. Gracias a esta reseña, nos lleva un par de minutos.
Si la revisión tarda un día o más, algo anda mal. En primer lugar, es posible que tenga algunos problemas con la arquitectura. O se trata de un fragmento de código grande, de 1 líneas, por ejemplo. O su arquitectura es tan compleja que una persona no puede entenderla. Se trata de un problema ligeramente lateral, pero también habrá que solucionarlo. Quizás no sea necesaria ninguna revisión. Necesitamos pensar en esto también. La revisión es lo que te frena. Tiene sus ventajas en general, pero es necesario comprender por qué lo hace. ¿Es esta una forma de transmitir información rápidamente, es una forma de establecer algunos estándares internamente o qué? ¿Por qué necesitas esto? Porque la revisión debe realizarse muy rápidamente o cancelarse por completo. Es como el desarrollo de transbase: la historia es muy hermosa, pero solo para chicos maduros.
Con respecto a las 4 métricas, aún recomendaría eliminarlas para comprender a qué conduce esto. Miren los números, miren la foto, qué mal está todo.
(Dmitry) Estoy dispuesto a entablar una discusión sobre esto contigo. Los números y las métricas son geniales, las prácticas son geniales. Pero es necesario comprender si la empresa lo necesita. Hay empresas que no necesitan ese tipo de velocidad de cambio. Conozco empresas donde no se pueden hacer cambios cada 15 minutos. Y no porque sean tan malos. Este es uno de esos ciclos de vida. Y para hacer que la función de ramas, la función de alternar, necesite un conocimiento profundo.
Es complicado. Si desea leer la historia sobre la función de alternancia con más detalle, lo recomiendo encarecidamente. . Y hay un maravilloso artículo de Martin Fowler sobre funciones de alternancia: qué tipos hay, ciclos de vida, etc. La función de alternancia es complicada.
Y todavía no has respondido a la pregunta: "¿Se necesita Jenkins o no?"
Jenkins no es necesario en ningún caso. En serio, las herramientas: Jenkins, Gitlab le brindarán comodidad. Verás que el conjunto está montado o no. Pueden ayudarte, pero no te darán práctica. Sólo pueden darte un círculo: Ok, no Ok. Y luego, si también escribes pruebas, porque si no hay pruebas, entonces es casi inútil. Por lo tanto, es necesario porque es más conveniente, pero en general puedes vivir sin él, no perderás mucho.
Es decir, si tienes prácticas, ¿eso significa que no las necesitas?
Así es. Recomiendo la prueba de Jez Humble. Ahí tengo una actitud ambivalente hacia el último punto. Pero en general, si tienes tres cosas, fusionas constantemente, ejecutas pruebas de confirmaciones en el maestro, arreglas rápidamente la compilación en el maestro, entonces quizás no necesites nada más.
Mientras esperamos las preguntas de los participantes, tengo una pregunta. Sólo estábamos hablando del código del producto. ¿Lo ha usado para código de infraestructura? ¿Es el mismo código, tiene los mismos principios y el mismo ciclo de vida, o hay diferentes ciclos de vida y principios? Normalmente, cuando todo el mundo habla de Integración y Desarrollo Continuo, todo el mundo olvida que también existe el código de infraestructura. Y últimamente ha habido más y más. ¿Y deberían llevarse allí todas estas reglas?
Ni siquiera que debería serlo, sería genial porque nos haría la vida más fácil de la misma manera. Tan pronto como trabajemos con código, no con scripts bash, sino que tengamos código normal.
Detente, detente, un script bash también es código. No toques a mi viejo amor.
Está bien, no pisotearé tus recuerdos. Tengo una aversión personal por bash. Se rompe feo y da miedo todo el tiempo. Y a menudo se estropea de forma impredecible, por eso no me gusta. Pero está bien, digamos que tienes código bash. Tal vez realmente no lo entiendo y existen marcos de prueba normales. Simplemente no estoy al tanto. Y obtenemos los mismos beneficios.
Tan pronto como trabajamos con la infraestructura como código, tenemos los mismos problemas que los desarrolladores. Hace unos meses, me encontré con una situación en la que un colega me envió una solicitud de extracción de 1 líneas en bash. Y pasas el rato en la revisión durante 000 horas. Surgen los mismos problemas. Sigue siendo código. Y sigue siendo una colaboración. Nos quedamos atascados con la solicitud de extracción y nos quedamos atascados con el hecho de que estamos resolviendo los mismos conflictos de fusión en el mismo bash, por ejemplo.
Ahora estoy observando muy activamente todo esto en la programación de infraestructura más hermosa. Ahora he incorporado a Pulumi a la infraestructura. Esto es programación en su forma más pura. Ahí es aún mejor, porque tengo todas las capacidades de un lenguaje de programación, es decir, hice un hermoso cambio de la nada con los mismos "si" y todo está bien. Es decir, mi cambio ya está en el master. Todos ya pueden verlo. Otros ingenieros lo saben. Ya ha influido en algo allí. Sin embargo, no estuvo habilitado para todas las infraestructuras. Se activó, por ejemplo, en mis bancos de pruebas. Por lo tanto, para responder nuevamente a su pregunta, es necesario. Nos hace la vida más fácil a nosotros, como ingenieros que trabajamos con código, de la misma manera.
¿Si alguien más tiene preguntas?
Tengo una pregunta. Quiero continuar la discusión con Oleg. En general creo que tienes razón, que si una tarea tarda un mes en completarse, entonces tienes un problema de arquitectura, tienes un problema de análisis, descomposición, planificación, etc. Pero tengo la sensación de que si empiezas intentando vivir de acuerdo con la Integración Continua, entonces comenzarás a corregir el dolor con planificación, porque no podrás escapar de él en ningún otro lugar.
(Oleg) Sí, es cierto. Esta práctica es comparable en esfuerzo a cualquier otra práctica seria de cambio cultural. Lo más difícil de superar son los hábitos, especialmente los malos hábitos. Y si para implementar esta práctica es necesario un cambio serio en los hábitos de quienes te rodean: desarrolladores, gerencia, gerente de producción, entonces te esperan sorpresas.
¿Qué sorpresas podría haber? Digamos que decides que te integrarás más a menudo. Y hay otras cosas relacionadas con la integración, por ejemplo, los artefactos. Y en su empresa, por ejemplo, existe una política según la cual cada artefacto debe contabilizarse de alguna manera en algún tipo de sistema de almacenamiento de artefactos. Y lleva algo de tiempo. Una persona debe marcar la casilla que indica que él, como administrador de versiones, ha probado este artefacto para asegurarse de que esté listo para su lanzamiento en producción. Si te lleva 5-10-15 minutos, pero haces el diseño una vez a la semana, dedicar media hora una vez a la semana es un pequeño impuesto.
Si realiza la Integración Continua 10 veces al día, entonces 10 veces deben multiplicarse por 30 minutos. Y esto excede la cantidad de tiempo de trabajo de este administrador de versiones. Simplemente se cansa de hacerlo. Hay costos fijos para algunas prácticas. Eso es todo.
Y debe cancelar esta regla para no volver a hacer esa basura, es decir, no asignar manualmente un título que corresponda a algo. Depende completamente de un conjunto automatizado de pruebas de preparación.
Y si necesitas pruebas de alguien para que el jefe las firme y no entres en producción sin que Vasya diga que lo permite, etc., todas estas tonterías se interponen en el camino del practicante. Porque si hay algunas actividades asociadas a un impuesto, entonces todo aumenta 100 veces. Por lo tanto, el cambio a menudo no será recibido con alegría por todos. Porque los hábitos de las personas son difíciles de cambiar.
Cuando una persona hace su trabajo habitual, lo hace casi sin pensar. Su carga cognitiva es cero. Simplemente juega con eso, ya tiene una lista de verificación en su cabeza, lo ha hecho mil veces. Y en cuanto vienes y le dices: “cancelemos esta práctica e introduzcamos una nueva a partir del lunes”, para él se convierte en una poderosa carga cognitiva. Y llega a todos a la vez.
Por tanto, lo más sencillo, aunque no todo el mundo puede permitirse este lujo, pero esto es lo que yo hago siempre, esto es lo siguiente. Si se inicia un nuevo proyecto, normalmente todas las prácticas no probadas se incluyen inmediatamente en este proyecto. Si bien el proyecto es joven, realmente no arriesgamos nada. Todavía no hay Prod, no hay nada que destruir. Por tanto, puede utilizarse como entrenamiento. Este enfoque funciona. Pero no todas las empresas tienen la oportunidad de iniciar proyectos de este tipo con frecuencia. Aunque esto también es un poco extraño, porque ahora hay una transformación digital completa, todos deben lanzar experimentos para mantenerse al día con la competencia.
Aquí se llega a la conclusión de que primero debe comprender lo que debe hacer. El mundo no es ideal y el producto tampoco lo es.
Sí, estas cosas están interconectadas.
Las empresas tampoco siempre entienden que deben seguir este camino.
Hay una situación en la que no es posible ningún cambio. Esta es una situación en la que hay más presión sobre el equipo. El equipo ya está bastante agotado. No tiene tiempo libre para ningún experimento. Trabajan en funciones desde la mañana hasta la noche. Y la gestión tiene cada vez menos funciones. Cada vez se requieren más. En tal situación, no es posible realizar ningún cambio. Solo se le puede decir al equipo que mañana haremos lo mismo que ayer, solo que necesitamos hacer un poco más de funciones. En este sentido, no es posible realizar transiciones a ninguna práctica. Esta es una situación clásica en la que no hay tiempo para afilar el hacha, hay que talar árboles, por eso lo cortan con un hacha sin filo. Aquí no hay consejos simples.
(Dmitry) Leeré una aclaración del chat: “Pero necesitamos mucha cobertura de pruebas en diferentes niveles. ¿Cuánto tiempo se asigna para las pruebas? Es un poco caro y requiere mucho tiempo”.
(Oleg) Este es un error clásico. Debería haber suficientes pruebas para que usted tenga confianza. La Integración Continua no es algo en lo que primero se hacen el 100% de las pruebas y solo después se empieza a aplicar esta práctica. La Integración Continua reduce tu carga cognitiva porque cada uno de los cambios que ves con tus ojos es tan obvio que sabes si algo se romperá o no, incluso sin pruebas. Puedes probar esto rápidamente en tu cabeza porque los cambios son pequeños. Incluso si sólo tienes probadores manuales, también es más fácil para ellos. Saliste y dijiste: "Mira, ¿hay algo roto?" Lo comprobaron y dijeron: "No, no hay nada roto". Porque el evaluador sabe dónde buscar. Tiene una confirmación asociada con un fragmento de código. Y esto es explotado por un comportamiento específico.
Aquí, por supuesto, embellecido.
(Dmitry) No estoy de acuerdo aquí. Existe una práctica: el desarrollo basado en pruebas, que le salvará de esto.
(Oleg) Bueno, todavía no he llegado a ese punto. La primera ilusión es que necesitas escribir el 100% de las pruebas o no necesitas hacer ninguna Integración Continua. No es cierto. Se trata de dos prácticas paralelas. Y no son directamente dependientes. La cobertura de tu prueba debe ser óptima. Óptimo: esto significa que usted mismo está seguro de que la calidad del maestro en el que permaneció su maestro después de la confirmación le permite presionar con confianza el botón "Implementar" en un viernes por la noche borracho. ¿Cómo se logra esto? A través de la revisión, a través de la cobertura, a través de un buen seguimiento.
Un buen seguimiento es indistinguible de las pruebas. Si ejecuta las pruebas una vez en la fase previa a la producción, comprobarán todos los scripts de usuario una vez y listo. Y si los ejecuta en un bucle sin fin, entonces este es su sistema de monitoreo implementado, que prueba todo sin cesar, ya sea que haya fallado o no. En este caso la única diferencia es si se hace una o dos veces. Un muy buen conjunto de pruebas... ejecutándose sin cesar, esto es monitoreo. Y el seguimiento adecuado debería ser así.
Y por lo tanto, cómo alcanzar exactamente este estado cuando se prepare el viernes por la noche y se vaya a casa es otra cuestión. Tal vez no seas más que un cabrón atrevido.
Volvamos un poco a la Integración Continua. Nos dirigimos a una práctica compleja ligeramente diferente.
Y la segunda ilusión es que MVP, dicen, debe realizarse rápidamente, por lo que no se necesitan pruebas allí en absoluto. Ciertamente no de esa manera. El hecho es que cuando escribes una historia de usuario en un MVP, puedes desarrollarla sobre la marcha, es decir, escuchaste que había algún tipo de historia de usuario e inmediatamente corriste a codificarla, o puedes trabajar usando TDD. Y según TDD, como muestra la práctica, no lleva más tiempo, es decir, las pruebas son un efecto secundario. La práctica de TDD no se trata de realizar pruebas. A pesar de lo que se llama Test Driven Development, no se trata en absoluto de pruebas. Este es también un enfoque más bien arquitectónico. Este es un enfoque para escribir exactamente lo que se necesita y no escribir lo que no se necesita. Esta es una práctica de centrarse en la siguiente iteración de su pensamiento en términos de creación de una arquitectura de aplicación.
Por tanto, no es tan fácil deshacerse de estas ilusiones. MVP y las pruebas no se contradicen. Incluso, más bien, por el contrario, si haces MVP usando práctica TDD, entonces lo harás mejor y más rápido que si lo haces sin práctica alguna, pero con una pelota.
Ésta es una idea muy poco obvia y compleja. Cuando escuchas que ahora escribiré más pruebas y al mismo tiempo haré algo más rápido, suena absolutamente inadecuado.
(Dmitry) Mucha gente aquí, cuando llaman a MVP, son demasiado vagas para escribir algo normal. Y estas siguen siendo cosas diferentes. No hay necesidad de convertir MVP en algo malo que no funcione.
Sí, sí, tienes razón.
Y luego, de repente, MVP interviene.
Para siempre
Y TDD suena muy inusual cuando escuchas que escribes pruebas y pareces trabajar más. Suena muy extraño, pero en realidad resulta más rápido y bonito de esta manera. Cuando escribes una prueba, ya piensas mucho en cómo se llamará el código y cómo, así como en el comportamiento que esperamos de él. No se puede decir simplemente que escribí alguna función y ésta hace algo. Al principio pensaste que ella tenía tales condiciones, que sería llamada de tal o cual manera. Cubre esto con pruebas y a partir de esto comprende cómo se verán sus interfaces dentro de su código. Esto tiene un gran impacto en la arquitectura. Su código automáticamente se vuelve más modular, porque primero intenta comprender cómo lo probará y solo luego lo escribe.
Lo que me pasó con TDD fue que en algún momento contraté a un mentor de Ruby cuando todavía era programador de Ruby. Y dice: “Hagámoslo según TDD”. Pensé: “Joder, ahora tengo que escribir algo más”. Y acordamos que dentro de dos semanas escribiría todo el código de trabajo en Python usando TDD. Después de dos semanas, me di cuenta de que no quería volver. Después de dos semanas de intentar aplicar esto en todas partes, te das cuenta de lo fácil que se ha vuelto para ti siquiera pensar. Pero esto no es obvio, por lo que recomiendo a todos que si tienen la sensación de que TDD es difícil, requiere mucho tiempo e innecesario, intenten seguir haciéndolo durante sólo dos semanas. Con dos me bastaron.
(Dmitri) Podemos ampliar esta idea desde el punto de vista de la explotación de la infraestructura. Antes de lanzar algo nuevo, realizamos un seguimiento y luego lo lanzamos. En este caso, el seguimiento se convierte para nosotros en una prueba normal. Y hay desarrollo a través del seguimiento. Pero casi todo el mundo dice que es largo, que soy un vago, que hice un borrador temporal. Si hemos realizado un seguimiento normal, entendemos el estado del sistema CI. Y el sistema CI tiene mucho control. Entendemos el estado del sistema, entendemos lo que hay dentro de él. Y durante el desarrollo, simplemente creamos el sistema para que alcance el estado deseado.
Estas prácticas se conocen desde hace mucho tiempo. Hablamos de esto hace unos 4 años. Pero en 4 años prácticamente nada ha cambiado.
Pero con esto propongo poner fin a la discusión oficial.
Video (insertado como elemento multimedia, pero por alguna razón no funciona):
Fuente: habr.com