Continuous Deployment seguro con GitLab y control de riesgos
Contenido del curso
John Henry Villamil Cardona
Wilowayne De La Cruz
Willinson Ipia velasco
Alexis Otaño
Cristhian Pinto
Ricardo Portillo
Edwin Garcia
Jose Almenarez
Eduard Leandro Correa Avendano
Yojan Antonio Pardo Zabala
Ricardo Antonio Rodriguez Valdez
Christian Irack Flores Maldonado
Julio Castañeda
Pablo Aquino
Omar D
Esteban Martini
Alex Camacho
ProfesorPablo Aquino
Alfredo Olmedo
Julio Enrique López Marin
Company_admin
Eddie Andres Rios Elgueta
Eduardo Adrian Giorgio
Omar D
Santiago Cano Garcés
Actualmente en mi trabajo lastimosamente los despligues son totalmente manuales por medio de git y es algo que quiero y voy a cambiar lo mas pronto posible. algun concejo de como incomporar una aplicacion existente en este proceso
Si el proyecto no fue desarrollado bajo el estándar TDD es sumamente dificil, pues tendrás que refactorizar muchas cosas.
Es dificil, pero no imposible.
Lo puedes realizar por medio de jenkins y no solamente te sirve para gitlab, sino tambien para muchos mas otros proyectos.
Yo configure un flightplan, y me anda bien. es semi automatico. Basicamente configuras comandos para correr local y comandos para correr remoto. (javascript)
En mi trabajo son manuales aún, pero es mi propósito y deber automatizar el proceso.
Yo tambien estoy pensando lo mismo. Pero tendre que estudiar un poco la parte de como instalar el servidor de kubernet ya que todo esta instalado en un datacenter
En donde trabajo utilizamos gitlab en un servidor privado, pero no utilizamos todas las funcionalidades, hacemos el despliegue en docker swarm con gitlab, pero todos es prácticamente manual.
En la empresa hacemos los deployments usando Jenkins para los proyectos modernos.
En mi empresa tenemos varios activos digitales, los modernos tienen implementado CD automático usando GitHub, Jenkins y AWS. Pero hay casos de Activos Digitales grandes que tienen partes que requieren aprobación manual de un Release Manager. También es importante analizar el tema de los pasos a producción cuando intervienen cambios en la Base de Datos, dado que los ambientes productivos son accedidos solo por los DBAs. Para este caso se recomienda herramientas como Liquibase.: https://www.liquibase.org/
Una vez trabajé en un lugar donde el deployment se hacía por medio de un FTP, allí se ponían los archivos con Ctrl+C y Ctrl+V, intenté decirles que había mejores maneras pero decidieron seguir así...
Los desarrolladores, lo hacen manualito, yo, lo hago con docker semi-automatico, buscando la forma para automatizar todo :p pero con estos conocimientos que aun me toca profundizar y practicar veo que lo lograre!
A pelo, en AWS.
Hola Cristianirack. Puedes contar ¿Cómo lo trabas en AWS?
En la empresa donde laboro, por ahora los procesos de deploy son manuales, aunque ya he introducido docker para ciertas aplicaciones y scripts de deploy, pero el objetivo es usar una herramienta como gitlab para realizar la automatización de este proceso.
Te deseo mucho éxito, nosotros ya hemos implementado algunas aplicaciones de algo monolítico a microservicios y llevando casi todo a la automatización haciendo uso de GitOps, y comenzamos a aplicar filosofía SRE, seguridad, penetration testing pero hemos detectado que hay aun mucho camino por recorrer.
me surgen algunas dudas:
los entornos de stagging y produccion, se generan automaticamente?
gitlab se encarga de generar namespaces diferentes para estos entornos en nuestro cluster y los corre ahi?
todo nuestro repositorio, se transforma en un solo pod?
alguna documentacion sobre como es este proceso?
Hola,
GitLab tiene su propia documentación al respecto, te la dejo por aquí.
En autodevops, al estar integrado con kubernetes, gitlab generá los nuevos ambientes de staging de acuerdo a la definición del .gitlab.yml
Dependiendo del SLA, SLO y SLI
Donde trabajo se hacen despliegues manuales.
Realiza la propuesta de cambiar a un modelo como el enseñado y crea un prototipo para el jefe con una pequeña explicación de como podría ayudar a la empresa, quizá ganes un aumento, quizá no te tomen en cuenta... pero al menos quedará una buena impresión.
Actualmente son todos manuales. Pero como estamos en la migración a la nueva versión de la plataforma va a ser necesario continuos delivery.
En el mundo de los SRE se manejan presupuestos de error (error budget) que permiten tener errores cada determinado tiempo, como dice @David una vez consumido ese presupuesto de error se puede entrar en un estado de alerta SRE para dejar todo a un lado y regresar al estado deseado el servicio.
Actualmente realizamos toda la ejecución automática de todas las tareas en el pipeline en ambientes de desarrollo y qa. Para producción hay un paso de aprobación manual, el despliegue sobre kubernetes se realiza utilizando las estrategias que este ya trae por defecto como Ramped, Canary Release o Blue/Green.
