Continous delivery (entrega continua en español) es un concepto bastante innovador de de­sa­rro­llo de software que cada vez se escucha con más fre­cue­n­cia. Gracias a esta práctica, las fases de pro­du­c­ción que incluyen el de­sa­rro­llo, el control de calidad y la entrega, no son de­fi­ni­ti­vas, sino que se repiten de forma au­to­ma­ti­za­da una y otra vez durante todo el proceso de de­sa­rro­llo a través de un pipeline de co­n­ti­nuous delivery. La principal ventaja es que, de esta manera, un software puede someterse cada poco tiempo a controles de calidad en cada una de sus fases de de­sa­rro­llo, pe­r­mi­tie­n­do realizar entregas, aunque el equipo siga tra­ba­ja­n­do en el de­sa­rro­llo del producto final. Además, hay un feedback constante que procede del pipeline, lo que nos permite mejorar el software de forma inmediata tras cada mo­di­fi­ca­ción in­tro­du­ci­da en el código fuente.

De­fi­ni­ción

Co­n­ti­nuous delivery hace re­fe­re­n­cia a una serie de prácticas uti­li­za­das en el de­sa­rro­llo de software para ejecutar el de­sa­rro­llo, la entrega, el feedback y la gestión de calidad de forma si­mu­l­tá­nea y cada poco tiempo, de acuerdo con un proceso re­pe­ti­ti­vo. De esta forma, se gana en efi­cie­n­cia y el cliente puede recibir el producto con mucha más prontitud, incluso cuando todavía no está terminado. La entrega continua genera un feedback constante para el de­sa­rro­lla­dor pro­ce­de­n­te de pruebas au­to­ma­ti­za­das que sirven, en general, para comprobar la es­tru­c­tu­ra después de cada cambio in­tro­du­ci­do en el código fuente.

Podemos resumir el co­n­ti­nuous delivery como un proceso recíproco que integra y au­to­ma­ti­za el de­sa­rro­llo, la entrega, el feedback y la gestión de calidad. El resultado es que podemos si­m­pli­fi­car las fases de trabajo para que nos lleven menos tiempo y se completen de forma más eficiente.

Las ventajas del co­n­ti­nuous delivery

Antes, el de­sa­rro­llo de software fu­n­cio­na­ba de una manera diferente: el producto final solo se entregaba si todas las fu­n­cio­na­li­da­des estaban to­ta­l­me­n­te de­sa­rro­lla­das, fu­n­cio­na­ban a la pe­r­fe­c­ción y no se de­te­c­ta­ban fallos im­po­r­ta­n­tes cuando se rea­li­za­ban las pruebas de calidad. Así que el de­sa­rro­lla­dor tenía que entregar po­s­te­rio­r­me­n­te parches o ac­tua­li­za­cio­nes cada cierto tiempo. Gracias al co­n­ti­nuous delivery, el cliente recibe el producto en una fase más temprana del de­sa­rro­llo en la que todavía no ha sido terminado. Esta pre-entrega suele incluir la fu­n­cio­na­li­dad es­tru­c­tu­ral del software para que el cliente pueda probarla en un entorno real. De esta manera, el propio cliente (o el tester de software) juega un papel muy im­po­r­ta­n­te dentro del proceso de control de calidad.

Gracias al feedback recibido, el de­sa­rro­lla­dor puede mejorar las fu­n­cio­na­li­da­des del producto durante la fase de de­sa­rro­llo. Además, recibe in­fo­r­ma­ción muy valiosa que le aporta una idea clara sobre qué fu­n­cio­na­li­dad debería de­sa­rro­llar a co­n­ti­nua­ción. Antes de que existiera el co­n­ti­nuous delivery, este proceso era realmente tedioso y, a menudo, dejaba de­s­co­n­te­n­tas a las dos partes: por un lado, el cliente no­r­ma­l­me­n­te espera que un producto final cumpla con sus re­qui­si­tos y deseos y, por otro, el de­sa­rro­lla­dor todavía no sabe exac­ta­me­n­te cuáles son esos re­qui­si­tos y deseos. Si se entabla una co­mu­ni­ca­ción sobre el estado de de­sa­rro­llo del producto en una fase más temprana, es más fácil tener en cuenta los re­qui­si­tos del cliente y no cometer errores. Es posible ilustrar en forma de ciclo este principio:

Imagen: Ciclo de desarrollo, garantía de calidad, producción
Co­n­ti­nuous Delivery au­to­ma­ti­za el ciclo de proceso relativo al de­sa­rro­llo, garantía de calidad y pro­du­c­ción.

Como muestra la imagen, las tres áreas que incluyen el de­sa­rro­llo, el control de calidad y la pro­du­c­ción no se re­em­pla­zan por un único proceso, sino que están co­n­s­ta­n­te­me­n­te in­te­r­co­ne­c­ta­das. De esta forma, un producto pasa por cada una de las fases in­di­vi­dua­les re­pe­ti­da­me­n­te y recibe mejoras continuas. Cuando tenemos que trabajar con muchos clientes al mismo tiempo, es imposible conseguir algo así si no contamos con procesos au­to­ma­ti­za­dos. Y en este punto es pre­ci­sa­me­n­te en el que in­te­r­vie­ne la entrega continua ya que se encarga de au­to­ma­ti­zar todo el proceso.

Gracias al co­n­ti­nuous delivery, es posible comprobar los procesos y mejoras im­ple­me­n­ta­dos sobre el software (es decir, todos los cambios rea­li­za­dos sobre el código fuente) en tiempo real con el fin de conseguir un feedback. Si un cambio genera efectos se­cu­n­da­rios no deseados, será posible de­te­c­tar­los rá­pi­da­me­n­te, lo que te permitirá im­ple­me­n­tar las acciones ne­ce­sa­rias en una fase temprana del de­sa­rro­llo. Este punto es realmente una mejora im­po­r­ta­n­te porque facilita, por ejemplo, la detección de bugs dentro del código. Sin la entrega continua, detectar dónde se encuentra el error se convierte en un trabajo realmente tedioso.

Hasta que llega al cliente, el software está en una fase in­te­r­me­dia, el pipeline de co­n­ti­nuous delivery. En este pipeline se llevan a cabo pruebas manuales y au­to­má­ti­cas. Cada fase de pruebas conlleva la aparición de una nueva versión del software (que suele llamarse “versión beta” o en algunas ocasiones “Nightly Build”, es decir la última versión creada de forma au­to­má­ti­ca) que, a su vez, entra en el pipeline. Hasta que se hayan pasado todas las pruebas y se reciba un feedback positivo, no se crea una versión “estable” y no se libera ofi­cia­l­me­n­te el producto (este proceso se conoce como “li­be­ra­ción” y también incluye a la propia apli­ca­ción publicada). Así aumentan co­n­si­de­ra­ble­me­n­te las pro­ba­bi­li­da­des de que el cliente reciba un producto sin bugs.

Imagen: Pipeline de continuous delivery para los cambios realizados en el código
El pipeline de co­n­ti­nuous delivery se activa cada vez que se realizan cambios en el código.

La principal ventaja del co­n­ti­nuous delivery es que el proceso au­to­ma­ti­za­do beneficia tanto al cliente como al de­sa­rro­lla­dor. Para el cliente, la ventaja radica en que el producto estará di­s­po­ni­ble más rápido y, no­r­ma­l­me­n­te, no pre­se­n­ta­rá errores. Para los de­sa­rro­lla­do­res, im­ple­me­n­tar pruebas de campo resulta mucho más efectivo que llevar a cabo pruebas durante la fase de testeo beta porque obtienen in­fo­r­ma­ción y orie­n­ta­cio­nes mucho más valiosas. Todo el proceso de de­sa­rro­llo adquiere una mayor fle­xi­bi­li­dad y se minimiza el riesgo de publicar software con bugs.

Resumen: ventajas y de­s­ve­n­ta­jas del co­n­ti­nuous delivery

Ventajas De­s­ve­n­ta­jas
Es mucho más fácil encontrar y eliminar los errores presentes en el software durante la etapa de de­sa­rro­llo. Factor de costo: es necesario contar con un servidor potente y fiable de in­te­gra­ción de datos para llevar a cabo las pruebas au­to­ma­ti­za­das y conseguir una li­be­ra­ción correcta y segura del producto.
En el pasado, el de­sa­rro­llo de software requería muchísimo esfuerzo. Gracias al co­n­ti­nuous delivery, los de­sa­rro­lla­do­res pueden co­n­ce­n­trar­se ex­clu­si­va­me­n­te en el de­sa­rro­llo. Las pruebas au­to­ma­ti­za­das tienen que funcionar a la pe­r­fe­c­ción y no presentar errores de código. En caso contrario, pueden ocasionar graves daños al ser eje­cu­ta­das.
Gracias al pipeline de co­n­ti­nuous delivery es mucho más sencillo para los de­sa­rro­lla­do­res llevar a cabo la re­so­lu­ción de problemas. Requiere que haya una buena coor­di­na­ción dentro del equipo porque los cambios in­tro­du­ci­dos en el código deben co­m­pi­lar­se de forma eficiente y con una de­te­r­mi­na­da fre­cue­n­cia.
Otros procesos de prueba (como las pruebas alfa y beta) conllevan más costes asociados. Requiere una buena y continua co­mu­ni­ca­ción con los clientes y sus sistemas de destino.
Se pueden dedicar más recursos a la etapa co­n­ce­p­tual que a la técnica durante el control de calidad para mejorar el software. El cliente espera que haya mejoras y ac­tua­li­za­cio­nes co­n­ti­nua­me­n­te. Es difícil poder “pausar” el proyecto de de­sa­rro­llo.
No­r­ma­l­me­n­te el de­sa­rro­llo de software se consigue de forma más rápida porque el proceso de li­be­ra­ción au­to­ma­ti­za­do reduce la carga de trabajo de los de­sa­rro­lla­do­res y también la cantidad de descansos que deben tomar. A la hora de im­ple­me­n­tar in­no­va­cio­nes, mejoras o mo­di­fi­ca­cio­nes al producto, sigue siendo necesario hacerlo ma­nua­l­me­n­te. Si se quiere au­to­ma­ti­zar este proceso, es necesario recurrir al co­n­ti­nuous de­plo­y­me­nt.
Gracias a que las pu­bli­ca­cio­nes de software ocurren más rápido y más a menudo, se recibe más feedback lo que se traduce en más mejoras. El cliente tiene que estar dispuesto a utilizar el software cuando todavía se encuentra en una fase de de­sa­rro­llo. Además, tiene que poner de su parte y de­vo­l­ve­r­nos su feedback.
Los de­sa­rro­lla­do­res tienen que soportar menos presión a la hora de realizar cambios en el código fuente porque los errores se en­cue­n­tran mucho más rápido. Esto sirve como mo­ti­va­ción e in­s­pi­ra­ción para el trabajo.

Las fases del pipeline de co­n­ti­nuous delivery

Cuando se produce una mo­di­fi­ca­ción en el código, se activa el pipeline de co­n­ti­nuous delivery y se ejecutan las pruebas. A co­n­ti­nua­ción, te mostramos las fases que atraviesa:

Imagen: Fases del pipeline de continuous delivery
El pipeline de co­n­ti­nuous delivery atraviesa varias fases y las ejecuta de principio a fin cada vez que se realizan cambios en el código.
  1. Fase de commit (Commit Stage): en esta primera fase de prueba se ejecutan tests de la versión del software, se de­sa­rro­llan sus co­m­po­ne­n­tes y, cuando es necesario, se compilan. Además, se llevan a cabo las pruebas unitarias pe­r­ti­ne­n­tes. Si se superan con éxito todas las pruebas, la fase se da por fi­na­li­za­da. En este momento, se compilan y se almacenan en el re­po­si­to­rio los ar­te­fa­c­tos binarios de los co­m­po­ne­n­tes de software. Por todo lo anterior, se trata de un paquete que afecta de­ci­si­va­me­n­te a la fu­n­cio­na­li­dad del pipeline porque determina el estado en el que se encuentra el software. Además, este paquete incluye todos los datos que serán in­s­ta­la­dos en un momento posterior en el sistema de destino. Los re­su­l­ta­dos de las pruebas en la fase de commit pueden asignarse de esta manera a las mo­di­fi­ca­cio­nes concretas rea­li­za­das sobre el código fuente, que es pre­ci­sa­me­n­te una de las ventajas más si­g­ni­fi­ca­ti­vas de la entrega continua.
  2. Fase de ace­p­ta­ción (Ac­ce­p­ta­n­ce Test Stage): en la segunda fase de prueba se ejecutan los tests de ace­p­ta­ción. Estamos hablando de las pruebas de in­te­gra­ción (para comprobar si la in­ter­ac­ción entre los co­m­po­ne­n­tes funciona) y las pruebas ne­ce­sa­rias del sistema (para comprobar si el software funciona del lado del usuario). Además, existen otras pruebas op­cio­na­les que forman parte de la fase de ace­p­ta­ción, como pruebas de re­n­di­mie­n­to y otros tests que ponen a prueba re­qui­si­tos no fu­n­cio­na­les del software. Durante la fase de ace­p­ta­ción, se vuelve a utilizar la co­m­pi­la­ción ejecutada en la fase previa que pasa a ser instalada en un entorno de pruebas adecuado.
  3. En caso de que se constaten errores o co­m­pli­ca­cio­nes durante alguna de las fases co­me­n­ta­das, se creará do­cu­me­n­ta­ción al respecto y, cuando sea necesario, se deberá enviar feedback al de­sa­rro­lla­dor. Puede enviarse mediante correo ele­c­tró­ni­co, programas de me­n­sa­je­ría o he­rra­mie­n­tas es­pe­cia­les (que co­me­n­ta­re­mos más adelante). Cada vez que se produce una mo­di­fi­ca­ción en el código, el pipeline se pone en fu­n­cio­na­mie­n­to por lo que los mensajes de error siempre hacen re­fe­re­n­cia a la última mo­di­fi­ca­ción. Así, el de­sa­rro­lla­dor puede reac­cio­nar con rapidez y de forma eficiente para arreglar los bugs o el código de­fe­c­tuo­so.
  4. Las pruebas manuales se realizan en función de las ne­ce­si­da­des concretas de cada caso. A la hora de realizar estas pruebas, el pipeline vuelve a utilizar la co­m­pi­la­ción creada en la primera fase y la reinstala en un entorno de pruebas adecuado.
  5. Si se completan todas las pruebas y el feedback recibido es positivo, ha llegado el momento de instalar el paquete ma­nua­l­me­n­te en el sistema de destino. No­r­ma­l­me­n­te, esto se hace con un solo clic. Es posible au­to­ma­ti­zar este paso a través del co­n­ti­nuous de­plo­y­me­nt.

Co­n­ti­nuous in­te­gra­tion vs. co­n­ti­nuous delivery

Dentro del mismo contexto en el que en­co­n­tra­mos el término co­n­ti­nuous delivery, aparece a menudo el término co­n­ti­nuous in­te­gra­tion. No obstante, hay una di­fe­re­n­cia muy im­po­r­ta­n­te que afecta al alcance de uno y otro; cuando hablamos de co­n­ti­nuous in­te­gra­tion estamos haciendo re­fe­re­n­cia a la au­to­ma­ti­za­ción del proceso de pruebas. Por lo tanto, el pipeline es un co­m­po­ne­n­te co­m­pa­r­ti­do con el co­n­ti­nuous delivery. En cambio, el continuos delivery es un término que abarca mucho más, co­n­cre­ta­me­n­te, abarca el proceso de li­be­ra­ción del software como un proceso au­to­ma­ti­za­do. Por lo tanto, la entrega continua co­m­ple­me­n­ta al modelo de co­n­ti­nuous in­te­gra­tion e involucra al usuario final ya que entrega el producto y, si­mu­l­tá­nea­me­n­te, ejecuta las pruebas pe­r­ti­ne­n­tes.

Como de­sa­rro­lla­dor, decidir si basta con utilizar la in­te­gra­ción continua o si es pre­fe­ri­ble ampliar el proceso de de­sa­rro­llo e incluir el co­n­ti­nuous delivery, dependerá de la pla­ni­fi­ca­ción del de­sa­rro­llo, del equipo de de­sa­rro­llo y de la base de clientes. En la siguiente tabla co­m­pa­ra­mos los dos conceptos:

Co­n­ti­nuous in­te­gra­tion (CI) Co­n­ti­nuous delivery (CD)
Proceso de pruebas au­to­ma­ti­za­do que revisa en pro­fu­n­di­dad cada mo­di­fi­ca­ción realizada en el código fuente. Abarca más que el proceso de pruebas e incluye al proceso de entrega. Las nuevas ca­ra­c­te­rí­s­ti­cas y las mo­di­fi­ca­cio­nes rea­li­za­das en el código llegan au­to­má­ti­ca­me­n­te al usuario final.
El equipo tiene que ejecutar pruebas au­to­ma­ti­za­das cada vez que se incluye una nueva ca­ra­c­te­rí­s­ti­ca, mejora o se produce una mo­di­fi­ca­ción en el código. Las pruebas tienen que ser realmente eficaces en el CD porque los re­su­l­ta­dos se entregan di­re­c­ta­me­n­te al usuario final.
Requiere un servidor de in­te­gra­ción dedicado y continuo que controle y ejecute las pruebas au­to­ma­ti­za­das. La in­s­ta­la­ción en el sistema de destino también debe ser lo más au­to­ma­ti­za­da posible, lo que plantea mayores exi­ge­n­cias al servidor.
Los de­sa­rro­lla­do­res tienen que fusionar las mo­di­fi­ca­cio­nes del código con mucha fre­cue­n­cia y de forma continua. Los de­sa­rro­lla­do­res tienen que mantener una buena co­mu­ni­ca­ción con el cliente y saber explicar de forma clara cómo funciona el software.
Requiere un uso re­la­ti­va­me­n­te elevado de recursos si se quiere ga­ra­n­ti­zar la calidad del producto en el momento de la entrega. En el caso del CD el esfuerzo es aún mayor pero el producto puede ser entregado mucho antes tras haber sido sometido a pruebas “reales”.
El de­sa­rro­llo en sí es más eficiente, pero es necesario pausarlo más a menudo debido a las li­be­ra­cio­nes manuales. Permite realizar un de­sa­rro­llo continuo porque el proceso de li­be­ra­ción está au­to­ma­ti­za­do en gran medida.

Las co­n­ti­nuous delivery tools más conocidas

Existen varios programas que nos ayudarán a comenzar a trabajar in­co­r­po­ra­n­do la entrega continua. Os pre­se­n­ta­mos cuatro de los más conocidos.

Jenkins

Jenkins es una apli­ca­ción web que facilita la in­te­gra­ción continua de los co­m­po­ne­n­tes del software. Jenkins está escrito en Java, se ejecuta en un co­n­te­ne­dor EJB y dispone de varias he­rra­mie­n­tas de build (Apache Ant, Maven/Gradle, CVS, Su­b­ve­r­sion, Git, etc.) y, por supuesto, de los procesos de pruebas au­to­má­ti­cas tan im­po­r­ta­n­tes en el caso del co­n­ti­nuous delivery (Junit, Emma). Existen plugins op­cio­na­les que sirven para ga­ra­n­ti­zar la co­m­pa­ti­bi­li­dad con otros co­m­pi­la­do­res. Gracias a su interfaz basada en REST, otros programas pueden acceder a Jenkins. Jenkins es un programa gratuito de código abierto. Está re­co­me­n­da­do es­pe­cia­l­me­n­te para pri­n­ci­pia­n­tes porque su interfaz y las fu­n­cio­na­li­da­des que ofrece son muy in­tui­ti­vas y fáciles de usar.

Consejo

Echa un vistazo a nuestro tutorial de Jenkins sobre el fu­n­cio­na­mie­n­to de la apli­ca­ción paso a paso.

CircleCI

CircleCI también es una apli­ca­ción web para co­n­ti­nuous in­te­gra­tion, delivery and de­plo­y­me­nt. CircleCI funciona pre­fe­ri­ble­me­n­te con GitHub, GitHub En­te­r­pri­se y Bitbucket. Además, la pla­ta­fo­r­ma ofrece muchas fu­n­cio­na­li­da­des prácticas como la gestión de pedidos, gestión de recursos, docker support, soporte de todos los lenguajes de pro­gra­ma­ción conocidos, al­ma­ce­na­mie­n­to seguro en caché, análisis de datos con es­ta­dí­s­ti­cas y completos conceptos de seguridad. CircleCI recibió el premio “Leader in Co­n­ti­nuous In­te­gra­tion” de Forrester en 2017. El primer co­n­te­ne­dor es gratuito y a partir del segundo el precio es de 50 $ por co­n­te­ne­dor al mes.

Microsoft Team Fou­n­da­tion Server

Microsoft Team Fou­n­da­tion Server (TFS) es una he­rra­mie­n­ta co­la­bo­ra­ti­va para proyectos de software que tienen que pla­ni­fi­car­se, de­sa­rro­llar­se y fi­na­l­me­n­te ser ge­s­tio­na­dos de manera conjunta. TFS es el sucesor no oficial de Microsoft’s Visual Sou­r­ce­Sa­fe. Para permitir el trabajo co­la­bo­ra­ti­vo en los proyectos de software, TFS soporta varios procesos de de­sa­rro­llo, incluido el CMMS, el de­sa­rro­llo de software ágil y Scrum. Además, TFS está vinculado e integra programas de Office muy conocidos como Word y Excel para que no tengas que salir de TFS y abrir otro programa.

Existen varias ca­ra­c­te­rí­s­ti­cas que te permiten crear un pipeline para co­n­ti­nuous in­te­gra­tion, delivery and de­plo­y­me­nt. Lo que hace TFS bá­si­ca­me­n­te es dividir el proceso completo en varios apartados: control de versiones, build, reports y ad­mi­ni­s­tra­ción de usuario.

Los equipos de hasta 5 personas pueden utilizar de forma gratuita la versión Express. Los equipos más grandes deberán hacerse con la versión comercial que tiene un precio apro­xi­ma­do de 6 euros por usuario al mes. Pero no­r­ma­l­me­n­te esto conlleva la obli­ga­ción de comprar una licencia de servidor. También es posible hacerse con TFS sin su­s­cri­p­ción mensual, aunque para ello tienes que contactar con tu di­s­tri­bui­dor local. El precio se encuentra entre los 500 y los 700 euros.

Codeship

Codeship es una pla­ta­fo­r­ma SaaS de in­te­gra­ción continua (y de entrega) que se adapta a las ne­ce­si­da­des pa­r­ti­cu­la­res de cada usuario. Codeship soporta GitLab, GitHub y Bitbucket. Las fu­n­cio­na­li­da­des di­s­po­ni­bles dependen del plan co­n­tra­ta­do. Por ejemplo, en su versión gratuita, Codeship ofrece un entorno CI pre­de­fi­ni­do y flujos de trabajo CI/CD. Además, la versión gratuita permite realizar un al­ma­ce­na­mie­n­to de caché eficiente y pruebas de builds si­mu­l­tá­neas en co­n­te­ne­do­res co­m­pa­r­ti­dos y pre­co­n­fi­gu­ra­dos. El plan gratuito incluye 100 builds al mes, un co­n­ti­nuous build y un pipeline de pruebas. De­s­ta­ca­mos el hecho de que no hayan es­ta­ble­ci­do un límite de proyectos, usuarios o equipos máximos pe­r­mi­ti­dos.

Si queremos sacarle más partido a Codeship, podemos comprar el plan “Codeship Basic”, que cuesta apro­xi­ma­da­me­n­te 45 euros al mes y va in­cre­me­n­ta­n­do su precio en función del tamaño del equipo. Existe también otra versión de pago, la “Codeship Pro”, que aporta una fu­n­cio­na­li­dad adicional tutorial para docker, el “control completo” sobre el entorno de build, los builds locales y un mejor control del flujo de trabajo. Además, ofrece muchas he­rra­mie­n­tas que ayudan a ganar en efi­cie­n­cia y tra­n­s­pa­re­n­cia. El precio varía en función del número de builds paralelos, pero es apro­xi­ma­da­me­n­te de 70 euros mensuales.

Ir al menú principal