Existen dos patrones principales para que los equipos de desarrollo colaboren mediante el control de versiones. Uno consiste en usar ramas de características (feature branches), donde un desarrollador o un grupo de desarrolladores crea una rama, generalmente desde el trunk (también conocido como main o mainline), y luego trabaja de forma aislada en ella hasta que la funcionalidad que están desarrollando esté completa. Cuando el equipo considera que la funcionalidad está lista, la fusiona de nuevo con el trunk.

He oído hablar de problemas con varios proyectos últimamente. Funciona así:

• Quieren utilizar un proceso ágil y eligen Scrum
• Adoptan las prácticas de Scrum, y tal vez incluso los principios
• Después de un tiempo, el progreso es lento porque la base de código es un desastre.

Lo que sucedio es que no han prestado suficiente atención a la calidad interna de su software. Si cometes ese error, pronto verás cómo tu productividad se reduce porque añadir nuevas funciones es mucho más difícil de lo que te gustaría. Has asumido una deuda técnica abrumadora y tu scrum se ha debilitado. (Y si has estado en un Scrum de verdad, sabrás que eso es malo).

Nota: Este post es una traduccion de What is Continuous Delivery? bajo la licencia: CC BY-SA 3.0 US.

La entrega continua es la capacidad de tener cambios de todo tipo (incluidas nuevas funcionalidades, cambios de configuración, correcciones de errores y experimentos) en producción o en manos de los usuarios, de forma segura, rápida y sostenible.

Nuestro objetivo es hacer que los despliegues (ya sea de un sistema distribuido a gran escala, un entorno de producción complejo, un sistema integrado o una aplicación) sean asuntos rutinarios y predecibles que se puedan realizar a pedido.