Desplegament Amb Gitlab i Vercel

Explicación:

Primero que nada hemos creado un proyecto en gitlab, por ejemplo, DeploymentGitlabVercel. Por defecto, el proyecto tiene una rama principal(main),pero tenemos que crear dos ramas para esta práctica porque queremos separar la lógica de desarrollo(development) y implementación(deployment/Production).cree la rama Pages para desarrollo y la rama Vercel para implementación. Usamos el archivo .gitlab-ci.yml. El archivo .gitlab-ci.yml es un archivo de configuración utilizado en las canalizaciones de GitLab CI/CD (integración continua/implementación continua). Se utiliza para definir los pasos y acciones que se deben realizar cuando los cambios de código se envían a repositorio. Este archivo especifica las etapas de la canalización (como compilación, prueba, implementación), los scripts o comandos a ejecutar en cada etapa.

Diferencia Entre Desarrollo y Producción:

Para el desarrollo trabajamos en nuestro entorno local para crear una web comprobando errores, etc, cuando la web está lista sin ningún error para producción utilizamos Vercel. Inicie sesión en la cuenta de Vercel y cree una nueva clave para nuestra web, copie esa clave e ingrese a la configuración del proyecto gitlab y péguela aquí para realizar una implementación en Vercel. Recuerde que en el archivo de configuración .gitlab-ci.yml, después de realizar cualquier cambio, debemos ingresar nuestra rama relacionada, por ejemplo, si los cambios están relacionados con el desarrollo, primero debemos cambiar la rama de Pages usando el comando git checkout Pages y editar el archivo de configuración. Después de realizar cambios, hicimos todo el proceso para impulsar estos cambios en nuestro proyecto, como git add . git commit -m "cambios en desarrollo" git push origin Pages esto agregará cambios en nuestras páginas de rama, luego vamos a nuestro proyecto para crear una solicitud de combinación(merge) para estos cambios en la rama principal, lo mismo para la rama Vercel también.

Control de Versiones:

Hemos creado dos sucursales, Pages para desarrollo y Vercel para producción en nuestro proyecto gitlab. En local Creamos dos carpetas web y mkdocs en web, tenemos index.html, una web estática para nuestro proyecto, esa letra la implementaremos en gitlab Pages. Para separar una lógica de desarrollo y producción, después de agregar este archivo html en la carpeta web, tenemos que crear un git push en las páginas de la rama, luego vaya al proyecto y realice una solicitud de fusión a la rama principal. En el archivo de configuración tenemos dos etapas también mkdocs y web.

Comandos de git Para Control de Versiones:

git branch para comprobar en qué rama te encuentras ahora git checkout Pages para cambiar a la rama Pages git add . para agregar los cambios que hiciste en esa rama git commit -m "añadir web" comentar el cambio git push origin Pages para subir en rama Pages Luego ingrese al proyecto de gitlab y haga una solicitud de fusión (merge) de Pages a main.

Archivo de configuración .gitlab-ci.yml:

stages: - MkDocs - web - deploy

Explicación del codigo:

Esta sección define las etapas (stages) de su proceso de CI/CD. Especifica tres etapas: MkDocs, web e implementación. Los trabajos se ejecutarán en estas etapas de forma secuencial.

Etapa Mkdocs:

mkdocs: image: python:3.8-buster stage: MkDocs script: - pip install mkdocs - pip install mkdocs-material - mkdocs build -f MkDocs/mkdocs.yml - mkdir public - mkdir public/MkDocs - cp -r MkDocs/site/* public/MkDocs artifacts: paths: - public

Explicación del codigo:

Esto define un trabajo llamado mkdocs que pertenece a la etapa MkDocs. Se ejecuta en una imagen de Docker basada en Python 3.8. La sección de script instala MkDocs y su tema Material, construye el sitio MkDocs, crea un directorio llamado público, copia el sitio MkDocs en él y luego define los artefactos que se guardarán, que en este caso es el directorio público.

Etapa web:

pages: stage: web script: - cp web/index.html public artifacts: paths: - public

Explicación de etapa web:

Esto define un trabajo llamado pages que pertenece a la etapa web. Copia el archivo index.html del directorio web al directorio público. El directorio público se define como un artefacto.

Etapa deploy:

`deploy_preview: image: node:16.16.0 stage: deploy except: - main script: - npm install --global vercel - vercel pull --yes --environment=preview --token=$VERCEL_TOKEN - vercel build --token=$VERCEL_TOKEN - vercel deploy --prebuilt --token=$VERCEL_TOKEN

deploy_production: image: node:16.16.0 stage: deploy only: - main script: - npm install --global vercel - vercel pull --yes --environment=production --token=$VERCEL - vercel build --prod --token=$VERCEL - vercel deploy --prebuilt --prod --token=$VERCEL `

Explicación:

Estos dos bloques definen trabajos de implementación. El trabajo deploy_preview se implementa en un entorno de vista previa, mientras que el trabajo deploy_production se implementa en el entorno de producción. Ambos usan una imagen Docker de Node.js 16.16.0. Las directivas except y only especifican cuándo debe ejecutarse cada trabajo según los nombres de las ramas. Las secciones de script instalan Vercel CLI, extraen la configuración de implementación actual de Vercel, crean el proyecto e implementanlo en Vercel. El token utilizado para la autenticación con Vercel se extrae de las variables de entorno CI/CD de GitLab ($VERCEL_TOKEN para vista previa y $VERCEL para producción).

Producción en Vercel:

Pero error en etapa deploy_production

Mietras que la semana pasada me desplegué con éxito

Conclusión:

De esta práctica prácticamente aprendemos el control de versiones de gitlab y cómo trabajar entre diferentes ramas, lo complicado es implementar en Vercel mientras hago un nuevo token con el nombre de VERCEL y copiar la clave y la pego en mi proyecto en Settings>CI/CD>Variables>add variable con el mismo nombre VERCEL pero aparece un error mientras mi web en Pages y mkdocs funciona correctamente.