Co­n­ti­nuous In­te­gra­tion vs. Co­n­ti­nuous Delivery vs. Co­n­ti­nuous De­plo­y­me­nt – visión general de los modelos de de­sa­rro­llo de software

No cabe duda de que los procesos de de­sa­rro­llo de software son caros. Es­pe­cia­l­me­n­te cuando el código elaborado no puede in­te­grar­se en el software existente, los costes de de­sa­rro­llo pueden di­s­pa­rar­se. Siendo esta la situación, los enfoques modernos Co­n­ti­nuous In­te­gra­tion, Co­n­ti­nuous Delivery y Co­n­ti­nuous De­plo­y­me­nt ofrecen una solución basada en la va­li­da­ción múltiple del código durante su de­sa­rro­llo. Además, también permiten entregar al cliente pro­to­ti­pos del producto deseado, ya que divide el trabajo en diversas fases de de­sa­rro­llo más pequeñas. De esta manera, puedes ajustar los re­qui­si­tos ne­ce­sa­rios a lo largo del proceso de de­sa­rro­llo y comprobar si el software adopta la forma deseada.

Los modelos modernos de de­sa­rro­llo de software tienen su origen en el concepto de de­sa­rro­llo ágil de software. Con este enfoque no solo acelera el proceso de de­sa­rro­llo, sino también facilita su co­m­pre­n­si­bi­li­dad. El objetivo detrás del de­sa­rro­llo ágil es crear el software que el cliente realmente necesita. Cada fase de de­sa­rro­llo pro­po­r­cio­na un prototipo y, a través de este, el cliente puede comprobar las funciones del software, al igual que su co­m­pa­ti­bi­li­dad con el software existente. Además, se pueden tener en cuenta los deseos que el cliente va fo­r­mu­la­n­do durante el proceso de de­sa­rro­llo.

Las empresas continúan im­ple­me­n­ta­n­do el de­sa­rro­llo ágil. De hecho, hay varios enfoques que se utilizan para acelerar los procesos de de­sa­rro­llo internos como, por ejemplo, DevOps, nombre que resulta de la co­m­bi­na­ción de las palabras “De­ve­lo­p­me­nt” (de­sa­rro­llo) y “Ope­ra­tio­ns” (ope­ra­cio­nes). El objetivo de este tipo de cultura co­r­po­ra­ti­va es unir durante toda la fase de de­sa­rro­llo del software a los equipos de de­sa­rro­llo pro­pia­me­n­te dichos con los equipos or­ga­ni­za­ti­vos. De esta manera, se evitan los problemas de in­te­gra­ción del software desde el principio. Además, se facilita el ma­n­te­ni­mie­n­to y la di­s­po­si­ción de los programas. Los re­pre­se­n­ta­n­tes de DevOps no solo utilizan el de­sa­rro­llo continuo, sino que también confían en Co­n­ti­nuous In­te­gra­tion y Co­n­ti­nuous De­plo­y­me­nt

El objetivo detrás del concepto Co­n­ti­nuous In­te­gra­tion es im­ple­me­n­tar lo más rápido posible todos los cambios ne­ce­sa­rios de un proyecto de software a todo el software y, por esta razón, los pro­gra­ma­do­res ac­tua­li­zan el código cada día. Para ello, además de he­rra­mie­n­tas de in­te­gra­ción continua, utilizan sistemas de control de versiones como, por ejemplo, GitHub, que permiten guardar copias locales de todo el proyecto en el propio ordenador. Los pro­gra­ma­do­res pueden realizar cambios en el código y subir estos al sistema de control de versiones. Después, se pueden hacer di­fe­re­n­tes pruebas a todo el sistema y, de este modo, se evitan los problemas de in­te­gra­ción.

El concepto de entrega continua va más allá de la in­te­gra­ción continua: además de ac­tua­li­zar el código a diario e integrar cada cambio rá­pi­da­me­n­te, el cliente dispone de un prototipo que recibe lo antes posible. La co­m­pa­ra­ción entre Co­n­ti­nuous In­te­gra­tion vs. Co­n­ti­nuous Delivery muestra que la entrega continua se centra, pri­n­ci­pa­l­me­n­te, en el feedback del cliente. Además, la entrega temprana del código parcial permite probar el software en un entorno real y, de esta manera, cada crítica del cliente puede adaptarse en el proceso de de­sa­rro­llo posterior. Si el cliente está de acuerdo con el código parcial, se le entrega po­s­te­rio­r­me­n­te de forma manual.

El enfoque del de­s­plie­gue continuo es semejante al anterior, pero aún más amplio. Su pro­ce­di­mie­n­to se basa en pruebas au­to­ma­ti­za­das que se utilizan di­re­c­ta­me­n­te en el proceso de de­sa­rro­llo. Si comparas los enfoques de Co­n­ti­nuous Delivery y Co­n­ti­nuous De­plo­y­me­nt, puedes darte de que con el Co­n­ti­nuous De­plo­y­me­nt no hay retraso entre la prueba y el momento de li­be­ra­ción del código. Además, debido a los amplios marcos de prueba, los pro­gra­ma­do­res no tienen que esperar a las críticas de los clientes. De hecho, los de­sa­rro­lla­do­res pueden pro­po­r­cio­nar el código parcial in­me­dia­ta­me­n­te después de su de­sa­rro­llo de forma au­to­ma­ti­za­da.

Si quieres saber qué modelo de de­sa­rro­llo es el más adecuado, debes analizar los re­que­ri­mie­n­tos es­pe­cí­fi­cos del proyecto, ya que la respuesta depende de estos. Sin embargo, los tres modelos tienen sus ventajas, aunque solo si el cliente y los pro­gra­ma­do­res trabajan juntos.

Los costes asociados al de­s­plie­gue continuo son elevados debido a los pro­ce­di­mie­n­tos de prueba. No obstante, estos métodos permiten que los clientes se den cuenta de la mejora diaria en el software. Asimismo, el proceso de de­sa­rro­llo es más rápido, ya que no hay in­te­rru­p­cio­nes en ningún momento. Esto permite ahorrar en algunas si­tua­cio­nes los costes adi­cio­na­les de los marcos de prueba al final. En cuanto a la entrega continua, el cliente tiene libertad de acción, por lo que los re­qui­si­tos se pueden es­pe­ci­fi­car po­s­te­rio­r­me­n­te sin causar ningún in­co­n­ve­nie­n­te. Además, es fácil realizar pequeños cambios en el código.

A di­fe­re­n­cia de la Co­n­ti­nuous In­te­gra­tion, la Co­n­ti­nuous Delivery renuncia por completo a la li­be­ra­ción in­te­r­me­dia de código y, por lo tanto, se re­co­mie­n­da utilizar este proceso de trabajo para elaborar proyectos más pequeños en los que la ac­tua­li­za­ción constante no es re­le­va­n­tes o incluso puede llegar a ser un obstáculo.