¿Por qué Nexus? (Para alguien que no programa)
Por: Tim OBrien
Ha habido varios no-programadores que preguntan ¿Qué es Nexus? ¿Qué hace? El verdadero desafío acerca de este tema es cómo transmitir lo que es Nexus a alguien que no tiene experiencia en programación directa. Es fácil para un desarrollador hablar con otro desarrollador, ya que se comparte el mismo conjunto de experiencias. Se puede hablar de un “compilador” y se puede asegurar que además de saber lo que es, lo utiliza todos los días.
¿Qué es Nexus?
Nexus es un administrador de repositorios, almacena “artefactos”, pero antes de pasar a la conceptualización, hay que comenzar con una descripción del desarrollo de software. Es necesario comenzar con una descripción simple de lo que implica el desarrollo de software y también analizar el desarrollo de Java Enterprise. Antes de continuar con la explicación de lo que hace Nexus, hay que responder la siguiente pregunta…
¿Cómo se desarrolla el software?
Use un sitio web como el New York Times o incluso algo tan simple como Google, podría ser fácil pensar que el esfuerzo requiere pocos desarrolladores, algunos diseñadores gráficos y algunas semanas de esfuerzo. Piense otra vez. Para cualquier sistema, generalmente estamos hablando de decenas a cientos de desarrolladores (a veces miles de desarrolladores) divididos en diferentes grupos, cada uno con un enfoque distinto. Por ejemplo, piense en un gran banco internacional. Tal organización probablemente empleará a miles de desarrolladores en todo el mundo. Puede haber cientos de desarrolladores en San Francisco enfocados en el desarrollo web, con decenas de desarrolladores en Nueva York enfocados en la información de mercado y la integración de datos. Tal vez hay un grupo que se centra en las operaciones de back office en Toronto y un grupo dedicado a clientes internacionales en Dubai, y otro grupo de desarrollo en Bangalore.
El punto aquí es que el desarrollo de software moderno se distribuye frecuentemente y los sistemas más grandes involucran a cientos de desarrolladores que intentan colaborar en un solo sistema empresarial. El «gran software» puede involucrar a miles de desarrolladores y los CTO y CIO, que hoy se dan cuenta de que la forma de mantenerse ágil y de innovar, es adoptando las mejores prácticas de la comunidad de código abierto. Los proyectos de código abierto como el Kernel de Linux o las comunidades de código abierto como Apache Software Foundation son la prueba de que miles de desarrolladores pueden colaborar en sistemas complejos si se les proporciona una infraestructura eficiente y un conjunto compartido de suposiciones sobre cómo se desarrolla el software. Si bien a menudo es difícil importar la cultura de código abierto en una corporación, es bastante fácil estandarizar en las mismas herramientas la misma estructura «eficiente» que permite a un gran grupo ad hoc de desarrolladores colaborar.
Infraestructura de desarrollo eficiente
Sistemas de control de código fuente, rastreadores de problemas, listas de correo, servidores de integración continua, wikis, entorno de desarrollo integrado y gestores de repositorios; cuando se comienza un nuevo proyecto de código abierto, una de las primeras cosas que se decide es qué se va a utilizar para cada uno de estos componentes. Por lo cual hay que revisar los componentes y analizar las diversas opciones que están disponibles:
- Sistema de control de código de fuente: Este es el servicio que va a rastrear el código, el cual se transforma finalmente en un sistema operativo. Por lo tanto, si está desarrollando sitios web, es probable que el código sea un artefacto primario justo al lado del contenido y el diseño. Los sistemas de control de código fuente son una pieza establecida de infraestructura y los programadores los han estado utilizando durante décadas.
- Listas de correo: Esto puede parecer muy simple para ser considerado como parte de la infraestructura de desarrollo, pero muchas veces es la pieza más esencial y básica de la infraestructura. Los equipos de desarrollo eficientes tienden a compartir casi todo lo técnico en una lista de correo compartida. Cada equipo de desarrollo enfocado tiene una lista de correo y las discusiones se archivan para futuras referencias. A medida que la composición del equipo evoluciona con el tiempo, esta conversación compartida puede ser un registro importante para la corrección de errores y el conocimiento institucional sobre una aplicación. Las listas de correo, como el control de código fuente, han existido durante décadas.
- Rastreadores de problemas: Su equipo necesitará un lugar para almacenar tareas e informes de errores, y también deberá tener una forma de planificar lo que sucederá en la próxima versión del software. Un buen rastreador de problemas proporciona al programador una forma de personalizar y filtrar la lista de problemas por proyecto o por persona. También puede ser tanto una herramienta de colaboración como un simple panel de control de productividad para los programadores. Los proyectos de código abierto han utilizado los rastreadores de problemas durante más de una década, pero los rastreadores de problemas modernos (como JIRA) aún están desarrollando características que redefinen la categoría.
- Servidores de integración continua: Piense en un “robot” automatizado, sentado en una sala al lado de los desarrolladores que esperan constantemente el cambio de código. Cuando el código cambia, este «robot» automatizado trae esos cambios a su sistema y realiza una compilación de software. Si la compilación falla o si las pruebas fallan, todos los desarrolladores reciben una notificación inmediata de la falla, y ellos eliminan todo para asegurarse de que los problemas se solucionen rápidamente. El principio detrás de la integración continua es que cuanto antes se encuentre un error, más fácil será solucionarlo. Si su empresa comprueba algún código erróneo, hay menos posibilidades de que pase desapercibida si hay un sistema que se ejecute constantemente y pruebe el código a medida que cambia. Antes de la era de los servidores de integración continua, Los programadores y desarrolladores solo pueden realizar compilaciones e integraciones completas del sistema una vez cada pocas semanas o meses durante una versión de software. Si bien esto puede parecer una parte obvia del desarrollo de software, los servidores de integración continua solo se han vuelto estándar en los últimos cinco años.
- Wikis: Si ha usado Wikipedia, sabrá qué es una Wiki. Es un sitio web compartido que es fácil de editar y está abierto a cualquier participante. La mayoría de los equipos de desarrollo interno tienen un Wiki para la colaboración que no tiene sentido llevar a cabo en una lista de correo. El efecto neto de tener un Wiki para un equipo de desarrollo es que el equipo tiende a enviar menos archivos adjuntos de Word o Excel a la lista de correo. Si hay que desarrollar una especificación, es normal que la gente lo haga en un Wiki. Apache Software Foundation solo comenzó a permitir un Wiki abierta hace seis años, y recientemente se ha convertido en algo estándar en la mayoría de los entornos de desarrollo interno.
- Entornos de desarrollo integrados/Integrated Development Environments: Esta es la herramienta principal que los desarrolladores utilizan todos los días. Si ve una «codificación» de programador, es muy probable que esté mirando una herramienta GUI, como Eclipse o IntelliJ, que contiene herramientas que facilitan mucho la escritura de código.
Gestores de repositorios
Esto nos lleva al componente final de la infraestructura de desarrollo eficiente: los administradores de repositorios.
Administradores de repositorios: Se puede pensar en un repositorio como si fuera una biblioteca. Es un servidor que almacena y recupera archivos, a los que nos referimos como artefactos. Cuando escribe una pieza de software, a menudo depende de bibliotecas externas. Si está desarrollando un sistema para enviar un cohete al espacio, puede depender de una biblioteca que proporcione funciones para calcular los efectos de la gravedad. Si está creando un sitio web, es probable que use un framework diseñado para servir a los sitios web.
En Java, estas bibliotecas se almacenan en archivos binarios denominados JAR, y si está trabajando en un sistema complejo, es posible que necesite cientos de bibliotecas externas en una aplicación. El uso principal de un administrador de repositorios es hacer proxy y almacenar en caché los artefactos de los repositorios «externos». Su organización utiliza bibliotecas de código abierto, y cuando su compilación las necesite, consultará automáticamente a un administrador de repositorio local. Si ese administrador de repositorio local no tiene ese artefacto en particular, lo recuperará de un servidor de repositorio externo y lo almacenará en caché para su uso posterior.
«Central» se refiere al «Repositorio Central de Maven», puede pensar en «central» como el administrador de repositorio global que almacena todos los componentes de código abierto. «Central» tiene millones de usuarios en todo el mundo y miles de usuarios lo utilizan para proyectos de código abierto. Es la moderna «Biblioteca de Alejandría» para componentes de código abierto, y reduce en gran medida el trabajo requerido para distribuir software a millones de desarrolladores. Si tiene algo que compartir con el mundo, póngalo en «central», distribuya las coordenadas y, en minutos, todos deberían tener una copia.
Antes de la llegada de «central», los usuarios tendrían que actualizar manualmente las dependencias, y los proyectos de código abierto tendrían que tratar de hacer correr la voz para que la gente supiera sobre una versión de software. En 2010, el lanzamiento de un nuevo componente de código abierto al repositorio de Central Maven no es un evento. Todo lo que un desarrollador debe hacer es publicar en «central»; el resto es automático. Si un desarrollador está utilizando un administrador de repositorio, incluso puede configurar la herramienta para notificarles todos los nuevos lanzamientos. El administrador «central» del repositorio de Maven es el tejido central de la colaboración, y en los últimos ocho años, ha cambiado la forma en que se distribuye y desarrolla el software.
Mientras que «central» brinda eficiencia a todo un mundo de desarrolladores de software, ejecutar un administrador de repositorio interno brinda una colaboración eficiente entre sus desarrolladores y sus equipos. Si un equipo desarrolla una biblioteca utilizada por otro equipo, puede usar un administrador de repositorio interno para distribuir las versiones de software internamente. Si sus equipos de desarrollo están entregando aplicaciones a un grupo de operaciones para su implementación, pueden usar un administrador de repositorio como una forma de compartir productos finales.
Si bien el mundo de código abierto se ha estandarizado en los administradores de repositorios en los últimos tres años, la mayoría de las organizaciones aún se encuentran al comienzo de la curva de adopción. Las organizaciones que han adoptado un administrador de repositorio comprenden los beneficios y entienden que el desarrollo sin uno sería un proceso cargado de ineficiencia. Se puede predecir que para dentro de tres años, la mayoría de las organizaciones ejecutarán un administrador de repositorio local llamado Nexus. Es una tecnología tan esencial como el control de código de fuente.
¿Qué es Nexus? (Para alguien que no programe)
Entonces, ¿Qué es Nexus? Si todavía no tiene ningún sentido después de leer esta publicación, considérelo como una biblioteca. Puede solicitar «artefactos», los almacenará, los recuperará y asignará un sistema de coordenadas estándar a los artefactos que almacena. Si está desarrollando software, al tener esta instalación disponible le permite catalogar y almacenar sus propios artefactos utilizando el mismo sistema de «numeración» que utiliza la biblioteca. Cuando un grupo desarrolla un nuevo sistema o una biblioteca, lo envía al administrador del repositorio. Otros grupos tienen una forma estándar de acceder a estas bibliotecas. Este estándar para catalogar y direccionar archivos trae eficiencia.
Piense en lo difícil que sería si los libros no tuvieran números ISBN, o si las bibliotecas no tuvieran un sistema de archivo como el sistema decimal Dewey. No podría buscar libros, no podría encontrar rápidamente un libro en Amazon. El administrador del repositorio es esa «biblioteca».
Blog Sonatype. (Abril 12). «Why Nexus?». https://blog.sonatype.com/