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?

Estrategias de Distribuci贸n

45/53

Lectura

Uno de los temas que m谩s ha cambiado en los 煤ltimos a帽os en el mundo de la Ingenier铆a de Software es la velocidad a la que se distribuyen cambios en nuestros aplicaciones. Los equipos de desarrolladores distribuyen cambios m谩s temprano y m谩s r谩pido que antes. Mientras que antes los ciclos naturales tomaban meses o a帽os, hoy en d铆a los cambios suceden varias veces al d铆a. Los beneficios son claros:

  • El tiempo requerido para comercializar productos o servicios se disminuye dr谩sticamente.
  • Los clientes obtienen el valor del producto en menos tiempo.
  • La retroalimentaci贸n de los clientes tambi茅n fluye a velocidades aceleradas, lo que permite al equipo de desarrollo iterar de manera m谩s r谩pida.
  • La moral del equipo aumenta, pues pueden ver el fruto de su trabajo en producci贸n.

Sin embargo, no todo es felicidad. Con este tipo de estrategias aceleradas, existe un mayor riesgo de introducir cambios que pueden afectar negativamente la experiencia del usuario; o peor a煤n, traer downtime a nuestro sistema. Por eso, es importante incluir pr谩cticas que permitan minimizar el riesgo de que lo anterior se materialice.

Big bang deployment
Como lo sugiere su nombre, los despliegues de Big Bang, actualizan todas las partes del sistema en una sola barrida. Esta estrategia encuentra sus or铆genes en los d铆as en que el software se distribu铆a en medios f铆sicos y el cliente lo instalaba manualmente en su m谩quina.

Este tipo de despliegues requieren que el negocio ejecute una enorme cantidad de pruebas durante una fase espec铆fica del desarrollo, antes de aprobar el despliegue. Este tipo de pruebas, normalmente se asocian con el modelo waterfall en el que el desarrollo se ejecuta en etapas secuenciales.

Las aplicaciones modernas tienen la ventaja de poderse actualizar autom谩ticamente, en el cliente o el servidor, por lo que este tipo de estrategias han sido casi completamente abandonadas por equipos que siguen las metodolog铆as 谩giles.

Rolling deployment
Los rolling deployments, o despliegue en fases, tienen la ventaja de mitigar algunas de las desventajas de los big bang deployments. Esto es as铆, porque disminuye el riesgo de downtime al desplegar la aplicaci贸n a lo largo del tiempo.

Es importante resaltar que el despliegue consiste en reemplazar una versi贸n de la aplicaci贸n con otra en fases; de tal manera que existe un tiempo en el que ambas aplicaciones pueden existir. En el caso de un despliegue a Kubernetes, por ejemplo, el reemplazo consiste en destruir el contenedor con la versi贸n anterior y descargar la 煤ltima versi贸n de la imagen desde el container registry en el cual la alojemos.

Y es aqu铆 donde se alcanza a ver otra ventaja de contenerizar nuestra aplicaci贸n: que los rollbacks resultan ser muy sencillos, cuando antes (en el modelo del Big Bang) resultaban imposibles. Hacer rollback es tan s贸lo destruir de nueva cuenta el pod, y descargar la versi贸n previa (o cualquier otra versi贸n que queramos) desde nuestro container registry.

Blue Green deployment
Esta estrategia, tambi茅n conocida como A/B deployment, consiste en tener dos ambientes de producci贸n paralelos (uno llamado blue y el otro llamado green) en el cual se despliegan las nuevas versiones de las aplicaciones de manera alternativa. Es decir, si blue tiene instalada la V1 de nuestra aplicaci贸n, entonces green tendr谩 instalada la V2, y cuando se despliegue se la siguiente versi贸n (V3) se utilizar谩 el ambiente blue, nuevamente. 驴D贸nde se desplegar谩 el ambiente V4? En green, por supuesto; y la secuencia alternativa contin煤a indefinidamente.

Una de las ventajas de esta estrategia es que facilita realizar un rollback a la versi贸n anterior, de manera sencilla, cuando nuestra aplicaci贸n no se encuentra habilitada para trabajar dentro de contenedores. En caso de que exista una falla en la nueva versi贸n, simplemente se rutea al ambiente previo.

Es importante mencionar, que 煤nicamente el ambiente de la capa de la aplicaci贸n se replica. Las bases de datos, al igual que el almacenamiento de archivos binarios (fotos, im谩genes, v铆deos, por ejemplo), son compartidas por ambos ambientes.

Existe otra modalidad de los despliegues blue green que se conoce como canary deployment. El canary deployment en lugar de rutear todo el tr谩fico de inmediato, se utiliza una aproximaci贸n incremental. Es decir, se comienza a rutear a la nueva versi贸n progresivamente. Por ejemplo, 25% 50% 75% 100% 贸 33% 66% 100%, etc.

Una de las ventajas de adoptar esta estrategia es que se puede probar la nueva versi贸n con un subconjunto de los usuarios para determinar si se encuentra estable, y en caso de confirmarse, se rutea todo el tr谩fico al ambiente green o blue.

Distribuci贸n en Gitlab
En Gitlab, cuando utilizamos AutoDevOps, podemos configurar nuestra estrategia de despliegue a trav茅s de opciones predeterminadas en el UI o a trav茅s de variables de ambiente de Gitlab CI.

Las variables que podemos configurar son las siguientes:
STAGING_ENABLED activa el ambiente staging cuando se le asigna el valor 1.
CANARY_ENABLED activa el ambiente canary cuando se le asigna el valor 1.
INCREMENTAL_ROLLOUT_MODE define la forma en el que el despliegue incremental se realizar谩. Acepta los valores manual y timed.

Este es el resultado de la algunas combinaciones de configuraci贸n:

Sin la declaraci贸n de INCREMENTAL_ROLLOUT_MODE ni STAGING_ENABLED.
Captura de Pantalla 2019-04-05 a la(s) 17.02.37.png

Sin la declaraci贸n de INCREMENTAL_ROLLOUT_MODE, pero con STAGING_ENABLED asignado el valor de 1.
Captura de Pantalla 2019-04-05 a la(s) 17.05.04.png

Con INCREMENTAL_ROLLOUT_MODE en modo manual, y sin STAGING_ENABLED.
Captura de Pantalla 2019-04-05 a la(s) 17.05.20.png
Con INCREMENTAL_ROLLOUT_MODE en modo manual, ySTAGING_ENABLED asignado el valor de 1
Captura de Pantalla 2019-04-05 a la(s) 17.05.33.png

Para modificar la opci贸n de despliegue a trav茅s de la UI, navega a Settings > CI/CD > Auto DevOps y selecciona una de la siguientes opciones:

  • Continuous deployment to production: Habilita el despliegue continuo del branch master al ambiente de producci贸n.
  • Continuous deployment to production using timed incremental rollout: Asigna el valor timed a la variable de Gitlab CI INCREMENTAL_ROLLOUT_MODE. Esto significa que el despliegue se realizar谩 cada vez que existe un cambio en el branch master, pero de manera incremental en lapsos de 5 minutos.
  • Automatic deployment to staging, manual deployment to production: Asigna el valor de 1 a la variable STAGING_ENABLED y el valor de manual a la variable INCREMENTAL_ROLLOUT_MODE. El resultado es que la rama master se despliega de manera continua al ambiente de staging, y se activan las acciones manuales para el despliegue a producci贸n.

Aportes 9

Preguntas 1

Ordenar por:

驴Quieres ver m谩s aportes, preguntas y respuestas de la comunidad? Crea una cuenta o inicia sesi贸n.

Muchas informaci贸n muy interesante, falta ponerlo mas en practica鈥

Excelente Informaci贸n

Excelente explicacion!!

Explicaci贸n mucho muy digerible!!

Muchas gracias!

Buen aporte.

Muchas gracias por compartir esta informaci贸n. Me gusto bastante la estrategia de Blue Green deployment, si me maneja correctamente los usuarios pr谩cticamente no notaran los tiempos de ca铆das para las actualizaciones, ya que solo depender谩 del cambio del enrutamiento de los DNS.

Excelente Documentaci贸n鈥!

Genial siento que hoy aprend铆 algo nuevo.