Dentro de AWS hay un servicio dentro de la seccion de codigo para el despliegue continuo
Se tendria que montar el codigo en aws codecommit y por medio de aws codepipeline se crea la tuberia para distribuir el codigo
Bienvenida
Desarrollo y Despliegue con Serverless Framework en AWS
Implementación de Serverless en AWS: API Gateway, Lambda y DynamoDB
Conceptos Claves
Ecosistema Serverless y Serverless Framework en AWS
Ventajas y desventajas de servicios y framework serverless
Explicación de Serverless Framework
Integración de Serverless Framework en AWS
Configuración de Entorno de Desarrollo Serverless en Windows
Preparación de entorno local con Serverless Framework en macOS
Serverless YAML: Estructura y Uso en Frameworks Cloud
Ecosistema Serverless en AWS
Creación y despliegue de una aplicación serverless básica
Creación y Gestión de Aplicaciones con Serverless Framework
Pruebas de Funciones Lambda en Local con Serverless Framework
Desarrollando con Serverless Framework
Creación y Configuración de CRUD Serverless con DynamoDB
Configuración y uso de DynamoDB Local con Serverless
Despliegue de Aplicaciones Serverless con DynamoDB en AWS
Inserción de Usuarios en DynamoDB con Funciones Lambda
Actualización de Usuarios en DynamoDB con Serverless Framework
Función Lambda Delete en Python para DynamoDB Serverless
Integración de AWS Free Tier con Serverless Framework
Bonus
Configuración de AWS Budgets para Control de Costos
Integración de GitHub Actions con AWS para CI/CD Serverless
Despliegue Automático con GitHub Actions y Serverless Framework
Optimización de Despliegue y Tamaño en AWS Lambda
Cierre del curso
Eliminación de Recursos y Claves en AWS con Serverless Framework
Proyecto Serverless Avanzado en AWS
Crea tus API’s con Serverless Framework y ChatGPT
Creación de APIs con Serverless Framework y ChatGPT
No tienes acceso a esta clase
¡Continúa aprendiendo! Únete y comienza a potenciar tu carrera
Si ya tienes una cuenta,
Despliegue Automático con GitHub Actions y Serverless Framework
21/25Recursos
¿Por qué es importante sincronizar un equipo remoto en el despliegue de aplicaciones serverless?
Trabajar en equipo, sobre todo de forma remota, implica ciertos desafíos técnicos y organizativos. Uno de los aspectos cruciales en el desarrollo de software es asegurar que todos los miembros del equipo pueden realizar despliegues sin conflictos o errores. Automatizar el proceso de integración y despliegue continuo (CI/CD) permite que el código se compile, pruebe y despliegue de manera eficiente en cualquier ambiente.
La implementación del framework Serverless en los despliegues ayuda a manejar aplicaciones en la nube de manera sencilla, utilizando solo un comando: serverless deploy. Sin embargo, es clave un sistema automatizado como GitHub Actions para garantizar que cada miembro del equipo pueda operar independientemente, sin necesidad de compartir acceso a computadoras específicas.
¿Cómo se integra GitHub Actions para soluciones CI/CD?
GitHub Actions permite automatizar flujos de trabajo directamente desde el repositorio de GitHub. Un flujo de trabajo típico con GitHub Actions para aplicaciones serverless incluiría:
- Configuración de workflows: Se define un archivo YAML en la carpeta
.github/workflows. Por ejemplo, el archivoDeployDevejecutará un flujo de trabajo cuando haya un pull request hacia la rama principal (main). - Creación de ramas y pull requests: Establecer estas prácticas asegura que los cambios se revisen y validen antes de ser integrados. Un pull request es vital para iniciar los workflows en GitHub Actions.
- Configuración de jobs para pruebas y despliegue: Los workflows pueden incluir jobs o tareas para realizar pruebas del código antes del despliegue. Aunque las pruebas no fueron añadidas en este ejemplo, es una buena práctica conversar con el equipo de QA para implementarlas a futuro.
- Uso de caché: Configurar el caché de dependencias es esencial para ahorrar tiempo y recursos durante los despliegues.
- Ejecutar despliegues automáticos: Tras validar los cambios, una acción en el repositorio ejecuta automáticamente el despliegue en el entorno apropiado.
¿Qué papel juegan los secretos y el caché en GitHub Actions?
En proyectos que utilizan servicios externos, como AWS, es fundamental manejar secretos para autenticar y realizar operaciones seguras. GitHub Actions permite gestionar esta información sensible mediante la sección de configuraciones de secretos.
- Manejo de secretos: Se deben crear variables secretas como el
AWS Access Key IDy unGitHub Tokenautomático, esencial para asegurar interacciones seguras y sin intervención manual. - Uso de caché: Establecer el caché en GitHub Actions ayuda a reducir el tiempo de despliegue. Cuando las dependencias ya han sido descargadas, el sistema valida un "cache hit", evitando instalaciones redundantes.
¿Cuáles son las mejores prácticas para utilizar GitHub Actions en despliegues serverless?
Al usar GitHub Actions en entornos serverless, es importante:
- Incluir pruebas antes de despliegues: Verificar que el código funcione correctamente antes de lanzarlo a producción es crucial.
- Reutilizar dependencias: Utilizar dependencias previamente descargadas para optimizar tiempo y recursos.
- Implementar múltiples ambientes: Aunque en este caso solo se utiliza un ambiente de desarrollo (dev), planificar para diferentes entornos es una buena práctica.
- Monitorear costos: GitHub Actions cobra por minuto de tiempo de ejecución, por lo que optimizar procesos para ahorrar segundos puede ser beneficioso económicamente.
Este tipo de configuración no solo facilita el despliegue de aplicaciones sino que prepara a los equipos para colaborar eficientemente, independientemente de su ubicación. ¡Esperamos que esta guía te inspire a seguir explorando y aprendiendo más sobre CI/CD y el uso de herramientas como GitHub Actions en tus proyectos!
Aportes 6
Preguntas 3
Ordenar por:
La clase anterior esta bugueada, no la pude ver:
Tampoco ésta al inicio del curso:
Tengo este proyecto con Typescript, prettiier y demas herramientas vistas en el curso
https://github.com/carlosdizx/crud-users-with-serverless
Excelente bonus, creo que realmente le da un valor agregado al curso.
En caso de que hayas recibido el siguiente mensaje, al hacer el deploy:
Run thollander/[email protected]
Error: Resource not accessible by integration
en el step de:
- name: Comment Pull Request
uses: thollander/[email protected]
with:
message: |
Your SLS App was deployed!
Awesome :D
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
Tienes que agregar lo siguiente tal y como lo dice la documentacion oficial, del package, nuestro job quedaria de la siguiente manera:
si te das cuenta lo unico que estoy agregando es la parte de permissions, despues del nombre del job
deploy-env:
permissions:
pull-requests: write
name: Deploy Lambda
runs-on: ubuntu-latest
needs: testing-changes
steps:
- uses: actions/[email protected]
- name: NPM - Load cached venv
id: cached-npm-dependencies
uses: actions/cache@v2
with:
path: node_modules
key: npm-${{ runner.os }}-${{ hashFiles('**/package.json') }}
- name: NPM - Install dependencies
if: steps.cached-npm-dependencies.outputs.cache-hit != 'true'
run: 'npm install'
- name: Deploy using sls
run: 'npx sls deploy'
env:
AWS_ACCESS_KEY_ID: ${{secrets.AWS_ACCESS_KEY_ID}}
AWS_SECRET_ACCESS_KEY: ${{secrets.AWS_SECRET_ACCESS_KEY}}
- name: Comment Pull Request
uses: thollander/[email protected]
with:
message: |
Your SLS App was deployed!
Awesome :D
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
una nota de curso, me gustó mucho!
¿Quieres ver más aportes, preguntas y respuestas de la comunidad?