Close

Conoce la implementación continua con Bitbucket Pipelines

Foto de Sten Pittet
Sten Pittet

Escritor colaborador

En esta guía veremos cómo se puede desplegar una canalización de implementación continua con Bitbucket Pipelines

Duración

30 minutos

Público

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

En el desarrollo de software, a veces tienes que realizar difíciles compensaciones al desarrollar una aplicación. Si quieres ir más rápido, la creencia general es que tendrás que hacer concesiones en la calidad de tus versiones. Sin embargo, hay una práctica de desarrollo que te permite ahorrar tiempo además de publicar más rápido: la implementación continua.

Gracias a la implementación continua, eliminas el estrés que supone implementar software convirtiendo esta tarea en un proceso automatizado. Tu equipo de desarrollo no tiene que detenerse más ni cambiar de contexto para una versión: el código se lanza a tus clientes en cuanto un desarrollador ha terminado su trabajo.

En esta guía veremos cómo se puede desplegar una canalización de implementación continua con Bitbucket Pipelines.

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

Configuración de un canal de implementación continua

En este ejemplo, ampliaremos la sencilla aplicación node.js que creamos en añadiendo una canalización de implementación continua. La implementación continua es una manera excelente de que los equipos aceleren el desarrollo. Elimina los obstáculos relacionados con el proceso de aprobación de publicaciones y permite a los desarrolladores recibir feedback de los clientes en cuanto han terminado su trabajo. Es más fácil detectar y resolver incidencias, y hay menos cambio de contexto, ya que deja de haber tiempo de publicación.

Configurar una canalización de implementación continua con Bitbucket Pipelines es muy sencillo. Veremos cómo hacerlo con una sencilla aplicación Hello World que pasa por un entorno de ensayo y pruebas de aceptación antes de publicarse automáticamente en la producción.

Paso 1: Crea una nueva aplicación de Heroku

En el tutorial de entrega continua, enviamos una rama con fusiones a la aplicación de Heroku de producción. Ahora, crearemos otra aplicación de Heroku para evitar conflictos al enviar este tutorial. Ejecuta lo siguiente.

heroku create --remote production2
git push production2 main

Ahora, git remote -vv muestra algo parecido a lo siguiente. Usa staging y production2 para el resto de este tutorial.

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/fierce-basin-45507.git (fetch)
production https://git.heroku.com/fierce-basin-45507.git (push)
production2 https://git.heroku.com/limitless-headland-92324.git (fetch)
production2 https://git.heroku.com/limitless-headland-92324.git (push)
staging https://git.heroku.com/thawing-river-12585.git (fetch)
staging https://git.heroku.com/thawing-river-12585.git (push)

Paso 2: Configura la canalización

Nuestro workflow es sencillo:

  • Crea la aplicación.
  • Ejecuta pruebas para la compilación.
  • Impleméntala en el entorno de ensayo.
  • Ejecuta pruebas de aceptación en el entorno de ensayo.
  • Haz la implementación en producción.

Como verás, es muy sencillo crear la configuración de canalización correspondiente. Para empezar, añadimos nuestra implementación automática en el entorno de ensayo, para asegurarnos de que todos los envíos funcionan correctamente.

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

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

Notarás que utilizamos una clonación completa para que Heroku no rechace nuestro envío. Además, también utilizaremos una canalización específica de rama para que solamente se implementen en el entorno de ensayo los cambios enviados en la rama principal, y no en otras ramas. Puedes enviar esta configuración a Bitbucket para verla en acción.

Enviar la configuración a Bitbucket Pipelines

Implementación automática completada en el entorno de ensayo

En esta fase, tenemos implementada nuestra aplicación Hello World en el entorno de ensayo.

Captura de pantalla de la aplicación "Hello World" implementada en el entorno de ensayo

Ahora podemos avanzar al siguiente paso y añadir nuestras pruebas de aceptación. Las pruebas de aceptación sirven para asegurarnos de que la aplicación se comporta como se esperaba en un entorno similar al de producción (ensayo). El objetivo es acabar con incertidumbres debidas a diferencias en la configuración entre el entorno utilizado para probar la compilación y la producción.

Si miras el código de nuestra aplicación, nuestra prueba está haciendo algo extremadamente simple: busca la presencia de la cadena "Hello World" en la página. En una aplicación real, recomendamos tener pruebas de aceptación que vayan mucho más allá y verifiquen que todos los servicios de base que utiliza la aplicación (base de datos, caché, terceros, etc.) funcionan correctamente.

Para añadir una prueba de aceptación, sigue estos pasos.

mkdir acceptance-test
touch acceptance-test/test.js

A continuación, edita acceptance-test/test.js y añade el siguiente fragmento de código.

var request = require('supertest');

// Running a test on our staging environment
describe('GET /', function() {
  it('displays "Hello World!" on staging', function(done) {
    var staging_url = 'https://' + process.env.HEROKU_STAGING + '.herokuapp.com'
    // The line below is the core test of our app.
    request(staging_url).get("/").expect("Hello World!", done);
  });
});

Actualiza el archivo package.json para que incluya --timeout 10000.

{
  "name": "cdtutorial",
  "version": "1.0.0",
  "description": "",
  "main": "server.js",
  "scripts": {
    "start": "node server.js",
    "test": "mocha --exit --timeout 10000"
  },
  "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"
  }
}

Así que vamos a añadir nuestra prueba justo después de la implementación en el entorno de ensayo.

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
            - HEROKU_STAGING=thawing-river-12585 npm test acceptance-test

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

Tras aplicar esta nueva configuración en Bitbucket, podemos ver nuestro canal completado satisfactoriamente.

Canalización que se ejecuta correctamente en Bitbucket

Bitbucket Pipelines ahora ejecuta pruebas de aceptación tras la implementación en el entorno de ensayo

Lo único que queda es añadir nuestra implementación de producción al final, para completar nuestra canalización de implementación continua.

image: node:16

clone:
  depth: full

pipelines:
  branches:
    main:
      - step:
          script:
            - npm install
            - npm test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/thawing-river-12585.git main
            - HEROKU_STAGING=thawing-river-12585 npm test acceptance-test
            - git push https://heroku:$HEROKU_API_KEY@git.heroku.com/limitless-headland-92324.git 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 production2 de git remote -vv.

Un último envío a Bitbucket llevará nuestros cambios de código a través de toda la canalización, compilando y probando el código y, después de verificar que el entorno de ensayo funciona, implementándolo en producción. En este caso, la página de inicio se ha actualizado con un mensaje diferente, para asegurarnos de que se implementa hasta la producción.

Mensaje de la página de inicio actualizado para confirmar que se ha implementado en producción: "Hello World! Straight to production!"

¡El nuevo mensaje ha llegado hasta la producción, tal y como queríamos!

Finalización de la canalización de implementación continua en Bitbucket

Comprobación de que el código ha pasado por el canal

Es importante destacar la importancia de contar con un buen conjunto de herramientas de pruebas, así como un método de supervisión en tiempo real antes de continuar y desplegar la implementación continua para tus propios repositorios. A partir de ahora, los cambios irán directos a la producción en cuanto se envíen a la rama main, de modo que es muy importante garantizar que las pruebas automatizadas comprueban las partes críticas de la aplicación. Además, necesitarás herramientas de supervisión para detectar cambios que afecten de forma negativa a tus instancias de producción, ya se trate de una interrupción total o de un servicio degradado.

Encontrarás la fuente final en el repositorio de Bitbucket Cloud vinculado a continuación.

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