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.
Un viaje de los mil binarios
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.
1. Introducción a las Dependencias
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
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.
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
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.
4. Seguridad y Problemas de Confianza con las Dependencias
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.
5. Seguridad y Gestión de Dependencias
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.
6. Configuración de Repositorio y Creación de Usuario
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.
7. Repositorios de Artifactory y Configuración de npm
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.
8. Resolviendo Dependencias y Publicación
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.
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
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...
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
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.
11. Configuración de Repositorios y Autenticación
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.
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
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
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
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.
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
Comments