Deployment Continuo

Paul Biggar, co-fundador de CircleCI presentó “Las diversas formas de deployar de manera continua” en la RubyConf 2013 en abril de este año. La frecuencia con la que ocurren los deployments, califica el término “continuo” e influye directamente en el espacio de problemas del deployment. La presentación engloba información de

Recent Posts

Paul Biggar, co-fundador de CircleCI presentó “Las diversas formas de deployar de manera continua” en la RubyConf 2013 en abril de este año. La frecuencia con la que ocurren los deployments, califica el término “continuo” e influye directamente en el espacio de problemas del deployment. La presentación engloba información de soluciones recolectadas de la propia base de clientes de CircleCI, Facebook, IMVU, Etsy, Heroku y Google. Con esto, se descubrió que cada compañía deploya de forma ligeramente diferente y que no hay una sola solución para el deployment continuo.

Paul compartió detalles sobre cómo las soluciones de deployment van a tener procesos que involucran código, cambios de bases de datos, unidades de deployment, velocidad de implementación, pruebas y monitoreo. Dijo que las variables que afectan el desarrollo de estas soluciones de deployments, incluyen la velocidad de características nuevas, complejidad de código, arquitectura de software, diseño de software, número de ingenieros y el estado de monitoreo.

Paul explicó que la solución más común para manejar la transición del deployment a la producción, la “carrera”, era deployar código que soporte funcionalidad vieja y nueva. Esto necesita ingenieros que programen funcionalidad para que el código nuevo pueda ejecutarse de manera segura junto con el código viejo. Las bases de datos presentan un desafío adicional de estado almacenado. Al principio parece que actualizar todo lo demás en la aplicación primero y permitir que la aplicación maneje ambas versiones de una base de datos sería suficiente antes de, finalmente, cambiar la versión. Sin embargo, en algunos casos cambiar las bases de datos SQL causa tanto bloqueo que la única opción razonable es crear una nueva tabla de base de datos para cada versión y migrar los datos fuera de banda.
La aplicación estaría codificada para chequear la nueva tabla y recurrir a la vieja si no hubiera información en ella. NoSQL se ha hecho popular en parte porque puede evitar el escenario de bloqueo.

La presentación cubre aspectos adicionales de deployment, incluyendo unidad de deployment, velocidad, validación por pruebas, y verificación por monitoreo. Si bien estos son requisitos no funcionales de deployment, el nivel de estas capacidades hasta qué grado de deployment es continuo.

Créditos: