Conoce la implementación continua con Bitbucket Pipelines
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.
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 mainAhora, 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 mainAsegú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.
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.
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.jsA 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-testAsegú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.
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 mainAsegú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.
¡El nuevo mensaje ha llegado hasta la producción, tal y como queríamos!
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.
Compartir este artículo
Tema siguiente
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.
La comunidad de DevOps
Ruta de aprendizaje de DevOps
