Un viaje de los mil binarios

Rate this content
Bookmark

En este masterclass exploraremos las ventajas de tener un gestor de repositorios de artefactos universal, robusto y maduro en el corazón del ciclo de desarrollo de software. Exploraremos las preocupaciones más importantes al desarrollar aplicaciones ricas y adaptarse a un mercado de ritmo rápido. En los últimos años, las grandes empresas se han beneficiado de técnicas como las pruebas AB para mejorar sus productos, aumentar el tráfico, mejorar la experiencia de usuario y ofrecer nuevas funcionalidades. Esto solo es posible si hay una infraestructura de devops sólida en su lugar con herramientas que proporcionen, entre otras cosas, control, seguridad, versionado y buen soporte de anotación. No se trata solo de tener las herramientas adecuadas, sino de saber cómo usarlas al máximo.

67 min
29 Mar, 2022

Comments

Sign in or register to post your comment.

Video Summary and Transcription

El masterclass cubre la importancia de las dependencias en el desarrollo de software, los diferentes tipos de dependencias, los desafíos y problemas de seguridad con las dependencias, el papel de los repositorios en la gestión de dependencias y el proceso de resolución de dependencias y publicación. También se discute la configuración de los repositorios y la autenticación, y la creación y configuración de diferentes tipos de repositorios. El masterclass enfatiza la necesidad de comprender las dependencias, garantizar la seguridad y utilizar herramientas como JFocusray y OWAS dependency check para el análisis y evaluación.

Available in English

1. Introducción a las Dependencias

Short description:

Esta parte trata sobre la importancia de las dependencias en el desarrollo de software. Se enfatiza la necesidad de reutilizar software escrito por otros y se discuten los diferentes tipos de dependencias como frameworks, bibliotecas, paquetes, módulos y recursos. También se destaca el hecho de que las dependencias no son todas iguales y pueden variar en términos de funcionalidad y complejidad. El texto anima a la audiencia a comenzar a aprovisionar su nivel gratuito y les proporciona un enlace para hacerlo. En general, esta parte prepara el escenario para el taller e introduce el concepto de dependencias en el desarrollo de software.

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.

2. Tipos de Dependencias

Short description:

Esta parte explica los diferentes tipos de dependencias en el desarrollo de software, incluyendo módulos, paquetes, bibliotecas y frameworks. Se enfatiza la importancia de comprender el propósito y la funcionalidad de cada tipo de dependencia para tomar decisiones informadas. También se destaca la necesidad de considerar el grado de necesidad y el impacto de las dependencias en las actualizaciones, los costos de migración y los esfuerzos de limpieza. La parte concluye recordando a la audiencia que comiencen a aprovisionar su entorno y resaltando la importancia de las dependencias en el desarrollo de software.

Esto es algo de lo que dependemos y necesitamos. Y un módulo. Este es un conjunto de funciones o métodos que proporciona funcionalidad autocontenida. Un módulo generalmente tiene una interfaz que especifica explícitamente y abstractamente tanto la funcionalidad como una implementación. Por lo tanto, podemos verlo como una caja negra. Un paquete es una colección de módulos que tienen, en general, el mismo propósito funcional. Por lo general, es un directorio. Y esto solo aplica a Python y JavaScript. Tenemos una estructura diferente para un paquete, pero el concepto sigue siendo el mismo. Por lo general, un directorio contiene un archivo que describe los metadatos sobre el paquete. Y generalmente se agrupan según la funcionalidad. Por lo tanto, es fácil abstraer o omitir algunos paquetes completos. Y una biblioteca. Una biblioteca es una colección de funcionalidades relacionadas definidas en varios paquetes. Esencialmente, es un conjunto de funciones que se pueden llamar. Cada llamada realiza un trabajo y devuelve el control al cliente, al framework o a la aplicación. Y finalmente, los frameworks. Un framework incorpora una definición abstracta con más comportamiento incorporado. Y para usar un framework, generalmente, es al revés. Incluimos nuestro código en algunos lugares del framework y él nos llamará. Por ejemplo, esta es una de las diferencias más interesantes entre un framework y una biblioteca. Y generalmente son más opinionados. Entonces, los frameworks o plataformas suelen ser más grandes, más opinionados. La integración entre los diferentes componentes funcionales está más conectada. Y generalmente tienen una larga lista de versiones o al menos una hoja de ruta. Es muy maduro. Porque generalmente requiere un grupo más grande de desarrolladores para construir su funcionalidad. Por lo general, hay una licencia y, por supuesto, hay un conjunto de pruebas.

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

3. Desafíos con las Dependencias

Short description:

Al agregar una dependencia, externalizamos el trabajo de desarrollo y mantenimiento a otra persona. Esto expone nuestro código a los fallos y defectos de las dependencias, ya sea que sean de código abierto o cerrado. Confiar en bibliotecas de código abierto es un desafío, ya que no hay una garantía contractual o una empresa detrás de ellas. Sin embargo, la reputación puede ser un factor para decidir si se confía en una biblioteca. El código abierto tiene sus beneficios y personalmente estoy involucrado y apasionado por contribuir a él.

De diferentes maneras. Entonces, ¿qué podría salir mal? Cuando agregamos una dependencia, también externalizamos el trabajo de desarrollar ese código, diseñarlo, escribirlo, probarlo, depurarlo y mantenerlo a otra persona. A menudo, son personas no programadoras. Por lo tanto, el uso de ese código específico expone todo lo que estamos haciendo a los fallos y defectos de las dependencias. Y esto no está realmente relacionado con si es de código abierto o cerrado. De hecho, hay un montón de artículos que muestran que no hay una preferencia real de dónde se encuentran la mayoría de los errores. Puedo mostrártelos si estás interesado en ellos. Puedo enviarte todas las referencias. Pero nuevamente, con el código abierto, el código abierto cambia muchas cosas. En el pasado, antes de que llegara a nuestras vidas, los desarrolladores confiaban en que otros escribieran esto o en lo que dependían. Afortunadamente, soy más joven que eso. Así que comencé con el código abierto desde el principio. Por lo general, o ellos solían comprar el software. Por ejemplo, eran los compiladores o los controladores para un hardware específico. Por lo tanto, existía esta idea contractual de que si algo salía mal, había una empresa o un producto detrás de ellos. Y con el código abierto no es así. Tenemos licencias que dicen `tal cual`. ¿Y cómo decidimos si esta es una biblioteca confiable o no? A veces se basa en la reputación. No me malinterpretes, no estoy diciendo que el código abierto sea malo. De hecho, soy una persona que está muy involucrada en el código abierto. Y amo el código abierto. Siempre estoy deseando contribuir.

4. Seguridad y Problemas de Confianza con las Dependencias

Short description:

En los últimos años, ha habido varios problemas de seguridad y confianza en el ecosistema de JavaScript y NPM. Ejemplos incluyen paquetes no publicados que causan interrupciones, cambios de propiedad que rompen sistemas Linux, credenciales comprometidas que llevan al robo de datos y paquetes maliciosos que causan interrupciones y roban tokens. Para abordar estos problemas, herramientas como JFocusray, OWAS dependency check y Scorecards pueden ayudar a analizar y evaluar la seguridad de las dependencias. Además, un artículo en ACMQ sugiere hacer preguntas sobre documentación, diseño de API, calidad de código, pruebas, corrección de errores y mantenimiento para evaluar el estado de las dependencias.

para contribuir de manera inteligente de una forma u otra. Entonces, ¿qué ha sucedido en el mundo de JavaScript o en el entorno de NPM en los últimos años? Bueno, todos recordamos en marzo de 2016, un paquete llamado LeftBatch que era muy popular con muchas bibliotecas de JavaScript. Después de una disputa de nombres, fue eliminado. Y causó tanta interrupción que NPM tuvo que republicarlo tres horas después. Y después de este evento, cambiaron sus políticas de eliminación. El siguiente que salió en las noticias fue en febrero de 2018, hubo un problema con la versión 570 de NPM. Resulta que en los sistemas Linux, cambió la propiedad del sistema de archivos. Así que, en realidad, rompieron las máquinas Linux En julio de 2018, las credenciales de NPM de uno de los mantenedores de ESLint scope fueron comprometidas. Hubo una versión 372 en la que, en esta versión en particular, lo que sucedió fue que las credenciales de NPM de la máquina que ejecutaba ESLint scope fueron robadas y subidas. En noviembre de 2018, se descubrió que había una nueva versión 336 de event stream. Este paquete en particular incluía un flat map strip que contenía una carga útil encriptada que robaba bitcoins de algunas aplicaciones. Y estos son los dos más recientes y tuve que agregar uno nuevo, pero veremos esa diapositiva en abril de 2020. Un pequeño paquete llamado ISPROMIS causó una interrupción en varias aplicaciones de lista. En enero de 2022, y probablemente hayas oído hablar de esto, el mantenedor de colors hizo cambios que imprimían texto basura en un bucle infinito. Y esto es lo que realmente le sucedió a Aron Schwartz. Y más recientemente, esto fue, déjame ver, esto fue a principios de este año, hubo algunos paquetes maliciosos de NPM que robaron los tokens de puntuación. Y el más reciente, esto fue la semana pasada, y el desarrollador detrás de un paquete NPM muy popular llamado node, IPC, lanzó una versión subatómica de la biblioteca. En realidad, esta versión en particular no fue descargada mucho hasta que el evangelista Rhea agregó el módulo a la dependencia. Bueno, en realidad la dependencia de node no era el paquete malicioso, sino que fue una dependencia que agregó Rhea evangelist a node PC, lo que hizo que por ejemplo, Vue JS dependiera de él. Así que eso causó el problema. Entonces, aquí hay algunos problemas. Hay algunos problemas de seguridad y confianza en la comunidad. Hay algunos problemas de seguridad y confianza con el código que consumimos. Y hay herramientas que nos pueden ayudar. Y por supuesto, una de ellas y la vamos a probar ahora mismo, bueno, en unos minutos, es JFocusray, una herramienta de seguridad de aplicaciones adjunta a Artifactory, que realiza un análisis binario completo. Y no solo análisis binario, también verifica en profundidad todas las capas de todas las dependencias, por ejemplo, si tienes imágenes de Docker, archivos zip o paquetes. La otra que te recomiendo es OWAS dependency check. Esto es algo mantenido por esta fundación, y te dirá qué dependencias tienen algún problema. La tercera, pero esto es más si eres un desarrollador de código abierto, o mantenedor o líder de proyecto. Scorecards es un proyecto que ejecuta diferentes heurísticas asociadas con la seguridad del software y asigna una puntuación. Así, de cero a diez. Y proporciona un informe, este informe se envía a la Linux Foundation y obtienen más información sobre el estado del código abierto y la seguridad en los proyectos de código abierto. Así que eso les ayuda. Y también ayuda a los posibles usuarios o consumidores de las diferentes bibliotecas. Así que te sugiero totalmente que las uses. Y finalmente, esto es más para comenzar las discusiones con tus gerentes o llevarlo aguas arriba. Hay un artículo en el ACMQ. Y trata sobre cómo sobrevivir a las dependencias de software. Y una de las cosas que menciona es que el costo esperado de tener un fallo en tu aplicación depende de la suma de todos los costos pero también de la probabilidad de que algo suceda como un riesgo. Así que dice que, para prevenir eso o reducirlo, deberíamos hacer algunas preguntas sobre cómo está o cuál es el estado de nuestras dependencias. En realidad, algunas de estas preguntas inspiraron el proyecto Scorecards, o al menos se intersectan. Así que, en primer lugar, debes verificar si hay documentación. Eso suele ser una buena señal, aunque a algunos desarrolladores no les gusta hacer documentación. A otros les encanta hacerlo, pero la documentación es importante. ¿Están bien diseñadas las API? ¿Hay un diseño claro, un diseño consistente? ¿Llamamos al parámetro de la misma manera en diferentes versiones? Bueno, no en esta versión, porque puede haber una ruptura, pero al menos en API similares en la misma versión, ¿puedes ver que hay un diseño claro en el conjunto de API o en la documentación? Calidad de código, tenemos que verificar eso. No estoy diciendo que ejecutemos un análisis de código estático en el código fuente de todas nuestras dependencias que estamos introduciendo, porque claramente tenemos dependencias directas y dependencias transitivas, pero nuevamente, en las que dependes mucho, esto es importante, porque va a doler más. Bueno, podemos entrar en esa discusión. Entonces, la calidad de código, ¿el código está bien escrito? ¿Es algo que te gustaría depurar en caso de que algo salga mal? Pruebas, ¿hay pruebas para esta biblioteca en particular? ¿Puedes ejecutarlas? ¿Pasaron? ¿Especifican la funcionalidad básica? Corrección de errores, ¿hacen un seguimiento de los errores, o el proyecto es como, oops, lo hice de nuevo, y tú lo resolverás ¿Cuántos informes de errores están abiertos? ¿Con qué frecuencia los cierran? ¿Responden? Mantenimiento, ¿con qué frecuencia se mantiene? ¿Con qué frecuencia? ¿Cuántas personas están trabajando en el paquete? Si es utilizado por una gran comunidad, es probable que si los líderes del proyecto tienen que renunciar,

5. Seguridad y Gestión de Dependencias

Short description:

Esta parte discute la importancia de la seguridad en las dependencias. Destaca la necesidad de sanitizar las entradas, publicar credenciales de manera responsable y garantizar el cumplimiento de las licencias. La parte también enfatiza la relación entre las dependencias directas y transitorias y los problemas que pueden surgir de las versiones desactualizadas. Menciona el papel de los repositorios en resolver problemas de dependencias y anima a la audiencia a aprovisionar su instancia de Artifactory. La parte concluye explicando los pasos involucrados en clonar un proyecto MPM y ejecutar MPM install, resaltando la gran cantidad de dependencias que se agregan en el proceso.

alguien más tomará la iniciativa. Así que eso es bueno. Esto también depende en la misma dirección. Seguridad. ¿Sanitizan sus entradas si están utilizando entradas extrañas? Entonces hay algunos gadgets de seguridad que pueden ayudarte. ¿Publican credenciales? ¿Son tan ingenuos que lo hacen en su propio proyecto? Probablemente, si lo hacen, no están pensando en la seguridad en primer lugar. ¿Tienen una licencia? ¿Puedes importarla en tu código sin ningún problema más adelante con el cumplimiento? Créeme, no quieres tener discusiones con el cumplimiento. Como dije, tenemos dependencias directas y dependencias transitorias Si eres una dependencia pequeña, muy pequeña, te va a traer 400 dependencias más. Quiero decir, una dependencia pequeña significa que no la necesitas mucho, pero te va a traer a tu proyecto muchas dependencias transitorias con versiones actualizadas. Las versiones desactualizadas, entonces aún necesitas empezar a pensar en cuál es el problema. Y las dependencias no existen en el vacío. Existen en repositorios. Así que la mayoría de los problemas que tenemos con las dependencias y en relación con las dependencias se pueden resolver en el origen donde almacenamos todo tipo de cosas. Y por eso, en primer lugar, vine a trabajar para JFrog, porque antes de esto era consultor, desarrollador senior. Principalmente soy un desarrollador full stack. Pero como viste en mi diapositiva de introducción, suelo ser un desarrollador del lado del servidor Para nosotros en el mundo de Java, es típico que tengamos mucho esfuerzo en crear nuestros repositorios cerca de nuestro entorno de desarrollo. Probablemente sea en todos los lenguajes. Pero lo digo como si tuviéramos esta idea particular. Así que nuevamente, si tienes una instancia de Artifactory, te insto a que lo hagas. Y porque comenzaremos la demostración ahora. Pero antes de comenzar la demostración, voy a mostrarlo en una captura de pantalla. Y voy a explicar cuáles son los pasos que vamos a seguir. Y finalmente, lo haremos juntos. Así que este es el momento en el que te digo qué vamos a hacer y cuáles son los beneficios de lo que estamos haciendo. Como dije, soy un defensor del código abierto. Primero y ante todo. Así que en lugar de darte un repositorio de la aplicación de `Hola mundo`, lo que me gustaría hacer es, sí, puedo enviártelo. Este es el que, quiero decir, sí. No te preocupes. Hubo una pregunta en el chat. Entonces, uno de mis primeros y principales ideas es que como desarrolladores, pasamos casi la misma cantidad de tiempo leyendo nuestro propio código que leyendo el código de otros desarrolladores, por lo que poder profundizar en el código de otros debería ser algo que mostremos mucho y hagamos mucho porque esto es parte de la realidad. Esto es parte de nuestra vida diaria. Entonces, lo que vamos a hacer es clonar, oh Dios mío, esto. Clonar el repositorio de este proyecto MPM en particular, R3. Este es uno de los paquetes micro MPM que te mostré en el video al principio. Así que debería ser muy pequeño y muy trivial. Ese es el punto. Entonces, lo que vamos a hacer es clonarlo. Y vamos a verificar, después de clonar, puedes ver que hay un paquete. Así que en realidad, es un proyecto realmente, realmente pequeño. Y lo primero que voy a hacer es ejecutar el MPM install. Y en el MPM install, de entrada, nada ha cambiado. Podemos ver que las dependencias se resuelven en el registro MPM. Sí. Y tarda cinco segundos en instalar y agregar las 172 paquetes que este pequeño proyecto en particular requiere. No estoy criticando. Sé que esto es normal. No hay nada de qué sorprenderse. No te preocupes.

6. Configuración de Repositorio y Creación de Usuario

Short description:

En esta parte, eliminamos nuestros módulos de nodo y ejecutamos localmente con variables. Agregamos el archivo de configuración de npm y el repositorio. Explicamos el proceso de creación del repositorio y la importancia de completar la página de inicio gratuita. Enfatizamos la necesidad de verificar la cuenta y elegir un nombre de repositorio y proveedor de nube. Destacamos el tiempo que lleva configurar y las preguntas realizadas durante el proceso. Finalmente, creamos un nuevo usuario y un repositorio de NPM con un tipo específico.

Y lo que vamos a hacer es eliminarlo. Y te diré por qué. Vamos a eliminar nuevamente nuestros modules de nodo. Y más tarde, ejecutaremos nuevamente localmente con variables. Y por qué estoy haciendo este código de árbol en particular. La primera razón es porque voy a agregar mi archivo de configuración de npm. Porque voy a agregar mi repositorio. Seguramente te preguntarás, ¿qué repositorio, Ichel? Bueno, el que acabamos de crear con el enlace. Así que, veamos eso. Nuevamente, el enlace. Esto es súper importante. Y en este momento, voy a explicar lo que ya debería haber sucedido. Deberíamos haber llegado a esta página en particular. Como inicio gratuito. Ingresamos nuestro nombre, apellido, correo electrónico y contraseña. Debes verificar tu cuenta si quieres mantenerla. Así que te animo a hacer eso. Puedes elegir tu propio nombre de repositorio y tu propio proveedor de cloud. En este caso, seleccionaré AWS, lo llamaré algo como DevOps JS algo. Y usaré la ubicación central para mi clúster o mi proveedor de cloud. Y como dije, esta es la razón por la que insistí tanto en hacerlo, ¡por favor hazlo! Toma tiempo. Así que te mostrará cuál es el nombre y qué elegiste, ¿verdad? Y después de un tiempo, te dirá sí, perfecto, estás ahí. Y te hará algunas preguntas, no te preocupes. Y te preguntará por qué lo estás usando o cómo quieres usar Artifactory. Es súper potente y polifónico. A veces te mostrará cosas diferentes en tu panel y cómo respondas a esto. Pero no te preocupes, si no respondiste esto, o seleccionaste todo o nada, en realidad nada es posible, pero todo, no importa. Te mostraré cuando lo hagamos juntos cuál fue el problema. Y luego esto sucede. Tienes un nuevo repositorio. Tienes tu nuevo panel que dice en un lado, y las aplicaciones. Y el primer paso que siempre recomendaré es crear un nuevo usuario. Y en este caso, el usuario que siempre me gusta crear es mi usuario administrador. Así que vas a la segunda pestaña y luego tenemos un submenú diferente y luego vas a los usuarios. Así que no te preocupes. Lo haremos paso a paso más adelante cuando lo haga realmente práctico. Esto es solo para que tengas, como, una idea clara de lo que estamos haciendo. No espero que lo hagas ahora mismo. Solo siéntate y disfruta de la película. Así que crea un nuevo usuario y vamos a crear un nuevo repositorio de NPM. Mira, ya cambié a mi usuario administrador. Y regreso a la primera pestaña, donde están mis repositorios. Así que presiono el botón de configuración rápida. Y esto sucede. Tengo todos los diferentes tipos que pueden tener mis repositorios. Quiero decir, como dije, Artifactory admite varios y también admite el genérico. ¿Cuál es la ventaja de usar un tipo de repositorio en particular? La ventaja es que podemos indexar según diferentes data. Quiero decir, no todos nuestros binarios o archivos tienen las mismas propiedades. Y a veces, indexarlos por las correctas o las más comunes o las requeridas hace que sea más rápido. Así que te animo a usar un tipo específico en lugar del genérico.

7. Repositorios de Artifactory y Configuración de npm

Short description:

Esta parte explica el concepto de repositorios locales, remotos y virtuales en Artifactory. Destaca los beneficios de los repositorios virtuales, que permiten una combinación de diferentes repositorios y un fácil segmentación y control. La parte también discute cómo Artifactory almacena eficientemente los datos mediante la vinculación de dependencias compartidas en lugar de duplicarlas. Se enfatiza la importancia de los repositorios virtuales para una gestión eficiente de recursos y una fácil promoción de binarios. La parte concluye explicando el proceso de configuración de un repositorio npm y los pasos involucrados en su uso para la gestión de dependencias.

Luego vamos a crear un nuevo repositorio. Y aquí verás que tenemos tres pestañas. Y explicaré esas tres. Entonces, puedes tener repositorios locales, remotos y virtuales. Tus repositorios locales son donde están tus construcciones, tus binarios, tus archivos, tus bibliotecas, los que creaste. Todo lo tuyo está ahí. Y verás que veremos una pestaña con los repositorios y dice local. Y siempre te dirá en el botón de información qué está sucediendo. El remoto. Esto es para tus bibliotecas de terceros, bibliotecas de equipos y ubicaciones. Aquí es donde es como un proxy y será una caché de esas dependencias. Y veremos a qué me refiero con eso. Y, nuevamente, la segunda pestaña, dice qué y en realidad te muestra cuáles son tus repositorios por cada tipo. Y habrás notado que hay muchos que dicen predeterminado. Voy a explicar eso. Después de haber dicho, ¿qué son los repositorios virtuales? Y esto es en realidad la característica más interesante para mí cuando estaba en mi vida anterior en JFrog. Porque en un repositorio virtual puedes tener una combinación de diferentes repositorios. Y en lugar de tener una lista de todos los diferentes repositorios o hacer referencia a tus dependencias particulares con una lista larga, esta fue nuestra solución. Así que déjame contarte por qué estaba tan emocionado con esto. Como desarrollador de Java en mi vida anterior como consultor solía ir a empresas como bancos o, de hecho, sí, viviendo en Suiza puedes imaginar quiénes eran mis clientes como bancos, farmacéuticas y, por supuesto, bancos y farmacéuticas están muy interesados en security. Así que teníamos todos nuestros entornos de desarrollo y testing y cada paso de nuestro proceso de construcción tenía sus propios repositorios. Q1 tenía sus propios repositorios y así sucesivamente. Si estábamos trabajando en diferentes modules o componentes teníamos los nuestros. Y una de las cosas que me gustaba de Artifactory era que era súper eficiente en cómo almacenaba los data. Así que, como dije, teníamos toneladas de repositorios. Algunas de nuestras dependencias compartidas existían en varios repositorios. Pero el almacenamiento nunca se salía de control. Porque lo que hace JFrog y Artifactory es almacenar la dependencia basada en el SHA. Y lo que hacen los otros repositorios es simplemente vincularse a ella. Así que, más adelante, si estás usando tu repositorio, Artifactory o repositorio de artefactos para promover y seguir cómo han cambiado tus binarios dentro de tu empresa, bueno, es súper fácil. Solo lo mueves a otro repositorio y no lleva tiempo. Así que, si teníamos una aplicación que tenía muchos medios, como imágenes o películas, y eran revisados por quien necesitaba revisarlos. Y más tarde, crearon un paquete y lo enviaron a producción. No copiamos el archivo de recursos completo, como, varios gigabytes. No, solo creamos un enlace en el repositorio. Entonces, por eso los repositorios virtuales son tan importantes, porque si tienes ese nivel de segmentación y control, más adelante es fácil crear este repositorio virtual seleccionando a mano lo que realmente quieres. Y nuevamente, en la parte superior del repositorio virtual, tienes la lista, y hay algunas diferencias que explicaré más adelante de todas las acciones que puedes realizar en tus repositorios. Así que sigamos. Vamos a configurar nuestro repositorio npm. Entonces, tan pronto como cree el repositorio npm, me pedirá, aquí está tu repositorio npm, ingresa tu nombre, y tan pronto como lo haga, se crea y en realidad me muestra cuáles son las configuraciones que debo usar en mi proyecto para usar un repositorio en particular. Entonces, esa es la URL que debo usar para obtener mis dependencias o publicar mis dependencias. y copio, verifico el primer comando, npm config, establezco el registro en la URL que acabo de obtener de mi navegador, y hago un npm install. Y tengo un error. Oops. No me autentifiqué. Así que, bajo en la misma pantalla, está la authentication y en realidad, si ves allí, dice, no muestra tus credenciales. Pero si subes y ingresas la contraseña de tu cuenta, ese fragmento de código en particular tendrá tus credenciales. Por supuesto, no te lo estoy mostrando ahora mismo porque muestra mi token, pero créeme, podrás hacerlo en tu propia instancia. Así que ahora que, nuevamente, lo hice en mi archivo de configuración de npm y lo agregué, puedo ejecutar nuevamente mi npm install, y esta vez voy a usar el modo de variables. Y como puedes ver ahora, bueno, en este caso en particular,

8. Resolviendo Dependencias y Publicación

Short description:

No. Pero ya estoy resolviendo todas mis dependencias en mi repositorio. La primera vez que hago un paquete npm y apunto a mi repositorio de Artifactory, lleva tiempo. Descargamos todas las dependencias requeridas por este proyecto en el repositorio remoto. Luego publicamos el paquete cambiando el nombre y la versión. Calcula la integridad y carga los archivos. Finalmente, escaneamos el paquete en busca de seguridad seleccionando la opción de rayos X en el repositorio local de MPM.

No podemos verlo. Permíteme ver. No. Pero ya estoy resolviendo todas mis dependencias en mi repositorio. Oh, sí. Probablemente estés usando la misma authentication. Porque en realidad, lo siento. Antes de confundir a todos, hubo una pregunta en el chat, y dice que no obtuve este error de authentication, pero estoy conectado a mi GitHub. Así que es probable que ya hayas configurado tus tokens de authentication desde GitHub. Así que los estamos utilizando prestados. Bueno, no, no los estamos tomando prestados en el sentido de que sabemos lo que estás haciendo. No. Sabes que hay protocolos que tenemos como un token de paso. Él dice que estás bien, así que confiamos en él y él confía en ti, por lo que terminamos confiando en ti. Esa es la idea. No puedo ver tus credenciales de GitHub. Esa no es la idea. Así que de todos modos. La primera vez que hago un paquete de npm y apunto a mi repositorio de Artifactory, lleva mucho tiempo. Así que no te emociones demasiado por eso. Es porque lo que está sucediendo es que estamos apuntando al repositorio remoto y estamos descargando por primera vez todas las dependencias que son requeridas por este proyecto en ese repositorio en particular, el repositorio remoto. Y esto es exactamente lo que vas a ver. Ahora tienes eso sirviendo felizmente 400 y algo de artefactos. Y si haces doble clic ahora, verás en el repositorio remoto todos los paquetes necesarios para este proyecto.

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.

9. Gestión de Dependencias y Configuración del Proyecto

Short description:

Y voilà, escaneamos nuestro paquete. Y x-ray nos dice que ha sido escaneado y no hay problema. Más adelante, puedo instalarlo de nuevo. Tenemos varias formas de hacer un seguimiento y enriquecer el conocimiento sobre las dependencias. Es una responsabilidad compartida en toda la empresa. Ahora, podemos hacerlo juntos. Proyectos. Lo primero que vamos a hacer es clonar el proyecto. Esta es la URL del proyecto. Voy a detener mi compartición porque voy a eliminar mi archivo NPM RC. Permíteme cambiar mi NPM. Tenemos todo así. Esto es NPM install. Estamos resolviendo todo desde el registro de NPM. Así que aquí no hay magia. Permíteme compartir mi navegador ahora. Porque ahora necesitamos mi navegador. Pero primero, necesito abrir mi navegador. Que es...

Y voilà, escaneamos nuestro paquete. Y x-ray nos dice que ha sido escaneado y no hay problema. Más adelante, puedo instalarlo de nuevo. Voy a una carpeta diferente, obviamente. Y MPM install DevOps JS. Y sucederá lo que esperamos. Y no agregué la nueva diapositiva. Bueno, obviamente después de instalarlo, cambiará en la parte superior de tu pantalla, te muestra cuántas descargas tienes de este artefacto. Así que tenemos, como verás, hay varias formas de hacer un seguimiento y enriquecer el conocimiento que estamos creando en nuestras empresas o en tus empresas sobre el estado, la funcionalidad o cualquier idea que tengas cerca de tus dependencias, puedes anotarlas, crear metadatos. Por ejemplo, puedes en algún momento crear una prueba y decir que esta dependencia en particular no afecta nuestro rendimiento. Y más adelante, puedes decirme todas las dependencias que se han probado o tienen esta bandera. Y luego no es solo responsabilidad de tu equipo hacer un seguimiento de las dependencias, ayuda. Es una responsabilidad compartida en toda la empresa.

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

10. Provisión de URL y Creación de Repositorios

Short description:

Y necesitas la URL. ¿Todos han provisto su propia instancia? ¿Hay algún problema? Nada? No estoy compartiendo... Bueno, ahora puedo compartir. A veces Zoom es sorprendente. Así que, bueno. Lo que puedo hacer es eliminar todos mis repositorios. Pero veamos. En realidad, puedo eliminar este. Y tan pronto como comiences a crear el prefijo del repositorio, obtendrás el local, el remoto y el virtual. Y tan pronto como lo cree, esto es lo que ya te dije. Puedes seleccionar los diferentes. Aquí ahora tengo toda la información para este en particular. Y si copias este código, tendrás la URL. Nuevamente, si ingresas tus credenciales aquí, tendrás tu propio nombre de usuario y contraseña. ¿Y qué sucede si cierras esta ventana? Vuelves a seleccionar este y vas a configurarme. Lo primero que te sugerí hacer fue agregar tu propio nuevo usuario en identidad y acceso. Si agregas un nuevo usuario, solo tienes que proporcionar un correo electrónico, una contraseña y los roles que deseas. Y aquí es donde comienza a ser interesante. Puedes comenzar a crear grupos.

navegador. Que es... Y necesitas la URL. ¿Todos han provisto su propia instancia? ¿Hay algún problema? Nada? No estoy compartiendo... Bueno, ahora puedo compartir. ¿Dónde está mi navegador? Espera un segundo. Disculpa por eso. Keynote. ¿Dónde está mi navegador? No tengo un navegador. Estoy viendo un navegador. Espera un segundo. Sí. Ahora sí. A veces Zoom es sorprendente. Y no estoy compartiendo toda mi pantalla porque tengo un monitor increíblemente grande, increíblemente. No fue mi idea, fue de mi esposo. Pero no debería quejarme. En realidad es muy, muy útil. Así que, bueno. Lo que puedo hacer es eliminar todos mis repositorios. Pero veamos. En realidad puedo eliminar este. Como dije, tenemos los diferentes artefactos. Los diferentes artefactos se agruparán aquí. Y como puedes ver en la parte superior de esta página, tengo los virtuales. Luego tienes los locales. Y luego tienes los remotos. Y luego estás viendo los remotos en caché. Porque obviamente esto no va a resolver ni almacenar ningún artefacto hasta que realmente lo necesites. Y puedes tener tus propias políticas para cuándo eliminar cada uno de ellos. Entonces, nuevamente, recuerda que si quiero hacer un nuevo repositorio, puedo hacer clic aquí. Seleccionas el tipo de repositorio. Dices que quieres uno nuevo. Y aquí está TEMP. Solo voy a crear TEMP. Y tan pronto como comiences a crear el prefijo del repositorio, obtendrás el local, el remoto y el virtual. Así que puedes seguir tus propias convenciones para crearlo basado en tus equipos o tu etapa o lo que necesites. Vamos con esto. Y tan pronto como lo cree, esto es lo que ya te dije. Puedes seleccionar los diferentes. Aquí ahora tengo toda la información para este en particular. Y si copias este código, este es el código que debemos copiar. Tendrás la URL. Nuevamente, si ingresas tus credenciales aquí, en esta parte tendrás tu propio nombre de usuario y contraseña. ¿Y qué sucede si cierras esta ventana? Estás como, oh Dios mío, ¿dónde está ese archivo de configuración? Lo sé, no te preocupes. Vuelves a seleccionar este y vas a configurarme y eso sucede nuevamente. Así que eso también es realmente importante hacerlo. Y en realidad ni siquiera seguí mi propio guion. Lo primero que te sugerí hacer fue agregar tu propio nuevo usuario en identidad y acceso. Si agregas un nuevo usuario, solo tienes que proporcionar un correo electrónico, una contraseña y los roles que deseas.

11. Configuración de Repositorios y Autenticación

Short description:

Puedes comenzar a restringir el acceso a los repositorios y configurar la autenticación en el archivo npm rc. La opción de configuración rápida te permite crear diferentes tipos de repositorios, incluyendo Docker, Maven, NPM y más. Es importante tener una única fuente de verdad para los recursos, asegurando que estén versionados y lanzados correctamente. El registro npm proporciona información sobre las dependencias, incluyendo los derechos de acceso y propiedades personalizables. Estas herramientas facilitan la mejora y anotación de la información de las dependencias.

Y aquí es donde empieza a ser interesante. Puedes comenzar a crear grupos. Puedes comenzar a restringir quién tiene acceso a qué. Así que ya podemos tener este nivel de granularidad. Voy a cerrar esto porque me molesta un poco. Así que si regresas al primer paso, tienes el artifactory y de nuevo, descartar. Tendrás tus repositorios allí. Y de nuevo, si quieres ver la configuración, partes de cada repositorio, está aquí. ¿Está claro hasta ahora?

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.

12. Publicación y Artefactos del Repositorio

Short description:

Al publicar en el repositorio, cambio el nombre y la versión directamente en el registro. La nueva versión aparece en el repositorio con la información correcta y se indexa con X ray. El paquete se escanea en busca de violaciones y no se encuentran problemas. Se pueden ver múltiples artefactos con el mismo nombre en el repositorio.

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.

13. Creación y Configuración de Repositorios

Short description:

En esta parte, hemos creado diferentes tipos de repositorios, incluyendo repositorios locales, remotos y virtuales. Hemos discutido las opciones de configuración, la capacidad de ejecutar análisis de seguridad y la facilidad de publicación. Se recomienda utilizar tipos de paquetes especializados para un mejor rendimiento. El orador anima a la audiencia a hacer preguntas y brinda la oportunidad de recibir comentarios. La parte concluye mencionando la disposición del orador para ayudar con cualquier consulta o sugerencia.

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.

Watch more workshops on topic

DevOps.js Conf 2022DevOps.js Conf 2022
152 min
MERN Stack Application Deployment in Kubernetes
Workshop
Deploying and managing JavaScript applications in Kubernetes can get tricky. Especially when a database also has to be part of the deployment. MongoDB Atlas has made developers' lives much easier, however, how do you take a SaaS product and integrate it with your existing Kubernetes cluster? This is where the MongoDB Atlas Operator comes into play. In this workshop, the attendees will learn about how to create a MERN (MongoDB, Express, React, Node.js) application locally, and how to deploy everything into a Kubernetes cluster with the Atlas Operator.
React Summit 2023React Summit 2023
88 min
Deploying React Native Apps in the Cloud
WorkshopFree
Deploying React Native apps manually on a local machine can be complex. The differences between Android and iOS require developers to use specific tools and processes for each platform, including hardware requirements for iOS. Manual deployments also make it difficult to manage signing credentials, environment configurations, track releases, and to collaborate as a team.
Appflow is the cloud mobile DevOps platform built by Ionic. Using a service like Appflow to build React Native apps not only provides access to powerful computing resources, it can simplify the deployment process by providing a centralized environment for managing and distributing your app to multiple platforms. This can save time and resources, enable collaboration, as well as improve the overall reliability and scalability of an app.
In this workshop, you’ll deploy a React Native application for delivery to Android and iOS test devices using Appflow. You’ll also learn the steps for publishing to Google Play and Apple App Stores. No previous experience with deploying native applications is required, and you’ll come away with a deeper understanding of the mobile deployment process and best practices for how to use a cloud mobile DevOps platform to ship quickly at scale.
DevOps.js Conf 2022DevOps.js Conf 2022
13 min
Azure Static Web Apps (SWA) with Azure DevOps
WorkshopFree
Azure Static Web Apps were launched earlier in 2021, and out of the box, they could integrate your existing repository and deploy your Static Web App from Azure DevOps. This workshop demonstrates how to publish an Azure Static Web App with Azure DevOps.
DevOps.js Conf 2022DevOps.js Conf 2022
163 min
How to develop, build, and deploy Node.js microservices with Pulumi and Azure DevOps
Workshop
The workshop gives a practical perspective of key principles needed to develop, build, and maintain a set of microservices in the Node.js stack. It covers specifics of creating isolated TypeScript services using the monorepo approach with lerna and yarn workspaces. The workshop includes an overview and a live exercise to create cloud environment with Pulumi framework and Azure services. The sessions fits the best developers who want to learn and practice build and deploy techniques using Azure stack and Pulumi for Node.js.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2021React Advanced Conference 2021
19 min
Automating All the Code & Testing Things with GitHub Actions
Top Content
Code tasks like linting and testing are critical pieces of a developer’s workflow that help keep us sane like preventing syntax or style issues and hardening our core business logic. We’ll talk about how we can use GitHub Actions to automate these tasks and help keep our projects running smoothly.
DevOps.js Conf 2022DevOps.js Conf 2022
33 min
Fine-tuning DevOps for People over Perfection
Demand for DevOps has increased in recent years as more organizations adopt cloud native technologies. Complexity has also increased and a "zero to hero" mentality leaves many people chasing perfection and FOMO. This session focusses instead on why maybe we shouldn't adopt a technology practice and how sometimes teams can achieve the same results prioritizing people over ops automation & controls. Let's look at amounts of and fine-tuning everything as code, pull requests, DevSecOps, Monitoring and more to prioritize developer well-being over optimization perfection. It can be a valid decision to deploy less and sleep better. And finally we'll examine how manual practice and discipline can be the key to superb products and experiences.
DevOps.js Conf 2022DevOps.js Conf 2022
27 min
Why is CI so Damn Slow?
We've all asked ourselves this while waiting an eternity for our CI job to finish. Slow CI not only wrecks developer productivity breaking our focus, it costs money in cloud computing fees, and wastes enormous amounts of electricity. Let’s take a dive into why this is the case and how we can solve it with better, faster tools.
DevOps.js Conf 2022DevOps.js Conf 2022
31 min
The Zen of Yarn
In the past years Yarn took a spot as one of the most common tools used to develop JavaScript projects, in no small part thanks to an opinionated set of guiding principles. But what are they? How do they apply to Yarn in practice? And just as important: how do they benefit you and your projects?
In this talk we won't dive into benchmarks or feature sets: instead, you'll learn how we approach Yarn’s development, how we explore new paths, how we keep our codebase healthy, and generally why we think Yarn will remain firmly set in our ecosystem for the years to come.
DevOps.js Conf 2024DevOps.js Conf 2024
25 min
Atomic Deployment for JS Hipsters
Deploying an app is all but an easy process. You will encounter a lot of glitches and pain points to solve to have it working properly. The worst is: that now that you can deploy your app in production, how can't you also deploy all branches in the project to get access to live previews? And be able to do a fast-revert on-demand?Fortunately, the classic DevOps toolkit has all you need to achieve it without compromising your mental health. By expertly mixing Git, Unix tools, and API calls, and orchestrating all of them with JavaScript, you'll master the secret of safe atomic deployments.No more need to rely on commercial services: become the perfect tool master and netlifize your app right at home!