Llevo ya bastantes años trabajando con una combinación de SVN + Trac para manejar el control de versiones y la gestión de los proyectos que desarrollo, y la verdad es que estoy muy contento. Pero en los últimos años la tendencia parece que va cambiando desde los sistemas centralizados hacia los sistemas distribuidos como es Git. Aún hay quien se resiste y dice que Git es tan solo una moda y quien dice que Git es prácticamente el «santo grial» de los controles de versiones. Sin lugar a dudas hay que decir que los que apoyan Git tienen un argumento a su favor que es indiscutible, con Git podrías hacer lo mismo que haces con subversion y mucho más, pero todo esto sería entrar en otro debate que no es el que nos ocupa en este post.
Si bien es cierto que existen multitud de servicios, algunos muy destacados, como Bitbucket o GitHub que nos permiten hospedar nuestros repositorios e integran diversas herramientas para la gestión de los proyectos, en sus versiones gratuitas (como es natural) imponen algunas condiciones con las que en muchos casos no podríamos comulgar, como por ejemplo que los proyectos sean open source y estén públicos para todo el mundo.
Por supuesto todos ellos nos ofrecen planes de pago que suprimen estas limitaciones y añaden características de valor añadido, de hecho GitLab también sigue este mismo modelo de negocio, pero a diferencia de los anteriores en GitLab también tenemos la opción de descargar y desplegar su plataforma en nuestros propios servidores. De nuevo aquí existen dos versiones, una gratuita y open source mantenida por la comunidad y otra enterprise con varios planes y precios que añaden más funcionalidades y soporte profesional.
Pero GitLab no solo ofrece la gestión de repositorios, también integra/permite integrar toda una gama de herramientas típicas en la gestión de proyectos y coordinación de grupos de trabajo, como wikis de proyecto, herramientas para la integración continua, bug tracking, ganchos, etc. Además de una gran facilidad para administrar los permisos de los distintos repositorios permitiendo asignar permisos mediante grupos y/o usuarios. Esto junto a la facilidad de instalación fue lo que me empujo a decidirme por el uso de GitLab en lugar de lanzarme a desplegar una estructura de Git + Trac. Podemos ver las diferencias entre la versión CE y la Enterprise en el siguiente enlace: https://about.gitlab.com/features/#compare.
Aunque acabo de decir que la instalación de GitLab es muy sencilla, todo depende, ya que GitLab nos ofrece una amplia modalidad de opciones para su despliegue. Por suerte en la misma web del proyecto existe una estupenda documentación, y si no queremos complicarnos y seguimos el método de instalación mediante paquete Omnibus la instalación no podría ser más sencilla (para los que desconozcan que es esto, Omnibus es un sistema de auto instalación para aplicaciones desarrolladas en Ruby On Rails, como es el caso de GitLab), tan solo deberemos seleccionar nuestro operativo y nos mostraran los pasos a seguir para tener nuestro entorno instalado en cuestión de minutos.
En mi caso voy a desplegar GitLab sobre un Ubuntu Server 14.04: https://about.gitlab.com/downloads/#ubuntu1404.
Tal como se indica en las instrucciones tenemos varias opciones para manejar los mails que nos envíe GitLab. Por defecto si esta instalado, GitLab empleará Postfix (durante la instalación del mismo seleccionar «Sitio de Internet» cuando nos pregunte), pero si no queremos instalar el MTA Postfix, podremos utilizar otros MTA como Sendmail o Exim o inclusive emplear un servidor SMTP externo, como por ejemplo el de Gmail, aunque esto conllevara algo más de trabajo de configuración posterior a la instalación de GitLab (https://gitlab.com/gitlab-org/omnibus-gitlab/blob/master/doc/settings/smtp.md).
Como hemos comentado tan solo debemos seguir las instrucciones indicadas para nuestra distribución en la web oficial. Comenzamos instalando las dependencias necesarias:
apt-get install curl ca-certificates postfix
Añadimos el repositorio de GitLab. Como podemos observar lo hacemos directamente pasándole al shell bash un script que descargamos mediante curl:
curl -sS https://packages.gitlab.com/install/repositories/gitlab/gitlab-ce/script.deb.sh | bash
Este script añade el fichero gitlab_gitlab-ce.list a /etc/apt/sources.list.d/ con los repositorios oficiales de GitLab:
cat /etc/apt/sources.list.d/gitlab_gitlab-ce.list
# this file was generated by packages.gitlab.com for # the repository at https://packages.gitlab.com/gitlab/gitlab-ce deb https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ trusty main deb-src https://packages.gitlab.com/gitlab/gitlab-ce/ubuntu/ trusty main
Ya podemos instalar GitLab CE como hacemos con cualquier otro paquete:
apt-get install gitlab-ce
Tras esto dispondremos de un entorno GitLab que implementara los servicios que necesita, como por ejemplo nginx y PostgreSQL, de forma embebida.
Tal como se nos indica, nada más instalar debemos lanzar el comando de reconfiguración del entorno GitLab, que lee los parámetros de configuración establecidos en el fichero /etc/gitlab/gitlab.rb y que en esta primera ejecución provocara que se establezcan algunas de las configuraciones iniciales necesarias, como establecer los permisos adecuados para los ficheros, crear el usuario global de administración, etc. Iniciando finalmente el servicio.
gitlab-ctl reconfigure
Ahora que ya tenemos GitLab preparado, nuestro primer paso debería ser loguearnos desde el navegador con las credenciales por defecto que GitLab asigna al usuario global: user: root y password: 5iveL!fe, tras lo cual se nos indica que cambiemos la contraseña por defecto por una más segura que tan solo nosotros conozcamos.
Tras cambiar la contraseña, volveremos a tener que loguearnos y ya podríamos comenzar a administrar nuestro servidor GitLab modificando configuraciones por defecto, creando usuarios, grupos, proyectos, etc.
