Descubre la entrega continua con Bitbucket Pipelines
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.
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.
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 ProcfileLuego, añade el siguiente texto a Procfile:
web: npm startInicia 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.
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.
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.
Luego, haz clic en Crear rama.
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 mainPara ver si esto ha funcionado correctamente, ve a Heroku en un navegador y comprueba si aparecen dos aplicaciones.
Ejecuta también esto:
git remote -vvLos 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 mainAsegú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.
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: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 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
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.
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.
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.
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: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 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.
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.
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
