Para hablar de CI\/CD, consideramos necesario introducir un concepto m\u00e1s amplio que, por razones obvias de espacio y coherencia, no podemos profundizar m\u00e1s all\u00e1 de un breve p\u00e1rrafo. El concepto que debemos mencionar es DevOps. Veamos qu\u00e9 se entiende por DevOps. <\/p>\n
El t\u00e9rmino \u00abDevOps\u00bb combina \u00abDesarrollo\u00bb y \u00abOperaciones\u00bb. DevOps engloba muchos aspectos y pr\u00e1cticas para gestionar los procesos de producci\u00f3n de software. T\u00e9cnicamente, DevOps indica un conjunto de enfoques y valores, m\u00e1s que una lista de pr\u00e1cticas concretas a utilizar. DevOps debe declinarse en un contexto concreto, en los distintos equipos de producci\u00f3n y gesti\u00f3n de software. Como informa aqu\u00ed<\/a> RedHat: DevOps describe los enfoques que deben adoptarse para acelerar los procesos que permiten que una idea (como una nueva funci\u00f3n de software, una solicitud de mejora o una correcci\u00f3n de errores) pase del desarrollo al despliegue en un entorno de producci\u00f3n, donde puede aportar valor al usuario. Estos enfoques requieren una comunicaci\u00f3n frecuente entre los equipos de desarrollo y los operativos. En este contexto, CI\/CD es un enfoque que forma parte de DevOps. CI\/CD (Integraci\u00f3n Continua\/Entrega Continua – Despliegue) es un enfoque de desarrollo de software que consiste en construir, probar y entregar de forma continua y autom\u00e1tica el c\u00f3digo desarrollado. CI\/CD permite la integraci\u00f3n autom\u00e1tica de los cambios incorporados al c\u00f3digo fuente mediante el uso de pipelines, es decir, la automatizaci\u00f3n de las operaciones de construcci\u00f3n, prueba y despliegue del software. Como afirma RedHat aqu\u00ed<\/a>: El enfoque CI\/CD es un componente fundamental de la metodolog\u00eda DevOps, cuyo prop\u00f3sito es aumentar la colaboraci\u00f3n entre los equipos de desarrollo y operaciones. Ambos m\u00e9todos se centran en la automatizaci\u00f3n de los procesos de integraci\u00f3n del c\u00f3digo, acelerando as\u00ed el paso de una idea (como una nueva funci\u00f3n, una correcci\u00f3n de errores o una solicitud de mejora) de la fase de desarrollo a la de despliegue, en un entorno de producci\u00f3n donde pueda ofrecer un valor a\u00f1adido al usuario. El CI\/CD incluye pasos que integran las operaciones a realizar para probar, compilar e integrar nuevos desarrollos en un software; el flujo de trabajo del equipo se adapta al uso de pipelines para optimizar su productividad y minimizar el tiempo y los errores en la fase de lanzamiento del software. Veamos algunos de los pasos cl\u00e1sicos que se integran en un pipeline de CI\/CD, teniendo en cuenta que no son los \u00fanicos posibles y que el pipeline debe adaptarse a las necesidades del software que se est\u00e1 desarrollando y del equipo que trabaja en \u00e9l. <\/p>\n La compilaci\u00f3n es el paso que crea alg\u00fan tipo de ejecutable a partir del c\u00f3digo fuente de la aplicaci\u00f3n. Un tipo de software muy utilizado hoy en d\u00eda se denomina \u00abdockerizado\u00bb. Docker<\/a> se basa en ciertas caracter\u00edsticas del kernel de Linux para permitir que el mismo software y sus dependencias se ejecuten en diferentes entornos. La compilaci\u00f3n del software suele generar im\u00e1genes Docker, que son el software que posteriormente ejecutar\u00e1 Docker; tienen la ventaja de ser port\u00e1tiles, autocontenidas y f\u00e1ciles de replicar. <\/p>\n La fase de prueba en el proceso CI\/CD es fundamental: garantiza que el c\u00f3digo integrado en la aplicaci\u00f3n no contenga regresiones o errores f\u00e1cilmente detectables. Normalmente, la fase de pruebas se lleva a cabo sobre el c\u00f3digo fuente creado por la fase de compilaci\u00f3n, o la fase de pruebas se basa en la propia compilaci\u00f3n, dependiendo de las caracter\u00edsticas del software. El proceso suele prever que, si las pruebas fallan, se detenga la publicaci\u00f3n; de lo contrario, el proceso contin\u00faa con la siguiente fase. <\/p>\n El versionado de software implica guardar un historial de los cambios realizados en el software. Normalmente, se utiliza alg\u00fan sistema tipo Git<\/a> para versionar el c\u00f3digo fuente; dado que Git es distribuido, a menudo se depende de alg\u00fan sistema centralizado como GitHub<\/a> o GitLab<\/a> para mantener una versi\u00f3n oficial del proyecto. Adem\u00e1s, el versionado implica asignar una versi\u00f3n, normalmente representada de alguna forma alfanum\u00e9rica, al c\u00f3digo fuente y a los ejecutables generados a partir de \u00e9l. Es posible integrar la fase de versionado autom\u00e1ticamente en un pipeline. La versi\u00f3n del software suele asignarse mediante el versionado sem\u00e1ntico<\/a>, que tiene la forma M.m.p, donde M es la versi\u00f3n mayor, m es la versi\u00f3n menor y p es el parche. <\/p>\n Un pipeline, como ya se ha mencionado, es un procedimiento que automatiza el proceso CI\/CD y con \u00e9l la liberaci\u00f3n de software a partir de nuevo c\u00f3digo fuente. El objetivo del pipeline es permitir a los desarrolladores realizar liberaciones de forma autom\u00e1tica, aliviando as\u00ed la carga de trabajo de los equipos de Operaciones y Sistemas. <\/p>\n GitLab<\/a><\/a> es una plataforma DevOps que permite integrar f\u00e1cilmente pipelines en los proyectos. GitLab integra el versionado del c\u00f3digo fuente a trav\u00e9s de Git, guard\u00e1ndolo en servidores centralizados que garantizan versiones compartidas y oficiales, herramientas y pipelines de CI\/CD, y pr\u00e1cticas de control y seguridad del software. Incluir un pipeline en un proyecto GitLab es muy sencillo: basta con crear un archivo llamado .gitlab-ci-yml y colocarlo en el directorio ra\u00edz del proyecto. El archivo .gitlab-ci.yml describe el pipeline en t\u00e9rminos de fases, trabajos y los distintos scripts correspondientes. La etapa es la implementaci\u00f3n de las fases presentadas anteriormente: compilaci\u00f3n, generaci\u00f3n de versiones, pruebas u otras; un trabajo es una tarea concreta que ejecuta una parte de la etapa. Una etapa puede constar de varios trabajos, que se ejecutan en paralelo; las distintas etapas, en cambio, se realizan secuencialmente. Por \u00faltimo, el script implementa los comandos espec\u00edficos relacionados con cada trabajo; adem\u00e1s del script, \u00e9ste incluye indicaciones sobre el entorno y el modo de ejecuci\u00f3n. Las etapas del pipeline y sus scripts son ejecutados por defecto por los GitLab runners (procesos que proporcionan un entorno en el que ejecutar los comandos del script). Por supuesto, es posible configurar ejecutores locales. Para ello, consulta la documentaci\u00f3n de GitLab<\/a>. Un ejemplo de pipeline cuyo \u00fanico prop\u00f3sito es introducir la sintaxis del archivo es: build_job: version_job: test_job: deploy_job: Un ejemplo de c\u00f3digo de versionado de un pipeline al realizar una petici\u00f3n de fusi\u00f3n en el siguiente archivo .gitlab-ci.yml. Para hablar de CI\/CD, consideramos necesario introducir un concepto m\u00e1s amplio que, por razones obvias de espacio y coherencia, no podemos profundizar m\u00e1s all\u00e1 de un breve p\u00e1rrafo. El concepto que debemos mencionar es DevOps. Veamos qu\u00e9 se entiende por DevOps. DevOps: conceptos b\u00e1sicos El t\u00e9rmino \u00abDevOps\u00bb combina \u00abDesarrollo\u00bb y \u00abOperaciones\u00bb. DevOps engloba muchos aspectos […]<\/p>\n","protected":false},"author":1,"featured_media":5849,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"site-sidebar-layout":"default","site-content-layout":"","ast-site-content-layout":"default","site-content-style":"default","site-sidebar-style":"default","ast-global-header-display":"","ast-banner-title-visibility":"","ast-main-header-display":"","ast-hfb-above-header-display":"","ast-hfb-below-header-display":"","ast-hfb-mobile-header-display":"","site-post-title":"","ast-breadcrumbs-content":"","ast-featured-img":"","footer-sml-layout":"","ast-disable-related-posts":"","theme-transparent-header-meta":"default","adv-header-id-meta":"","stick-header-meta":"","header-above-stick-meta":"","header-main-stick-meta":"","header-below-stick-meta":"","astra-migrate-meta-layouts":"default","ast-page-background-enabled":"default","ast-page-background-meta":{"desktop":{"background-color":"var(--ast-global-color-4)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"ast-content-background-meta":{"desktop":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"tablet":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""},"mobile":{"background-color":"var(--ast-global-color-5)","background-image":"","background-repeat":"repeat","background-position":"center center","background-size":"auto","background-attachment":"scroll","background-type":"","background-media":"","overlay-type":"","overlay-color":"","overlay-opacity":"","overlay-gradient":""}},"footnotes":""},"categories":[128],"tags":[],"class_list":["post-5856","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-novedades-tecnologicas"],"yoast_head":"\n
Traducci\u00f3n realizada con la versi\u00f3n gratuita del traductor www.DeepL.com\/Translator <\/p>\nQu\u00e9 significa CI\/CD<\/h4>\n
Compilaci\u00f3n<\/h4>\n
Pruebas<\/h4>\n
Versionado<\/h4>\n
Pipeline<\/h4>\n
Pipeline en GitLab<\/h4>\n
stages:
\n- build
\n- test
\n- deploy<\/p>\n
\nstage: build
\nscript:
\n- echo \"Building\"<\/p>\n
\nstage: build
\nscript:
\n- echo \"Versioning\"<\/p>\n
\nstage: test
\nscript:
\n- echo \"Testing\"<\/p>\n
\nstage: deploy
\nscript:
\n- echo \"Deploying\"<\/code> El archivo pipeline indica tres etapas, en nuestro caso: build, test y deploy. Se puede introducir un n\u00famero arbitrario de etapas con el nombre deseado. A continuaci\u00f3n, cada secci\u00f3n describe trabajos. El deploy_job, por ejemplo, se ejecuta en la etapa deploy y consiste en el script echo ‘Deploying’ (que imprime la cadena Deploying como salida est\u00e1ndar). Es posible decidir ejecutar el trabajo de despliegue s\u00f3lo para una determinada rama del c\u00f3digo versionado. Para ello, la configuraci\u00f3n debe ser:
\ndeploy:
\nonly:
\n- master
\nstage: deploy
\nscript:
\n- echo \"Deploying\"<\/code><\/p>\nUn ejemplo<\/h4>\n
stages:
\n- build
\n- test
\n- deploy<\/code> build: only: – master stage: build script: – echo “Building” version: stage: build before_script: – git config user.email “${GITLAB_USER_EMAIL}” – git config user.name “${GITLAB_USER_NAME}” – git remote add versioning-origin https:\/\/oauth2:${GITLAB_ACCESS_TOKEN}@gitlab.com\/${CI_PROJECT_PATH} script: – echo \u00abVersioning\u00bb – git fetch –tags – OLD_VERSION=`git describe –abbrev=0 –tags` – NEW_VERSION=`bash change_version.sh $OLD_VERSION` – git tag -a $NEW_VERSION -m \u00abAuto-tagged\u00bb – git push versioning-origin $NEW_VERSION rules: – if: $CI_MERGE_REQUEST_ID test: only: – etapa maestra: script de prueba: – echo \u00abProbando\u00bb deploy: only: – master stage: deploy script: – echo \u00abDeploying\u00bb Como puede verse, los comandos siguen la sintaxis de Bash. La secci\u00f3n
\nrules:
\n- if: $CI_MERGE_REQUEST_ID<\/code>indica a GitLab que compruebe la variable de entorno<\/a> por defecto CI_MERGE_REQUEST_ID, que especifica si el pipeline actual fue lanzado por una Merge Request<\/a>. Este pipeline llama al script change_version.sh, que debe ser guardado en el repositorio del proyecto para ser ejecutado correctamente. <\/p>\n","protected":false},"excerpt":{"rendered":"