Cadena de suministro de Software

Lo primero decir que me encanta la imagen destacada de esta entrada. Primero porque representa una cadena y segundo porque me parece muy bonita estéticamente hablando.

El concepto de cadena de suministro de Software no es muy usado, está mas de moda el de devops. Pero a mi la verdad es que el de devops no me gusta tanto, porque hace referencia a desarrolladores y operadores y prefiero utilizar el de cadena de suministro de software, como hacen referencia en Nexus de Sonatype.

Me gusta mas porque desde que nuestro cliente tiene una necesidad, hasta que esa necesidad se pone en producción en forma de un programa, hay que pasar por una serie de fases o una cadena para suministrar ese Software.

Por eso me gusta mas, porque creo que representa mejor lo que pasa, pero claro devops es un nombre mas cortito.

Os dejo bastantes reflexiones mas sobre este concepto en el vídeo

GitLab #7: Gestión de tareas

Esta es otra de las funcionalidades de Git que no suelo usar, porque normalmente suelo decantarme por gestores de tareas mas completos.

Pero está en el producto así que os la enseño. Quizá la gente que no quiera meterse en muchos productos en su infraestructura de desarrollo puede serle útil.

GitLab #6: Wiki

Esta es una funcionalidad del producto, que para mi no es muy importante, porque siempre he preferido Wikis mas completas.

Pero existe en el producto y en determinadas situaciones puede ser útil a alguien, así que os lo enseño.

GitLab #5: Importar desde GitHub

Quinta entrega sobre GitLab, en esa ocasión vemos como importar un repositorio desde GitHub.

Una de las ventajas de Git es que tiene un ecosistema de servidores que son compatibles entre si, de tal forma que si un servidor no te gusta puedes cambiar a otro.

Os dejo el vídeo en el que enseño como se realiza esta importación.

GitLab #2: Configurar usuario

Segunda entrega sobre los videotutoriales de gitlab, en esta ocasión lo que os traigo es como crear un usuario en gitlab. Puede parecer sencillo, pero tal y como funciona git con las claves ssh tiene una cierta miga, sobre todo para los que no estén acostumbrados a manejarse con autenticación transparente mediante ssh.

Nueva serie sobre GitLab

Primer video de una serie sobre el gitlab. Como sabemos git es un control de versiones, pero es una utilidad de línea de comandos, con lo que ha surgido una serie de herramientas complementarias para añadirle funcionalidad.

Una de estas herramientas es gitlab, muy conocido dentro de los que quieren tener un git en sus instalaciones y un producto de código abierto y gratuito.

 

Definitivamente: Git edulcorado

Escribía en una entrada previa sobre si usar git a palo seco o edulcorado. He tenido algunas experiencias ya, aparte de con el git que instalé en mi RaspBerry (a palo seco), con GitHub, GitLab y BitBucket (git edulcorados).

Definitivamente me quedo con el git edulcorado. Estos tres productos son un Git, pero con el añadido de que unas serie de funcionalidades que me parecen bastante interesante.

– Disponen de una interface Web que simplifica enormemente el uso y la administración.
– Disponen de una pequeña Wiki, también soportada sobre Git, lo que permite tener publicada cierta documentación sin tener que andar instalando y administrando otro servicio.
– Disponen de una pequeña gestión de tickets, que al igual que en el caso de la Wiki, dispone de una funcionalidad básica, pero suficiente para proyectos pequeños.

Me parece especialmente interesante la funcionalidad de pull request o merge request, que permite a un desarrollador pedir a su responsable que le haga el merge de su branch de trabajo en el branch común.
Además hay variedad de implementaciones ( GitHub, GitLab, BitBucket,…) con lo que es relativamente fácil encontrar una que se ajuste a las necesidades.

En tu repositorio o en el mio

Esta no es una entrada de la línea de que le pido a un repositorio de código, porque no siempre es un requisito el disponer de un repositorio de código distribuido.

Pero si que es cierto que alguna vez he estado en discusiones con los clientes en las que ha salido el tema de que repositorio utilizar, si el del cliente o el del proveedor. Es una decisión un poco estéril ya que el cliente puede imponerte entregar el producto que ha comprado en su repositorio, y tampoco tiene normalmente potestad para prohibirte el utilizar tu propio repositorio.

El problema suele venir por el hecho de que muchas veces la conexión con tu cliente se hace por medios no transparentes, es decir mediante VPN o similares, que hacen que el trabajar contra la infraestructura del cliente sea algo engorroso.

Aparte hay que tener en cuenta que aunque la propiedad intelectual del producto construido sea del cliente normalmente las empresas suelen querer tener una copia del trabajo realizado, simplemente para en caso de reclamación poder demostrar si ha habido o no modificaciones ajenas al desarrollo realizado.

En estos casos el utilizar un repositorio distribuido como es el caso del Git aporta bastantes ventajas, ya que permite diluir esa discusión de si utilizar el repositorio del cliente o el del proveedor. Puedes utilizar el de tu empresa y luego empujar los cambios al del cliente.