Descubre la entrega continua con Bitbucket Pipelines

En esta guía, veremos cómo se usa Bitbucket Pipelines para adoptar un flujo de trabajo de entrega continua. ¡Sigue leyendo! 

Sten Pittet Sten Pittet

Requisitos

Duración:

30 minutos

Público:

Es tu primera vez con la entrega continua o Bitbucket Pipelines

Requisito previo:

Pruébalo gratis

Publicar una nueva función siempre es un momento emocionante, ya que estás a punto de brindar nuevas capacidades a tus clientes. Pero también puede ser un ejercicio arriesgado que exija mucha preparación, lo que haría que tu equipo se muestre reacio a hacerlo a menudo. Y, cuanto más esperes, más difícil será implementar en la producción. Los cambios se acumulan y es difícil entender el alcance del cambio e identificar las causas principales si se producen problemas en la producción.

Una forma sencilla de eliminar el miedo y el coste de implementar software es automatizarlo y publicar cambios más pequeños con mayor frecuencia. En primer lugar, ahorrarás muchísimas horas que normalmente sirven para preparar el lanzamiento. Sin embargo, también reducirás el riesgo que implica la implementación de software al tener un alcance mucho más pequeño para cada lanzamiento, lo que facilita la supervisión de entornos y la resolución de incidencias.

Esta automatización de implementación es algo que puedes realizar fácilmente hoy mismo con Bitbucket Cloud. Para cada uno de tus repositorios, puedes configurar una canalización que compilará, evaluará e implementará automáticamente el código en tus entornos en cada inserción. En esta guía, veremos cómo se usa Bitbucket Pipelines para adoptar un flujo de trabajo de entrega continua.

Entrega continua frente a implementación continua

La práctica de entrega continua consiste en asegurarse de que el código siempre esté listo para publicar, aunque no se implementen todos los cambios en la producción. Es recomendable actualizar la producción tan a menudo como sea posible para mantener al mínimo el alcance de los cambios, pero tú eres quien decide en última instancia el ritmo de publicación.

En la implementación continua, los nuevos cambios que se envían al repositorio se implementan automáticamente en la producción si superan las pruebas. Esto pone más énfasis (o lo que es lo mismo, más presión) en la cultura de pruebas, pero es una forma excelente de acelerar el ciclo de feedback con los clientes.

Diagrama con la comparación entre la entrega continua (CD) y la integración continua (CI) | CI y CD de Atlassian

Adopción de una canalización de entrega continua

En este ejemplo, compilaremos una sencilla canalización de entrega continua que implemente automáticamente en el entorno de ensayo cuando la compilación pase la prueba. Veremos dos estrategias diferentes para la implementación en la producción: una con ramas y solicitudes de extracción, y la otra con canalizaciones personalizadas y desencadenadores manuales.

En ambos ejemplos, utilizaremos una sencilla aplicación de Node.js que muestre el mensaje “Hello World” en tu navegador. Puedes clonar el código de la aplicación Hello World a continuación y utilizarlo para seguir este tutorial.

Implementaremos esta aplicación en los entornos de ensayo y de producción alojados en Heroku utilizando ambos métodos.

Una aplicación básica de Hello World | CI y CD de Atlassian

Nuestra aplicación básica Hello World

Preparación de una implementación en Heroku

Para empezar, deberemos añadir algunas variables de entorno a Bitbucket Pipelines para que podamos realizar implementaciones en Heroku:

  • HEROKU_API_KEY: puedes encontrar tu clave de API en tu cuenta de Heroku
  • HEROKU_STAGING: nombre de tu entorno de ensayo
  • HEROKU_PROD: nombre de tu entorno de producción

Para añadir todas estas variables, ve a Pipelines > Environment variables (Canalizaciones > Variables de entorno) en la configuración del repositorio.

Captura de pantalla con la configuración de Heroku en Bitbucket | CI y CD de Atlassian

Configuración de variables de entorno que implementar en Heroku

Estamos utilizando Heroku en esta guía, pero sin duda es posible adaptar este ejemplo a otros servicios de hosting. Puede encontrar otras guías de implementación en la documentación.

Entrega continua con ramas como entrada a la producción

Esta configuración es adecuada para equipos con ramas de publicación especiales que se pueden asignar a una implementación. También te permite revisar los cambios en una solicitud de extracción antes de implementarlos en la producción.

En esta configuración, utilizaremos dos ramas diferentes para desencadenar las implementaciones:

  • Principal: cualquier envío a la rama principal implementará el código en un entorno de ensayo después de ejecutar las pruebas.
  • Producción: el código fusionado en la rama de producción se publicará automáticamente en el entorno de producción.

En primer lugar, configuraremos la implementación en el entorno de ensayo. Para ello, usaremos las canalizaciones específicas de ramas y crearemos una canalización que se ejecute por cada envío en la rama principal.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main

Ahora hemos creado una canalización que implementará cada envío a la rama principal en Heroku después de compilar y evaluar nuestra aplicación. Al comienzo de la configuración, la sección de clones asegura que hacemos un clon completo (de lo contrario, Heroku podría rechazar el git push). Solo tienes que enviar esta configuración a Bitbucket para ver tu primera implementación automatizada en el entorno de ensayo.

Captura de pantalla de una implementación de canalización correcta | CI y CD de Atlassian

Una canalización correcta que implementa nuestra aplicación en el entorno de ensayo

Como habrás adivinado, solo tenemos que añadir otra canalización para la rama de producción a fin de publicar automáticamente el entorno de producción cuando los cambios se fusionan en la rama de producción.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     # When code is pushed to the main branch it is deployed automatically to the staging environment.     main:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main     # When code is pushed to the main branch it is deployed automatically to the production environment.     production:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git production:main  

Volvemos a ejecutar las pruebas en la rama de producción para asegurarnos de que nada haya afectado a la compilación antes de publicar la aplicación.

Nuestros canales ahora están configurados y podemos restringir la rama de producción para aceptar únicamente las fusiones mediante solicitudes de incorporación de cambios. Solo tienes que ir a Workflow > Branch permissions (Workflow > Permisos de rama) en la configuración del repositorio para restringir la rama de producción. Este es un paso importante, ya que queremos evitar que la gente pase datos directamente a la producción desde su máquina local.

Configuración de los permisos de la rama de producción | CI y CD de Atlassian

Configuración de los permisos de la rama de producción

En la captura de pantalla anterior puedes ver los permisos:

  • Nadie tiene acceso de escritura
  • Solo un desarrollador puede fusionar en la rama

También hemos añadido una comprobación de merge para asegurarnos de que la rama de origen tenga, al menos, una compilación correcta antes de fusionar el código. Esto nos permitirá ahorrar tiempo de compilación y evitar que los desarrolladores de código fusionen el código incorrecto en nuestra rama de producción.

Una vez hecho esto, puedes crear una solicitud de extracción para fusionar el código de la rama principal en la producción y, posteriormente, publicar los nuevos cambios en tu entorno de producción.

Una captura de pantalla de Bitbucket sobre cómo crear una solicitud de extracción | CI y CD de Atlassian

Crea una solicitud de extracción para fusionar cambios en la producción

En cuanto fusiones la solicitud de incorporación de cambios, podrás ver cómo un nuevo canal se activa para la rama de producción.

Se ha desencadenado correctamente una canalización mediante la solicitud de extracción | CI y CD de Atlassian

Una vez terminada, se habrán implementado correctamente los nuevos cambios en el entorno de producción.

¡El entorno de producción está actualizado!

Ahora has configurado un flujo de trabajo de entrega continua con Bitbucket Pipelines y puedes utilizar solicitudes de extracción de forma segura para publicar código para tus clientes.

Puedes encontrar la fuente final de este ejemplo en el siguiente repositorio vinculado.

Entrega continua con desencadenador manual para la publicación

Esta configuración es ideal para equipos que ponen en práctica el desarrollo por tronco.

Con Bitbucket Pipelines, es posible configurar canalizaciones personalizadas que se pueden desencadenar manualmente. Tienen varios propósitos: pruebas de larga duración que no quieres ejecutar en cada envío o acciones específicas que deseas controlar personalmente. Usaremos una canalización personalizada para configurar un flujo de trabajo de entrega continua donde los envíos a la rama principal se implementan automáticamente en un entorno de ensayo y las confirmaciones se pueden implementar manualmente en la producción.

En primer lugar, hay que configurar la implementación automática en el entorno de ensayo. Tan solo tienes que añadir una canalización específica de rama para la rama principal que implementará el entorno de ensayo.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main  

Puedes enviar esta configuración a tu repositorio para ver en acción la primera implementación en el entorno de ensayo.

Nuestra primera implementación automática en el entorno de ensayo

Ahora que tenemos configurada nuestra implementación del entorno de ensayo, podemos añadir una canalización personalizada a nuestra configuración bitbucket-pipelines.yml, que usaremos para desencadenar la producción manualmente.

bitbucket-pipelines.yml

image: node:4.6.0   # Doing a full clone to be able to push back to Heroku. clone:   depth: full   pipelines:   branches:     main:       - step:           script: # Modify the commands below to build your repository.             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_STAGING.git main   custom:     prod-deployment:       - step:           script:             - npm install             - npm test             - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/$HEROKU_PROD.git main  

Después de enviar la nueva configuración a tu repositorio de Bitbucket, puedes ir a la confirmación y hacer clic en el enlace Run pipeline (Ejecutar canalización) bajo la información de la confirmación para desencadenar la implementación en la producción.

La acción para ejecutar la canalización incluirá las canalizaciones personalizadas disponibles

Solo tienes que pulsar el botón Ejecutar y se te redirigirá a la canalización de implementación de producción donde podrás supervisar los registros.

En la sección de información de confirmación de la canalización, puedes ver el nombre de la canalización personalizada que se ha utilizado. Ya puedes utilizar tu nueva configuración de Bitbucket Pipelines para una entrega continua y puedes comprobar la aplicación Hello World en la producción para asegurarte de que todo ha salido bien.

Nosotros hemos implementado Hello World en la producción mediante un desencadenador manual

Puedes encontrar la fuente final de este ejemplo en el siguiente repositorio vinculado.