{"id":546,"date":"2026-09-06T01:10:49","date_gmt":"2026-09-06T04:10:49","guid":{"rendered":"https:\/\/www.linuxpro.com.br\/2026\/09\/a-historia-do-gitlab\/"},"modified":"2026-09-08T07:57:21","modified_gmt":"2026-09-08T10:57:21","slug":"a-historia-do-gitlab","status":"publish","type":"post","link":"https:\/\/www.linuxpro.com.br\/es\/2026\/09\/a-historia-do-gitlab\/","title":{"rendered":"La historia de GitLab: el tanuki que sali\u00f3 de Ucrania"},"content":{"rendered":"

\"Mascote<\/p>\n

El 8 de octubre de 2011 Dmitriy Zaporozhets hizo el primer commit de GitLab. La casa en Ucrania no ten\u00eda agua corriente; el pozo comunitario era el menor problema \u2014 faltaba una herramienta de Git que \u00e9l pudiera cambiar. Ruby on Rails, inspirado en GitWeb, hecho con Valeriy Sizov. Quince a\u00f1os despu\u00e9s GitLab 19.3.1 (26 de agosto de 2026) sigue saliendo al mismo ritmo: una versi\u00f3n por mes, 177 seguidas hasta junio de 2026. Del pozo a Nasdaq. El tanuki naranja en el medio.<\/p>\n

<\/p>\n

Ucrania, 2011: un Rails contra el GitHub cerrado<\/h2>\n

Dmitriy (Dmytro) Zaporozhets quer\u00eda colaborar con el equipo sin que GitHub fuera due\u00f1o del flujo. Self-hosted, c\u00f3digo abierto, instalaci\u00f3n que un humano aguanta. El nombre vino de GitWeb y de la familia \u201cgit algo\u201d. El commit inicial est\u00e1 en gitlab-foss<\/code>: 9ba12248, 8 de octubre de 2011. No era empresa. Era fin de semana y noche.<\/p>\n

O Git<\/a> ya estaba el disco. Faltaba la forge: issue, merge request, wiki, permiso, web. Gitorious exist\u00eda. GitHub ya era el social por defecto. GitLab naci\u00f3 del lado self-hosted \u2014 el servidor que la empresa instala y no manda el c\u00f3digo a California.<\/p>\n

2012: pancake, Hacker News y el CI<\/h2>\n

Sytse Sijbrandij \u2014 holand\u00e9s, despu\u00e9s Sid para el inversor estadounidense \u2014 vio el proyecto, ley\u00f3 el Rails y le gust\u00f3 la calidad tras trescientos commits. Public\u00f3 en Hacker News preguntando qui\u00e9n quer\u00eda un GitLab.com. El post no subi\u00f3. Se fue a hacer tortitas. El tel\u00e9fono se llen\u00f3. La mujer se qued\u00f3 con la sart\u00e9n; Sid pas\u00f3 el d\u00eda respondiendo. Cientos en la beta.<\/p>\n

En noviembre de 2012 Dmitriy hizo commit de la primera versi\u00f3n de GitLab CI. El resto de las forges trataba CI como plugin. GitLab lo trataba como el mismo producto. Esa decisi\u00f3n \u2014 una aplicaci\u00f3n, desde la issue hasta el deploy \u2014 es el \u201cmaster plan\u201d que solo recibir\u00eda nombre en 2016. Runner, .gitlab-ci.yml<\/code>, pipeline en el merge request: todo desciende de ah\u00ed.<\/p>\n

2013\u20132014: EE, empresa, d\u00eda 22<\/h2>\n

Una organizaci\u00f3n grande pidi\u00f3 una funcionalidad que la CE no ten\u00eda. Dmitriy tuite\u00f3 que quer\u00eda vivir de GitLab. Sid y \u00e9l cerraron GitLab Enterprise Edition el 22 de julio de 2013 \u2014 open core: CE MIT, EE con lo que pagan telecos y bancos. Sid hizo el commit inicial del sitio. GitLab B.V. en Utrecht; despu\u00e9s GitLab Inc. en EE. UU., sin oficina. El primer empleado era de Serbia. Dmitriy, Ucrania. Los holandeses que Sid contrat\u00f3 dejaron de ir a la mesa extra de su casa al tercer d\u00eda. El remote no fue ideolog\u00eda. Fue lo que qued\u00f3 cuando nadie aparec\u00eda y Slack ya lo resolv\u00eda.<\/p>\n

En 2014 la empresa se convirti\u00f3 en LLC. GitLab Cloud pas\u00f3 a llamarse GitLab.com. Release el d\u00eda 22 de cada mes \u2014 6.5 en enero, 7.6 en diciembre \u2014 y el calendario no se ha roto desde entonces. A final de a\u00f1o mandaron la aplicaci\u00f3n a Y Combinator.<\/p>\n

2015\u20132016: YC, handbook, master plan<\/h2>\n

El winter batch de 2015 llev\u00f3 a casi todo el equipo al Valle. Nueve personas en la graduaci\u00f3n, en marzo. El GitLab Handbook entr\u00f3 en el repositorio del sitio: valores, hiring, onboarding, salario, todo por defecto p\u00fablico. CREDIT: Collaboration, Results, Efficiency, Diversity, Iteration, Transparency. La transparencia era tambi\u00e9n defensa: comercializar open source suele matar a la comunidad; el handbook era el ant\u00eddoto que Sid describi\u00f3.<\/p>\n

Compraron Gitorious (2015) y migraron a los usuarios. Khosla, seed. En 2016 el master plan: no ser \u201cotro GitHub m\u00e1s\u201d, ser la plataforma DevOps entera. Serie B de $ 20 millones de d\u00f3lares. M\u00e1s de mil contribuyentes, cien mil organizaciones. El equipo pas\u00f3 de 140.<\/p>\n

31 de enero de 2017: rm en la base de datos equivocada<\/h2>\n

Spam de snippets tumb\u00f3 el PostgreSQL de GitLab.com. En mitad de la recuperaci\u00f3n de la replicaci\u00f3n, un sysadmin ejecut\u00f3 rm -rf<\/code> en el directorio de datos pensando que estaba en el secundario. Estaba en el primario. 300 GB se convirtieron en 4,5 GB. El backup a S3 estaba vac\u00edo: pg_dump<\/code> 9.2 contra Postgres 9.6, el job fallaba en silencio. Snapshot de disco de la base de datos no exist\u00eda. Restauraci\u00f3n de un staging de seis horas. Issues, MR y usuarios de la ventana 17:20\u201300:00 UTC se perdieron; repositorio Git y wiki, no \u2014 viven en otro disco. A los self-hosted nadie les toc\u00f3.<\/p>\n

El postmortem sali\u00f3 p\u00fablico, con un Google Doc en vivo. La lecci\u00f3n qued\u00f3 en la cultura: un backup que no restaura no es backup; la consola de producci\u00f3n necesita guardrail; la transparencia del handbook tambi\u00e9n vale cuando el tanuki se lleva el golpe. Ese mismo a\u00f1o compraron Gitter.<\/p>\n

Qu\u00e9 es el tanuki, por dentro<\/h2>\n

No es un Git daemon con piel. Es un stack:<\/p>\n