Close

Descubre la entrega continua con Bitbucket Pipelines

Foto de Sten Pittet
Sten Pittet

Escritor colaborador

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

Duración

30 minutos

Público

Usuario sin experiencia en la implementación continua y/o Bitbucket Pipelines

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 que muestra la diferencia entre la implementación continua y el desarrollo continuo | CI/CD de Atlassian

Adopción de una canalización de entrega continua

En este ejemplo, ampliaremos la sencilla aplicación node.js que creamos en el tutorial de integración continua con una canalización de entrega continua que se implementa automáticamente en el entorno de ensayo cuando la compilación pasa la prueba. Veremos dos estrategias diferentes para la implementación en la producción: una con ramas y solicitudes de incorporación de cambios, 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. 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, regístrate en Heroku.

A continuación, instala la CLI de Heroku.

Actualiza package.json para que sea algo parecido a esto:

{
  "name": "cdtutorial",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "mocha --exit"
  },
  "repository": {
    "type": "git",
    "url": "git+ssh://git@bitbucket.org/pmmquickstartguides01/cdtutorial.git"
  },
  "author": "",
  "license": "ISC",
  "bugs": {
    "url": "https://bitbucket.org/pmmquickstartguides01/cdtutorial/issues"
  },
  "homepage": "https://bitbucket.org/pmmquickstartguides01/cdtutorial#readme",
  "dependencies": {
    "express": "^4.17.3"
  },
  "devDependencies": {
    "mocha": "^9.2.2",
    "supertest": "^6.2.2"
  }
}

Actualiza el archivo server.js para que sea más o menos así:

var express = require("express");
var app = express();

app.get("/", function (req, res) {
  res.send("Hello World!");
});

app.listen(process.env.PORT || 3000, function () {
  console.log("Example app listening on port 3000!");
});

module.exports = app;

Fíjate en el cambio en app.listen (). Ahora incluye Process.env.PORT, que está definido por Heroku.

Ejecuta lo siguiente para añadir Procfile al directorio raíz del repositorio de ejemplo:

touch Procfile

Luego, añade el siguiente texto a Procfile:

web: npm start

Inicia sesión en Heroku, haz clic en el icono de usuario de la esquina superior derecha, haz clic en Account Setting (Configuración de cuenta) y desplázate hacia abajo hasta encontrar la clave de API.

Localizar la clave de API en la configuración de la cuenta de Heroku

A continuación, añade una variable 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

Para añadir esta variable, 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

En esta guía utilizamos Heroku, pero este ejemplo se puede adaptar a otros servicios de alojamiento. Usa esta guía como referencia de Heroku.

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 incorporación de cambios antes de implementarlos en la producción.

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

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

Crea la rama production en Bitbucket Cloud haciendo clic en Ramas.

Rama production en Bitbucket Cloud

Luego, haz clic en Crear rama.

Opción "Crear rama" en la ventana emergente de Bitbucket Cloud

Escribe "production" y haz clic en Crear.

Desde el directorio raíz del repositorio de ejemplo, ejecuta esto:

heroku create --remote staging
git push staging main
heroku create --remote production
git push production main

Para ver si esto ha funcionado correctamente, ve a Heroku en un navegador y comprueba si aparecen dos aplicaciones.

Aplicaciones que se muestran en Heroku en el navegador

Ejecuta también esto:

git remote -vv

Los resultados esperados tendrán tres ramas remotas, una para Bitbucket y dos para Heroku. Una será la rama remota de entorno de ensayo, mientras que la otra será la rama production remota.

wmarusiak@C02F207NML7L cdTutorial % git remote -vv
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (fetch)
origin git@bitbucket.org:pmmquickstartguides01/cdtutorial.git (push)
production https://git.heroku.com/young-harbor-11356.git (fetch)
production https://git.heroku.com/young-harbor-11356.git (push)
staging https://git.heroku.com/boiling-refuge-14681.git (fetch)
staging https://git.heroku.com/boiling-refuge-14681.git (push)

A continuación, configura 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 main. Haz este cambio en tu terminal y envíalo a la rama main de origen.

bitbucket-pipelines.yml

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/boiling-refuge-1468.git main

Asegúrate de reemplazar la URL de git push para main por la URL del entorno de ensayo de git remote -vv de más arriba.

Ahora hemos creado una canalización que implementará cada envío de la rama main a Heroku después de compilar y evaluar nuestra aplicación. La sección de clones al comienzo de la configuración garantiza 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 production a fin de publicar automáticamente el entorno de producción cuando los cambios se fusionan en la rama production. Haz este cambio en tu terminal y envíalo a la rama main de origen.

bitbucket-pipelines.yml

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
    production:
      - step:
          name: deploy_to_production
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production:main

Asegúrate de reemplazar la URL de git push para main por la URL del entorno de ensayo de git remote -vv y la URL de git push para producción por la URL de producción de git remote -vv.

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 incorporación de cambios 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.

Mensaje de "Hello World!" que confirma que el entorno de producción está actualizado

¡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.

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:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          name: deploy_to_staging
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
  custom:
    prod-deployment:
      - step:
          name: deploy_to_production
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/fierce-basin-45507.git production:main

Asegúrate de reemplazar la URL de git push para main por la URL del entorno de ensayo de git remote -vv y la URL de git push para producción por la URL de producción de git remote -vv.

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.

Selección y ejecución de una canalización desde Bitbucket

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.

Canalización de implementación del entorno de producción en Bitbucket

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.

Mensaje de prueba de "Hello World!" en el entorno de producción

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.

Sten Pittet
Sten Pittet

Llevo 10 años en el negocio del software desempeñando diversas funciones, desde el desarrollo hasta la gestión de productos. Tras pasar los últimos 5 años en Atlassian trabajando en herramientas para desarrolladores, ahora escribo sobre compilación de software. Fuera del trabajo, me dedico a perfeccionar mis habilidades como padre con el maravilloso hijo que tengo.


Compartir este artículo

Lecturas recomendadas

Consulta estos recursos para conocer los tipos de equipos de DevOps o para estar al tanto de las novedades sobre DevOps en Atlassian.

Ilustración de Devops

La comunidad de DevOps

Ilustración de Devops

Taller de simulación

Ilustración de un mapa

Pruébalo gratis

Suscríbete para recibir el boletín de DevOps

Thank you for signing up