Y aun as\u00ed no respondiste a la pregunta: \u00ab\u00bfJenkins es necesario o no?\u00bb<\/em><\/p>\n<\/p>\n
Jenkins no es necesario en ning\u00fan caso, en realidad. Hablando en serio, herramientas como Jenkins o Gitlab te brindar\u00e1n comodidad. Podr\u00e1s ver si la compilaci\u00f3n se realiz\u00f3 o no. Pero no te proporcionar\u00e1n la pr\u00e1ctica. Solo te dar\u00e1n un c\u00edrculo: Ok, no Ok. Y eso, si a\u00fan escribes pruebas, porque si no hay pruebas, es casi in\u00fatil. As\u00ed que es necesario, porque es m\u00e1s conveniente, pero en general se puede vivir sin \u00e9l, no perder\u00e1s mucho. <\/p>\n
<\/p>\n
Es decir, si tienes pr\u00e1cticas, \u00bfsignifica que no lo necesitas?<\/em><\/p>\n<\/p>\n
Correcto. Recomiendo la prueba de Jez Humble. Tengo una relaci\u00f3n ambigua con el \u00faltimo punto. Pero en general, si tienes tres cosas: te fusionas constantemente, ejecutas pruebas en los commits en master y reparas r\u00e1pidamente la compilaci\u00f3n en master, entonces posiblemente no necesites nada m\u00e1s. <\/p>\n
<\/p>\n
Mientras esperamos preguntas de los participantes, tengo una pregunta. Hablamos sobre c\u00f3digo de producto. \u00bfHas utilizado esto para c\u00f3digo de infraestructura? \u00bfEs el mismo c\u00f3digo, tiene los mismos principios y el mismo ciclo de vida, o hay otros ciclos de vida y principios? Normalmente, cuando todos hablan sobre Integraci\u00f3n y Desarrollo Continuos, olvidan que tambi\u00e9n existe el c\u00f3digo de infraestructura. Y \u00faltimamente se est\u00e1 utilizando cada vez m\u00e1s. \u00bfDeber\u00edamos llevar todas estas reglas all\u00ed?<\/em><\/p>\n<\/p>\n
No es solo que debamos, ser\u00eda genial, porque definitivamente simplificar\u00e1 la vida. En cuanto trabajamos con c\u00f3digo, no con scripts en bash, y tenemos c\u00f3digo normal.<\/p>\n
<\/p>\n
Espera, espera, el script en bash tambi\u00e9n es c\u00f3digo. No toques a mi viejo amor.<\/em> <\/p>\n<\/p>\n
Est\u00e1 bien, no voy a pisotear tus recuerdos. Tengo una aversi\u00f3n personal hacia bash. Se rompen de forma poco agradable y siempre asustan. Y a menudo se rompen de manera impredecible, por lo que no me agrada. Pero bien, supongamos que tienes c\u00f3digo en bash. Tal vez realmente no entiendo y hay frameworks decentes para pruebas. Simplemente no estoy al tanto. Y obtenemos los mismos beneficios.<\/p>\n
<\/p>\n
Una vez que trabajamos con infraestructura como c\u00f3digo, obtenemos los mismos problemas que los desarrolladores. Hace unos meses me encontr\u00e9 en una situaci\u00f3n en la que un colega me envi\u00f3 un pull request de 1,000 l\u00edneas en bash. Y te quedas atascado en la revisi\u00f3n durante 4 horas. Los problemas son los mismos. Todav\u00eda es c\u00f3digo. Y a\u00fan es trabajo colaborativo. Nos quedamos atascados con el pull request y lidiamos con los mismos conflictos de fusi\u00f3n del mismo bash, por ejemplo. <\/p>\n
<\/p>\n
Actualmente estoy observando intensamente esta cuesti\u00f3n de la programaci\u00f3n de infraestructura de la manera m\u00e1s hermosa. He incorporado Pulumi a la infraestructura. Esto es programaci\u00f3n en su m\u00e1xima expresi\u00f3n. Es a\u00fan m\u00e1s atractivo, porque tengo todas las posibilidades del lenguaje de programaci\u00f3n, es decir, con las mismas condiciones hice toggles bonitos en un abrir y cerrar de ojos y todo va bien. Es decir, mi cambio ya est\u00e1 en el master. Todos ya lo ven. Otros ingenieros est\u00e1n al tanto. Ya ha influido en algo. Pero no se ha activado para todas las infraestructuras. Se activ\u00f3 para mis entornos de prueba, por ejemplo. Por lo tanto, respondiendo a tu pregunta una vez m\u00e1s, es necesario. Esto, para nosotros como ingenieros que trabajamos con c\u00f3digo, definitivamente facilita la vida. <\/p>\n
<\/p>\n
\u00bfAlguien m\u00e1s tiene preguntas?<\/em> <\/p>\n<\/p>\n
Tengo una pregunta. Quiero continuar la discusi\u00f3n con Oleg. En general, creo que tienes raz\u00f3n, que si una tarea te lleva un mes, entonces tienes un problema con la arquitectura, tienes un problema con el an\u00e1lisis, la descomposici\u00f3n, la planificaci\u00f3n, etc. Pero tengo la sensaci\u00f3n de que si comienzas a tratar de vivir con la Integraci\u00f3n Continua, empezar\u00e1s a corregir los problemas con la planificaci\u00f3n, porque no puedes escapar de eso. <\/p>\n
<\/p>\n
(Oleg) S\u00ed, es as\u00ed. En t\u00e9rminos de esfuerzo, esta pr\u00e1ctica es comparable a cualquier otra pr\u00e1ctica seria que cambie la cultura. Lo m\u00e1s dif\u00edcil de superar son los h\u00e1bitos, especialmente los malos h\u00e1bitos. Y si para implementar esta pr\u00e1ctica se requiere un cambio significativo en los h\u00e1bitos de quienes te rodean: desarrolladores, direcci\u00f3n, gerente de producci\u00f3n, entonces te esperan sorpresas.<\/em> <\/p>\n<\/p>\n
\u00bfQu\u00e9 sorpresas pueden haber? Supongamos que decidiste que har\u00e1s m\u00e1s integraciones. Y en la integraci\u00f3n tienes atados algunas cosas, como artefactos. Y en tu empresa, por ejemplo, hay una pol\u00edtica de que cada artefacto debe ser contabilizado de alguna manera en un sistema de almacenamiento de artefactos. Y esto toma un cierto tiempo. La persona necesita marcar que, como gerente de lanzamientos, ha probado este artefacto para su disposici\u00f3n en producci\u00f3n. Si esto toma 5-10-15 minutos, pero al mismo tiempo haces lanzamientos una vez a la semana, entonces gastar media hora una vez a la semana no es un gran impuesto.<\/em> <\/p>\n<\/p>\n
Si realizas Integraci\u00f3n Continua 10 veces al d\u00eda, entonces debes multiplicar 10 veces por 30 minutos. Y esto supera la cantidad de tiempo laboral de ese gerente de lanzamientos. Simplemente se cansa de hacerlo. Hay costos constantes asociados a ciertas pr\u00e1cticas. Y eso es todo.<\/em> <\/p>\n<\/p>\n
Y necesitas o cancelar esta regla, para que ya no te ocupes de tonter\u00edas, es decir, no asignas manualmente un grado de conformidad de algo a algo. Conf\u00edas total y completamente en un conjunto automatizado de pruebas de preparaci\u00f3n.<\/em> <\/p>\n<\/p>\n
Y si necesitas que alguien te d\u00e9 pruebas para que el jefe firme, y no entras en producci\u00f3n sin que Vasya haya dicho que lo permite, etc., toda esta tonter\u00eda se interpone en el camino de las pr\u00e1cticas. Porque si hay actividades relacionadas que son como un impuesto, todo se multiplica por 100. Por lo tanto, el cambio generalmente no es bien recibido por todos. Porque es dif\u00edcil corregir los h\u00e1bitos de la gente.<\/em> <\/p>\n<\/p>\n
Cuando una persona realiza un trabajo habitual, lo hace pr\u00e1cticamente sin pensarlo. Su carga cognitiva es igual a cero. Simplemente se dedica a lo que ya est\u00e1, tiene una lista de verificaci\u00f3n en su cabeza, lo ha hecho mil veces. Y tan pronto como llegas y le dices: 'Vamos a cancelar esta pr\u00e1ctica y a partir del lunes implementaremos una nueva', para \u00e9l se convierte en una carga cognitiva enorme. Y esto afecta a todos de inmediato.<\/em> <\/p>\n<\/p>\n
Por lo tanto, lo m\u00e1s f\u00e1cil, aunque esta es una lujo que no todos pueden permitirse, es siempre hacer exactamente eso, lo siguiente. Si se lanza un nuevo proyecto, por lo general se introducen de inmediato todas las pr\u00e1cticas no probadas en este proyecto. Mientras el proyecto es joven, no estamos asumiendo un gran riesgo. No hay producci\u00f3n, no hay nada que destruir. Por lo tanto, se puede utilizar como pr\u00e1ctica. Este enfoque funciona. Sin embargo, no todas las empresas tienen la oportunidad de iniciar tales proyectos con frecuencia. Aunque esto tambi\u00e9n resulta un poco extra\u00f1o, porque actualmente estamos en plena transformaci\u00f3n digital, todos deber\u00edan lanzar experimentos para seguir el ritmo de la competencia.<\/em> <\/p>\n<\/p>\n
Aqu\u00ed te enfrentas a que primero debes tener claridad sobre lo que necesitas hacer. El mundo no es perfecto, la producci\u00f3n tampoco es perfecta. <\/p>\n
<\/p>\n
S\u00ed, estas cosas est\u00e1n interrelacionadas.<\/em><\/p>\n<\/p>\n
Las empresas tampoco siempre tienen claridad sobre que necesitan dirigirse hacia eso. <\/p>\n
<\/p>\n
Hay situaciones en las que ning\u00fan cambio es posible. Esta es una situaci\u00f3n en la que hay m\u00e1s presi\u00f3n sobre el equipo. El equipo ya est\u00e1 bastante quemado. No tiene tiempo extra para ning\u00fan tipo de experimentos. Desde la ma\u00f1ana hasta la noche est\u00e1n desarrollando caracter\u00edsticas. Y la direcci\u00f3n siempre pide m\u00e1s y m\u00e1s caracter\u00edsticas. Se necesita cada vez m\u00e1s. En tal situaci\u00f3n, no es posible realizar ning\u00fan cambio. Solo se les puede decir al equipo que ma\u00f1ana haremos lo mismo que ayer, solo que necesitamos hacer un poco m\u00e1s de caracter\u00edsticas. No hay transici\u00f3n a ninguna pr\u00e1ctica significativa en este sentido. Esta es una situaci\u00f3n cl\u00e1sica donde no hay tiempo para afilar el hacha, hay que talar \u00e1rboles, as\u00ed que se talan con un hacha desafilada. Aqu\u00ed no hay consejos sencillos.<\/em> <\/p>\n<\/p>\n
(Dmitry) Voy a leer una aclaraci\u00f3n del chat: \u00abPero es necesario tener una amplia cobertura de pruebas a diferentes niveles. \u00bfCu\u00e1nto tiempo se dedica a las pruebas? Es algo costoso, lleva mucho tiempo\u00bb.<\/em><\/p>\n<\/p>\n
(Oleg) Este es un mito cl\u00e1sico. Debe haber suficientes pruebas para que ustedes mismos tengan confianza. La Integraci\u00f3n Continua no es algo donde primero se realizan el 100% de las pruebas y solo luego se comienza a aplicar esta pr\u00e1ctica. La Integraci\u00f3n Continua reduce su carga cognitiva porque cada uno de los cambios que ven con sus propios ojos es tan obvio que pueden entender si va a romper algo o no, incluso sin pruebas. Pueden probarlo r\u00e1pidamente en su mente, porque son cambios peque\u00f1os. Incluso si solo tienen testers manuales, para ellos tambi\u00e9n es m\u00e1s sencillo. Ustedes hacen un despliegue y dicen: 'Mira, \u00bfno se rompi\u00f3 nada?'. Ellos verifican y dicen: 'No, no se rompi\u00f3 nada'. Porque el tester sabe a d\u00f3nde mirar. Tienen un commit relacionado con un fragmento de c\u00f3digo. Y esto se explota hacia un comportamiento espec\u00edfico.<\/em><\/p>\n<\/p>\n
Aqu\u00ed, por supuesto, has embellecido las cosas. <\/p>\n
<\/p>\n
(Dmitry) Aqu\u00ed no estoy de acuerdo. Existe una pr\u00e1ctica: desarrollo a trav\u00e9s de pruebas, que es precisamente lo que salvar\u00e1 de esto.<\/em> <\/p>\n<\/p>\n
(Oleg) A\u00fan no he llegado a eso. La primera ilusi\u00f3n es que hay que escribir el 100% de las pruebas o no se debe hacer nada relacionado con la Integraci\u00f3n Continua. Eso es falso. Son dos pr\u00e1cticas paralelas. Y no dependen entre s\u00ed directamente. Su cobertura de pruebas debe ser \u00f3ptima. \u00d3ptima significa que ustedes mismos est\u00e1n seguros de que la calidad del maestro, que qued\u00f3 despu\u00e9s del commit, les permite presionar el bot\u00f3n 'Deploy' con confianza el viernes por la noche, incluso si han bebido. \u00bfC\u00f3mo logran esto? A trav\u00e9s de revisiones, cobertura y buen monitoreo.<\/em> <\/p>\n<\/p>\n
Un buen monitoreo es indistinguible de las pruebas. Si ejecutan las pruebas una vez en pre producci\u00f3n, solo verifican todos sus escenarios de usuario una vez. Pero si las ejecutan en un ciclo infinito, esto se convierte en su sistema de monitoreo desplegado, que prueba todo de forma continua \u2013 si fall\u00f3 o no. En este caso, la \u00fanica diferencia es si es una vez o muchas veces. Un conjunto muy bueno de pruebas..., ejecutado de forma infinita, es monitoreo. Y el monitoreo correcto debe ser as\u00ed.<\/em> <\/p>\n<\/p>\n
Y por lo tanto, c\u00f3mo exactamente lograr\u00e1n este estado, donde el viernes por la noche despliegan y se van a casa, es otra cuesti\u00f3n. Tal vez simplemente sean un atrevido.<\/em> <\/p>\n<\/p>\n
Volvamos un poco atr\u00e1s a la Integraci\u00f3n Continua. Nos hemos desviado hacia otra pr\u00e1ctica compleja. <\/p>\n
<\/p>\n
Y la segunda ilusi\u00f3n es que, se dice, hay que hacer el MVP r\u00e1pidamente, por lo que no se necesitan pruebas en absoluto. No es del todo as\u00ed. La cuesti\u00f3n es que cuando escribes una historia de usuario para el MVP, puedes desarrollarla de dos maneras: o a la ligera, es decir, escuchas que hay alguna historia de usuario y te pones a codificarla de inmediato, o puedes trabajar con TDD. Y con TDD, como demuestra la pr\u00e1ctica, no se tarda m\u00e1s, es decir, las pruebas son un efecto secundario. La pr\u00e1ctica de TDD no se trata de probar. A pesar de que se llama Desarrollo Impulsado por Pruebas, realmente no se trata de pruebas. Tambi\u00e9n es m\u00e1s bien un enfoque arquitect\u00f3nico. Es un enfoque sobre c\u00f3mo escribir exactamente lo que se necesita y no escribir lo que no se necesita. Esta pr\u00e1ctica se centra en la siguiente iteraci\u00f3n de tu desarrollo de ideas en t\u00e9rminos de creaci\u00f3n de la arquitectura de la aplicaci\u00f3n.<\/em> <\/p>\n<\/p>\n
Por lo tanto, no es tan f\u00e1cil deshacerse de estas ilusiones. El MVP y las pruebas no se contradicen mutuamente. De hecho, m\u00e1s bien, si haces tu MVP siguiendo la pr\u00e1ctica de TDD, lo har\u00e1s mejor y m\u00e1s r\u00e1pido que si lo haces sin ninguna pr\u00e1ctica y a la ligera.<\/em><\/p>\n<\/p>\n
Es un pensamiento muy poco obvio y complicado. Cuando escuchas que ahora vas a escribir m\u00e1s pruebas y aun as\u00ed vas a hacer algo m\u00e1s r\u00e1pido, suena absolutamente inadecuado. <\/p>\n
<\/p>\n
(Dmitry) Aqu\u00ed muchos, cuando mencionan el MVP, es que la gente simplemente no quiere escribir algo decente. Y, de hecho, son cosas diferentes. No conviertas el MVP en algo que no funcione.<\/em> <\/p>\n<\/p>\n
S\u00ed, tienes raz\u00f3n.<\/p>\n
<\/p>\n
Y luego, de repente, el MVP en producci\u00f3n.<\/em><\/p>\n<\/p>\n
Para siempre. <\/p>\n
<\/p>\n
Y TDD suena muy extra\u00f1o cuando escuchas que est\u00e1s escribiendo pruebas y parece que tienes m\u00e1s trabajo. Suena muy raro, pero en realidad resulta m\u00e1s r\u00e1pido y m\u00e1s est\u00e9tico. Cuando escribes una prueba, ya piensas mucho en c\u00f3mo ser\u00e1 el c\u00f3digo, c\u00f3mo ser\u00e1 invocado, y tambi\u00e9n qu\u00e9 comportamiento esperamos de \u00e9l. No solo dices que has escrito alguna funci\u00f3n y que hace algo. Primero piensas en qu\u00e9 condiciones tendr\u00e1, c\u00f3mo ser\u00e1 invocada. Cubres esto con pruebas y a partir de ah\u00ed entiendes c\u00f3mo se ver\u00e1n las interfaces dentro de tu c\u00f3digo. Esto influye mucho en la arquitectura. Tu c\u00f3digo autom\u00e1ticamente se vuelve m\u00e1s modular, porque primero intentas entender c\u00f3mo lo vas a probar, y solo luego lo escribes. <\/p>\n
<\/p>\n
En mi experiencia con TDD, en alg\u00fan momento contrat\u00e9 un mentor de Ruby cuando a\u00fan era programador de Ruby. \u00c9l me dijo: \"Hagamos esto usando TDD\". Y pens\u00e9: \"Vaya, ahora tengo que escribir algo adicional\". Entonces acordamos que durante dos semanas, escribir\u00eda todo el c\u00f3digo funcional en Python usando TDD. Al cabo de esas dos semanas, comprend\u00ed que ya no quer\u00eda volver atr\u00e1s. Al intentar aplicarlo en todos lados durante dos semanas, te das cuenta de lo mucho m\u00e1s f\u00e1cil que se vuelve incluso solo pensar. Pero no es obvio, as\u00ed que recomiendo a todos que, si sienten que TDD es complicado, largo y innecesario, lo intenten por dos semanas. A m\u00ed me bastaron esos dos para darme cuenta.<\/p>\n
<\/p>\n
(Dmitry) Podemos desarrollar esta idea desde la perspectiva de la explotaci\u00f3n de infraestructura. Antes de lanzar algo nuevo, hacemos un monitoreo y luego lo lanzamos. En este caso, el monitoreo se convierte en una prueba normal. Y hay desarrollo a trav\u00e9s del monitoreo. Pero casi todos dicen que es largo, que les da pereza, y que hacen un borrador temporal. Si hacemos un monitoreo adecuado, entendemos el estado del sistema CI. Y en el sistema CI hay mucho monitoreo. Entendemos el estado del sistema, entendemos lo que hay dentro de \u00e9l. Y durante el desarrollo, precisamente creamos el sistema para que alcance el estado deseado.<\/em> <\/p>\n<\/p>\n
Estas pr\u00e1cticas son conocidas desde hace tiempo. Hace unos 4 a\u00f1os lo discutimos. Pero en 4 a\u00f1os pr\u00e1cticamente nada ha cambiado.<\/em> <\/p>\n<\/p>\n
Pero propongo finalizar esta discusi\u00f3n oficial en esta nota.<\/em><\/p>\n<\/p>\n
Video (insertado como elemento multimedia, pero por alguna raz\u00f3n no funciona):<\/p>\n
\nhttps:\/\/youtu.be\/zZ3qXVN3Oic<\/a><\/noindex> habr.com<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u041e\u0431\u0441\u0443\u0434\u0438\u043c \u043f\u043e\u0447\u0435\u043c\u0443 CI-\u0438\u043d\u0441\u0442\u0440\u0443\u043c\u0435\u043d\u0442\u044b \u0438 CI \u2013 \u044d\u0442\u043e \u0441\u043e\u0432\u0441\u0435\u043c \u043f\u0440\u043e \u0440\u0430\u0437\u043d\u043e\u0435. \u041a\u0430\u043a\u0443\u044e \u0431\u043e\u043b\u044c CI \u043f\u0440\u0438\u0437\u0432\u0430\u043d\u043e \u0440\u0435\u0448\u0438\u0442\u044c, \u043e\u0442\u043a\u0443\u0434\u0430 \u0432\u043e\u0437\u043d\u0438\u043a\u043b\u0430 \u0438\u0434\u0435\u044f, \u043a\u0430\u043a\u0438\u0435 \u043f\u043e\u0441\u043b\u0435\u0434\u043d\u0438\u0435 \u043f\u043e\u0434\u0442\u0432\u0435\u0440\u0436\u0434\u0435\u043d\u0438\u044f \u0447\u0442\u043e \u043e\u043d\u043e \u0440\u0430\u0431\u043e\u0442\u0430\u0435\u0442, \u043a\u0430\u043a \u043f\u043e\u043d\u044f\u0442\u044c \u0447\u0442\u043e \u0443 \u0432\u0430\u0441 \u0435\u0441\u0442\u044c \u0438\u043c\u0435\u043d\u043d\u043e \u043f\u0440\u0430\u043a\u0442\u0438\u043a\u0430, \u0430 \u043d\u0435 \u043f\u0440\u043e\u0441\u0442\u043e \u0443\u0441\u0442\u0430\u043d\u043e\u0432\u043b\u0435\u043d\u043d\u044b\u0439 Jenkins. \u041c\u044b\u0441\u043b\u044c \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u0434\u043e\u043a\u043b\u0430\u0434 \u043f\u0440\u043e Continuous Integration \u043f\u043e\u044f\u0432\u0438\u043b\u0430\u0441\u044c \u0435\u0449\u0435 \u0433\u043e\u0434 \u043d\u0430\u0437\u0430\u0434, \u043a\u043e\u0433\u0434\u0430 \u044f \u0445\u043e\u0434\u0438\u043b \u043f\u043e \u0441\u043e\u0431\u0435\u0441\u0435\u0434\u043e\u0432\u0430\u043d\u0438\u044f\u043c \u0438\u0441\u043a\u0430\u043b \u0440\u0430\u0431\u043e\u0442\u0443. \u041f\u043e\u043e\u0431\u0449\u0430\u043b\u0441\u044f […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":93886,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-93885","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"Integraci\u00f3n](\"\/wp-content\/uploads\/2020\/09\/ed8a32ae63b8dccfc8b4893ab27f1527.jpg\")
<\/p>\n