Continuous Integration en laburo Devops (un ejemplo)

Hablo desde la simple lectura informativa en lo relativo a desarrollo y con cierta experiencia en lo de infraestructura, CI involucra ambas áreas, desarrollo e infraestructura, los encargados de concretar mucho del trabajo de CI son llamados - hoy - devops.

http://en.wikipedia.org/wiki/DevOps

Implementar CI no es puramente una práctica de desarrollo, no puede serlo, y muchos "shops" no se embarcan en implementaciones continuas, en releases a producción frecuentes, porque no disponen de suficiente personal de infraestructura (los mismos que codean, arman los servers, depuran los deployments, suben el código, etc.), obviamente esa "parada" en el desarrollo no es algo que la mayoría de los "shops" puedan permitirse desde lo económico.

En este artículo:
Exclusive: a behind-the-scenes look at Facebook release engineering
http://arstechnica.com/business/news/2012/04/exclusive-a-behind-the-scenes-look-at-facebook-release-engineering.ars

Se puede leer como lo hace Facebook, como podrán leer, la metodología de desarrollo está íntimamente ligada a facilitar y viabilizar lo más posible un deployment automatizado, evitando como la peste cualquier tunning manual/artesanal.

Ese trabajo de integración, - metodológico (en el artículo, por ejemplo: cada developer es 100% responsable del código que sube,  incluyendo un sistema de karma, para diferenciar entre buenos y malos coders), - práctico (en el artículo, es indispensable contactar a los developers antes de subir el código, vía, irc, sms, email, llamado, etc. como sea, alguien tiene que dar la cara antes de subir nada a producción), - y tecnologico (por ejemplo usar bittorrent para distribuir los binarios ultraoptimizados de php que usa Fbk), les permite tener una CI casi "pura" (o lo más parecido posible de lo que tenga noticia)

No es fácil en absoluto, pero parece resultarles muy rentable. CI pide recursos, y en muchos casos puede no ser rentable, pero seguramente se puede llegar a compromisos e implementar CI parcialmente, para llegar a "concretar" en metodologías ágiles (que involucran desarrollo/infraestructura): lo de tener código en producción al final de cada sprint (en scrum), de desarrollo y "verlo" / "sentirlo" correr en su entorno (vs. tenerlo "declarado" como en-producción, pero sin verlo en acción).