Introducción

1

Lo que aprenderás sobre DevOps con GitLab

2

¿Qué es Devops?

3

El ciclo de vida del Devops

4

Introducción a Gitlab

5

Gitlab vs Github

Administración

6

Autenticación

7

Grupos

8

Autorización

9

Auditoría

10

Proyectos

Planificación

11

Tipos de desarrollo

12

Planificación en Gitlab-Issues

13

Planificación en Gitlab-Etiquetas

14

Planificación en Gitlab-Pesos

15

Planificación en Gitlab-Milestones

16

Planificación en Gitlab-Boards

17

Planificación en Gitlab-Service Desk

18

Planificación en Gitlab-Quick actions

Verificación

19

Inicialización del repositorio

20

Merge requests

21

Profundizando en Merge requests

22

Continuous Integration-CI

23

Gitlab CI

24

Automatizacion con GitLab Cl

25

Validacion de la configuracion con GitLab Cl

26

gitlab-ci.yml

27

Gitlab pages

28

Implementando Gitlab pages

29

¿Qué es el Desarrollo Ágil?

30

Gitlab autodevops

31

Implementando GitLab autodevops

32

Habilitando autodevops

Empaquetación

33

Gitlab container registry

34

Introducción a contenedores

Seguridad

35

Introducción a DevSecOps

36

Firmas de seguridad

37

Pruebas estáticas de seguridad

38

Escaneo de contenedores

39

Escaneo de dependencias

40

Pruebas dinámicas de seguridad

41

Gitlab security dashboard

Distribución

42

Continuous Delivery (CD)

43

Ambientes

44

Review apps

45

Estrategias de Distribución

46

Feature Flags

47

Rollback

Monitoreo

48

¿Por qué monitorear?

49

Métricas de desempeño (performance metrics)

50

Métricas de salud (health metrics)

51

Metricas de equipo

52

Rastreo de errores

Conclusiones

53

¿Por qué desarrollar con Gitlab?

Aún no tienes acceso a esta clase

Crea una cuenta y continúa viendo este curso

Continuous Delivery (CD)

42/53
Recursos

Aportes 14

Preguntas 1

Ordenar por:

¿Quieres ver más aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesión.

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

En mi trabajo son manuales aún, pero es mi propósito y deber automatizar el proceso.

Yo configure un flightplan, y me anda bien. es semi automatico.
Basicamente configuras comandos para correr local y comandos para correr remoto.
(javascript)

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.

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!

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/

A pelo, 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.

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.