Un viaje de los mil binarios

Hola, hola. Estoy muy contento de que estén aquí. Uno de los enlaces más importantes que tendrán es el que se muestra en mi pantalla en este momento. Si lo siguen, podrán obtener una instancia gratuita. Esto es importante porque para seguir todos los ejemplos y hacer exactamente lo mismo que voy a hacer en la demostración, usualmente lleva un poco de tiempo aprovisionar las instancias. Por lo tanto, es importante que comiencen a hacerlo en este momento para que cuando lleguemos a la parte práctica de este taller, nuestras instancias estén en funcionamiento. Y, bueno, estoy aquí en Suiza, en Basilea, Suiza. Estoy muy emocionado y feliz de que estén aquí conmigo. Así que comencemos con la sesión o el taller. Y publicaré el enlace y lo tendrán en algunas de las diapositivas, por lo que si se unen más tarde o no lo han hecho todavía, todavía hay una oportunidad. Así que este soy yo. Soy de México. Vivo en Suiza, como trabajo para una empresa, así que eso es exactamente a donde van con ese enlace. Nuevamente, esta sesión y este taller se tratan de dependencias. Y si están comenzando a aprovisionar su nivel gratuito, esto es lo que están viendo. Y pueden comenzar de forma gratuita. Pueden elegir cualquier nombre allí. Y como dije, lleva tiempo. Por lo tanto, es por eso que los animo a hacerlo ahora mismo. Y mientras hacen eso y todo se está aprovisionando, comencemos con los temas realmente interesantes. Entonces, la presentación y el taller de hoy se trata de una parte clave de nuestro proceso de desarrollo de software. Y son las dependencias. No necesitamos reinventar la rueda cada vez que queremos lograr un nuevo nivel de funcionalidad o entregar software más rápido. Queremos y reutilizamos software escrito por otros todos los días. Dependencias de software. Pero al hacer eso, a veces nos metemos en problemas. Entonces, las dependencias no solo se usan mientras estamos desarrollando. Se usan para runtime o testing. ¿Y saben qué? Las dependencias no son todas iguales. Así que voy a darles dos afirmaciones y ustedes me dirán si son verdaderas o falsas. En realidad, responderé eso por ustedes. Pero entienden la idea. Entonces, las dependencias son colecciones que contienen código probado de alta calidad que proporciona funcionalidad que requiere una experiencia significativa para desarrollar. Eso es cierto. Algunas de nuestras dependencias son realmente altamente funcionales. Están muy bien probadas. Ese es el caso de nuestros frameworks. Entonces, es cierto. Los administradores de dependencias como NPM han hecho posible que funcionalidades casi triviales se puedan empaquetar y publicar. Eso es cierto. Publicar en el registro de NPM es muy sencillo. Y estos son ambos extremos del espectro. Por un lado, tenemos bibliotecas o piezas de código que requieren mucho trabajo, tienen muchas pruebas y proporcionan mucha funcionalidad y tal vez son opinionadas. Por otro lado, tenemos piezas de código muy pequeñas. Entonces, tenemos que ver cuáles son los diferentes tipos de dependencias que tenemos. Frameworks, bibliotecas, paquetes, módulos y recursos. Esto es típico de lo que nos referimos como nuestras dependencias. Entonces, ¿qué es nuestro recurso? Un recurso es una colección de archivos, por ejemplo, plantillas, medios, audio, video o imágenes, texto plano o incluso blobs que deben incluirse en nuestras aplicaciones para ejecutarse o mostrarse correctamente. Esto no necesita ser binario.

Y en el mundo de JavaScript, esto es bastante evidente. Por ejemplo, Angular se define como una plataforma. Mientras que React, ellos dicen que es solo una biblioteca o un grupo de bibliotecas para construir interfaces de usuario. Por lo tanto, son muy claros sobre cuál es el propósito de sus bibliotecas o frameworks. Y en el otro extremo del espectro, como les dije antes, tenemos frameworks y tenemos paquetes muy pequeños. Y esto es una colección de micro paquetes de NPM, a veces de solo una línea de código.

Entonces, hay diferentes tipos de dependencias. Y tener una idea clara o una idea clara de qué tipo de dependencias tenemos en nuestros proyectos nos hace darnos cuenta y también nos hace pensar cuáles son las cruciales, cuáles son las importantes. ¿Cuáles son solo cosméticas? Otras se pueden intercambiar fácilmente. Y también algo que debemos tener en cuenta es nuestro grado de necesidad. Porque incluso si es una biblioteca grande, no es realmente necesaria. Y estos dos factores son realmente importantes para ayudarnos a decidir la frecuencia de actualización. Los costos de migración, nuestros esfuerzos de limpieza. Porque eso debe suceder en cada aplicación. Por ejemplo, tenemos una dependencia de cinco bibliotecas principales. O cinco bibliotecas principales de una plataforma generalmente. ¿Cuándo actualizamos? ¿Cómo probamos? ¿Y cuál es nuestra propia hoja de ruta? ¿Qué tan dependientes somos de un código que no es tan bueno? Esta es la pregunta que debemos hacer cada vez que decidamos agregar una nueva dependencia en nuestros proyectos. O cuando intentamos pensar en el futuro, o cuando tenemos un problema con una dependencia específica. Por lo tanto, hacer que las dependencias sean importantes, nuestro nivel de dependencia, nuestro nivel o tipo de dependencia es realmente importante.

Entonces, antes de continuar con las malas noticias, les recordaré nuevamente el enlace para comenzar a aprovisionar su entorno, para que puedan trabajar conmigo durante la parte de demostración. Así que tenemos dependencias, todo tipo de dependencias, y dependemos de ellas de diferentes

La última vez que vamos a hacer es publicar. Pero como puedes pensar ahora, esto es súper trivial. Ya tengo mi repositorio. Ya tengo mis credenciales. Entonces, ¿cuál es la complicación real aquí? En realidad, no hay ninguna. Así que solo haces NPM publish. En este caso, porque en realidad estamos usando el código open-source de otra persona, lo que hice cuando edité el archivo package JSON es cambiar el nombre y cambiar la versión. Si no cambias la versión y tratas de publicar, bueno, la misma versión ya existe. Así que debería decirte que no, no, no puedes publicar con la misma versión. Pero en este caso, lo que estoy haciendo es cambiar el nombre y la versión para que quede muy claro lo que estamos haciendo. Y cuando lo ejecuto, dice, ¡yay, lo lograste! Y como puedes ver, calcula la integridad y me dice cuántos archivos realmente cargó. Y como puedes ver, lo cambié a DevOps JS dash Rtrim en lugar del nombre original. Y ahora si vamos a nuestro repositorio local, podemos ver que está nuestro artefacto publicado. Y bueno, lo hice. Actualicé todas estas pantallas en la mañana porque siempre me gusta ejecutar las mismas instancias como verás y experimentarás en esta masterclass. Y vamos a pasar a la parte final. Y la parte final es el escaneo de seguridad. Recuerda toda esta idea de que deberíamos confiar un poco más en nuestras dependencias. Así que entro en nuestro repositorio local de MPM y selecciono la opción de rayos X. Así que eso significa que este repositorio en particular será escaneado con rayos X. Y luego voy a la pestaña de rayos X y verifico si está allí. Si no está allí, tengo que agregarlo. Y cuando hago clic en agregar repositorio, me mostrará todos los repositorios que tengo que aún no están indexados por rayos X. Y puedes agregarlo. Ahí están. Y más adelante, puedo ejecutar diferentes funciones para cada repositorio. Y una de ellas es comenzar el indexado.

Ahora, podemos hacerlo juntos. Proyectos. Así que lo que tengo aquí es que voy a eliminar todo. Así que no hay nada bajo mi manga. Lo primero que vamos a hacer es clonar. Así que voy a clonar de nuevo. Y lo voy a poner en el chat. Así que, ¡hola! Así que voy a clonar el proyecto. Y esta es la URL del proyecto. Así que, si quieres usarlo. Quiero decir, es un proyecto que quieres usar. Esto es algo que quieres seguir. Solo se trata de instalar las dependencias, configurar tu repositorio, crearemos tus repositorios y publicaremos un paquete. Así que cualquier cosa puede funcionar. Así que ahora vuelvo a R3. Y no hay nada como este árbol de nuevo. Esto es muy similar a lo que vimos. Eso es todo. Voy a detener mi compartición porque voy a eliminar mi NPM RC. Y odio que no haya forma de mostrar en un script o en un texto plano. Esto es mi secreto. No deberías en texto plano. Permíteme cambiar mi NPM. Así que solo hice lo común a todos mis registros y mi autenticación y todo. Todas las preferencias que tengo para Artifactory. Así que si hago un NPM install y variables de nivel de bloqueo. Me gusta usar variables de nivel de bloqueo porque muestra quién está resolviendo tus dependencias. Así que, nuevamente, lo otro que debería haber mencionado es que realmente funciona con paquetes de ámbito, pero cuando estás creando tu repositorio, verás que ese es el caso. Así que nada, tomó cinco segundos y tenemos lo mismo que te mostré en las capturas de pantalla. Así que eso es perfecto. Tenemos todo así. Quiero decir, esto es NPM install. Estamos resolviendo todo desde el registro de NPM. Así que aquí no hay magia. Así que permíteme, nuevamente, compartir mi navegador ahora. Porque ahora necesitamos mi navegador. Pero primero, necesito abrir mi

Así que de nuevo, el siguiente paso es copiar tu authentication, editar tu archivo npm rc y ejecutarlo. Cuando lo ejecutes, déjame descomentar de nuevo, mi archivo npm rc y cambiar de nuevo el mío y compartirlo de nuevo. De acuerdo, ahora tengo los módulos N voy a eliminarlos de nuevo y de nuevo los voy a instalar. Bueno, en mi caso será súper rápido, 2 segundos en lugar de los 7 que probablemente has visto y esa es la razón por la que no cambié ni eliminé los repositorios. Podría haberlo hecho, pero está bien. Aquí te está diciendo cuál es la URL que estás obteniendo. En realidad, la prueba de DevOps en PM. ¿Está todo el mundo siguiéndome? Ya perdí a alguien. Por favor, díganme. Déjame revisar el chat. A veces me lo pierdo porque el chat se cierra cada vez que cambio la pantalla compartida. De acuerdo. ¿Dónde estoy creando los repositorios? Por ejemplo, si por alguna razón quiero crear otro repositorio, puedo ir a la configuración rápida. la configuración rápida te muestra todos los tipos de paquetes y puedes seleccionar cuáles son, en realidad, los más típicos que tenemos son Docker, genérico, Maven o NPM. Pero si te fijas, también tenemos, así que, tú lo nombras. PHP, tenemos repositorios de Go, así que hay muchos tipos de paquetes y, por supuesto, tenemos el genérico. Y porque, de nuevo, como dije, una de las dependencias que puedes tener son los recursos. Y los recursos pueden ser archivos multimedia. Lo que quieras. Porque a veces también tienen que ser versionados, tienen que ser lanzados, tienen que ser agregados a una versión específica de una aplicación. Así que es importante que tengamos una única fuente de verdad y la única fuente de verdad utiliza la misma configuración para la seguridad y los derechos. Déjame mirar de nuevo mi chat. Por si alguien me está haciendo preguntas. No me gusta bien. Perfecto. No te preocupes. Sí. Puedes seguir la grabación cuando quieras. Así que volvamos aquí. Son solo los repositorios que has visto. Y esto es algo que ya vimos en la prueba local de DevOps. Bueno, en realidad, no. Lo que quiero es mostrarte el test de npm. Aquí es donde tengo todas las dependencias de este paquete que se crearon o se actualizaron en base a esa instalación de npm que acabamos de hacer en nuestro archivo de terminal. Así que, si entras aquí, puedes tener toda la información que tenemos disponible que proviene del registro de npm. Algunos de estos paquetes te dicen, quiero decir, esto es algo casi la misma información que tienes en los paquetes de npm y te puede mostrar quién tiene acceso sobre qué cosa y qué propiedades obtienes de este en particular. Y esta es la parte donde dije que este tipo de herramientas nos facilitan la vida. Porque si por alguna razón queremos anotar o mejorar la información que está disponible para estas dependencias en particular, podemos crear nuestro propio nombre de propiedad con nuestro propio valor de propiedad. Y el valor de la propiedad puede ser texto, puede ser números, puede ser numérico, puede ser un rango específico. Así que tú lo nombras. Eso es súper poderoso.

De acuerdo. Entonces, cuando ejecutas esto, automáticamente estás llenando tu repositorio remoto porque ha sucedido por primera vez, la solicitud. Ahora tienes tu caché, tus dependencias. Lo que voy a hacer ahora es cambiar el package JSON. Y aquí lo voy a llamar, vamos a implementar una nueva versión, que será devops.js5, y lo llamaremos devops.js la nueva versión, porque ¿por qué no? De acuerdo, devops.js. Abrí otro devops. Nueva versión. Así que está muy claro. No voy a cambiar todo, nada más. Así que el readme es y todo sigue igual, así que no te confundas. Ya necesito el paquete npm. Cambio, vamos a revisar. Solo cambio el nombre. Solo cambio la versión. Así que cada vez que publico en mi repositorio, es fácil hacerlo. Se encontró mi enlace al repositorio y cuando vuelvo a cambiar al navegador, te mostraré dónde obtienes esa URL y qué es en realidad lo que tienes en la pestaña de implementación. Selecciona tu repositorio local de npm. Vuelve a configurarme. Aparece la ventana que te muestra todos los diferentes archivos de configuración. Si vas a la segunda pestaña, está la implementación. Puedes usar el registro donde deseas publicar tu paquete. Y por mi curiosidad, vuelve a configurarme en el virtual. Y nuevamente, si vas a la implementación, verás que es la misma URL. Así que ahora voy a hacer solo el npm publish. Pero en este caso, estoy especificando no en el package JSON, estoy publicando directamente en el registro. Porque no modifiqué eso en el package JSON. Y como puedes ver, tengo un sí, versión 1.65. Con la forma corta y nuevamente, cinco archivos. Y nuevamente, voy a compartir la pantalla de orden. Esta vez apareció en el primer intento. ¡Yay! De acuerdo. Lo siento. Es porque me tomó un tiempo. Así que, déjame refrescar. Así que ahora, tenemos tan pronto como refresco, ahora tenemos el DevOps.js, nueva versión. Y cuando haces clic aquí y abres y expandes, puedes ver que la versión de MPM es la 105. Tiene toda la información diferente. Y si voy a los repositorios en la segunda pestaña y veo los repositorios y entro en el remoto. Recuerda cuando te decía que esto era posible en el archivo de configuración en los repositorios, verifica cuáles tienes si están listados por diferentes tipos. Este es el lugar donde lo estamos haciendo. Y el más importante es este en mi remoto. Déjame expandir un poco. Espero que no haya arruinado nada aquí. Entonces, si selecciono nuevamente, mi DevOps este, aquí es donde puedes habilitar la indexación con X ray. Entonces, este repositorio en particular se está indexando, y si regresas aquí en tu primero, en el segundo, puedes ver la configuración y el seguimiento, las políticas. Entonces, si ahora vas a tus artefactos, verás que nuestro último, este, MPM, no, lo siento, lo siento, lo siento, no estoy leyendo correctamente, mi local, aquí, pasa, se está escaneando, y no se encuentran violaciones. Y aquí puedo ver la licencia. Así que está bien. Eso es perfecto. Así que ahora si reviso aquí nuevamente, porque puedes seleccionar aquí también, puedes ver que tengo dos artefactos diferentes con el mismo nombre.

Bien, en este caso, solo es el archivo JSON, así que está bien. Y aún puedes ver la misma información. Entonces, lo que hemos hecho es crear diferentes repositorios, tres tipos de repositorios, tres versiones de repositorios, locales, remotos y virtuales. Hemos visto que hay diferentes tipos de repositorios, casi todos los repositorios siguen el mismo patrón. Puedes configurarlo, seleccionar los diferentes permisos, puedes especificar el nivel de granularidad que desees, puedes ejecutar análisis de seguridad en ellos y puedes publicar muy fácilmente. Y una vez que tienes un repositorio virtual, puedes crear nuevos repositorios virtuales, donde puedes agregar diferentes repositorios. Pero deben ser del mismo tipo. Es decir, todos MPM, todos Maven, todos PHP, pero todos del mismo tipo, o todos genéricos. No te recomiendo usar genéricos y mezclar diferentes tipos de genéricos. En primer lugar, porque perderás un poco de rendimiento si no estás utilizando el tipo de paquete especializado. Como dije antes, están optimizados para el tipo de paquete específico. Así que siempre utiliza el nativo. Y no sé, ¿qué más? ¿Qué más puedo mostrarte? Bueno, en realidad puedo mostrarte mucho, pero no quiero comenzar algo que no podamos terminar ahora mismo. ¿Hay alguna pregunta hasta ahora? Si no, te mostraré la última diapositiva. Y luego te dejaré ir. Como dije, paso mucho tiempo dando sesiones o trabajando con clientes, pero siempre pido comentarios a mis colegas y, por supuesto, a los asistentes a mi sesión. Así que por favor, por favor, por favor, contáctame si tienes alguna pregunta, comentario o sugerencia. Siempre estoy dispuesto a recibirlos.