Inglés para Devs: Mejora tu inglés, con Darwinglish
La industria tech habla en inglés y la IA lo está cambiando todo. En Inglés para Devs destripamos un término por episodio junto a developers con más de 20 años de experiencia en empresas de clase mundial. Esta temporada con Vicente Plata, Staff Engineer en Pinterest y xAI — alguien que literalmente construye herramientas de AI mientras hablamos.
Inglés para Devs: Mejora tu inglés, con Darwinglish
"Continuous Integration / Continuous Delivery"
Use Left/Right to seek, Home/End to jump to start or end. Hold shift to jump forward or backward.
¿Qué signfiica y cómo se dice correctamente?
Sigue a Darwin: https://twitter.com/darwinglish
Sigue a Swanros: https://twitter.com/Swanros
Escucha El Podcast DEV: https://elpodcast.dev
Suscríbete a El Newsletter DEV: https://elnewsletter.dev
📩 ¿Quieres mejorar tu inglés técnico todos los días?
Únete a nuestra comunidad gratuita:
https://chat.whatsapp.com/H9OQT0MlsIcLOfd7viGzrb
📄 Encuentra la descarga la worksheet gratuita de este episodio también en la comunidad
🗣️ Únete a nuestros club de conversación enfocados en el mundo Tech
https://inglesparadevs.io
📲 Sígueme en redes para más tips:
Twitter: @SoyDarwinglish
Instagram: @Darwinglish
YouTube: www.youtube.com/c/InglésparaDevs
🎧 Aprende inglés, Inglés para Devs.
Ayúdame, Oscar, por favor. Ya vimos que fue deploy. Ya me explicaste qué es deploy. Ya me explicaste la diferencia entre deploy y release. Pero mencionaste que en algún episodio pasado que tenía el continuous delivery Y digo delivery, y lo pongo con mayúsculas porque muchas personas nos vamos con el delivery. Delivery. Delivery, no, no, no, no sé qué, o sea, eso. Pero es delivery. Y quiero que me digas en dónde se encuentra entre release and deploy el continuous delivery, o si es algo que está transversal. Es como parte de lo mismo, y más bien yo diría que el continuous delivery puede ser más bien como una estrategia para hacer tus deployment y tus releases. Continuous delivery en general es como una filosofía que te está diciendo que siempre tienes que estar sacando cosas a producción. Que en cuanto algo esté listo y en cuanto algo esté en verde y pasen las pruebas y esté disponible, no hay razón para que eso se quede en tu universo privado de código. Entonces, yo diría que continuous delivery como tal es más bien una filosofía de cómo vas a hacer tu deployment y tus pero cómo se ve ese continuous delivery puede ser puede tener un montón de variaciones de empresa a empresa y dependiendo de objetivos dentro de todo este concepto de continuous delivery pues en realidad te puedes poner a pensar en términos por ejemplo de cómo vas a hacer tus integraciones cómo vas a hacer tus testing cómo vas a hacer tus validaciones cuál es la cultura de trabajo que estás intentando propiciar porque también muchas veces por ejemplo hay algunas personas como yo en este caso que yo no estoy tan de acuerdo con la filosofía de hacer continuous delivery porque básicamente estás siempre sacando cosas, siempre estás como como mandando cosas a producción y eso a final de cuentas termina como impactando, siento yo, un poco la calidad de tu software porque siempre hay una siguiente oportunidad de arreglar las cosas Oye, pero me llama mucho la atención cómo me estás platicando esto te veo así como con risa y creo que es porque como tú dices en distintas empresas toman diferentes filosofías respecto del continuous delivery habrá empresas entonces que sí les gusta que todo el tiempo estén entregando precisamente mira ahí está el concepto todo el tiempo entregar entregar entregar y habrá empresas que no entonces y es que por ejemplo hay empresas como Facebook que tienen este mantra que es move past and break things que es básicamente Básicamente, lo que nos importa es movernos. Dale, dale, dale, dale. Siempre saca cosas a producción. Prueba en producción. Atrévete, ¿no? Y yo vengo de un background de desarrollo móvil donde desafortunadamente o afortunadamente, depende cómo lo quieras ver, el continuous delivery no es tanto una opción porque no es como que yo pueda mandar una aplicación al App Store sin que pase por un proceso de revisión. Hay un stopgap. Hay un espacio ahí por el cual yo tengo que tener en cuenta. Entonces, eso de alguna manera, cambia mi filosofía de que para mí el continuous delivery no es algo como que, una, esté acostumbrado a hacer, y dos, sienta que agrega tanto valor, ¿no? Entonces, ahora, te entiendo, te entiendo, es que te apasiona, ya te vi, ya te di, quieres defender tu punto, pero vamos a esto, ¿por qué no me explicas entonces la diferencia entre continuous delivery y continuous integration? Ok, y probablemente vamos a tener que hacer otro segmento exclusivamente de Continuous Integration, pero rápidamente. Lo que significa Continuous Integration es de que así como estás mandando código, o sea, cuando estás terminando tu código, lo mandas a un servicio para que ese servicio te asegure de que tu código, tu pedazo de código nuevo que acabas de hacer, se integre correctamente con el resto del ecosistema. Que no hayas roto nada. Que no vaya a llegar a darle en la torre algo. Exactamente. Y ese es un proceso automático, ¿no? Donde tú envías tu código, tú terminas tu feature, tú terminas tu bug fix, lo mandas a un servicio de Continuous Integration o CI, así también se le conoce, un servicio de CI, que básicamente agarra tu código, lo mete en una licuadora y se asegura de que tu código no rompa otra parte de la aplicación. Eso es Continuous Integration. Perfecto, perfecto. Pues ya está. Release, deploy, continuous delivery and Continuous Integration. Ok. Continuous. No continuous, chavos. Continuous. Yes. Ok.
SPEAKER_01Gracias.
UNKNOWNNice.