Despliegue a Producción: Tipos, Riesgos y Mejores Prácticas

แชร์
ฝัง
  • เผยแพร่เมื่อ 9 พ.ย. 2024

ความคิดเห็น • 9

  • @NetMentor
    @NetMentor  3 หลายเดือนก่อน +4

    twitter: x.com/NetMentorTW
    Blog: www.netmentor.es/entrada/errores-en-despliegues
    Guía completa de desarrollo full stack con .NET: www.netmentor.es/libros/guia-completa-desarrollo-full-stack

  • @YeniceiRoyeroLopez
    @YeniceiRoyeroLopez 3 หลายเดือนก่อน +1

    Excelente tema, soy dev pero con perfil de devops y actualmente hacemos despliegue blue/green.
    Siempre he tenido la duda cómo manejar la base de datos al hacer despliegues gradual o canary.
    Existe algún patrón, estrategia o algo similar que me ayude con este tipo de despliegue?
    Mil gracias

    • @NetMentor
      @NetMentor  3 หลายเดือนก่อน

      depende un poco de lo que quieras, si quieres incluir un nuevo campo, se hace un despliegue, normalmente rolling (desde mi experiencia) y cuando acaba se puede desplegar la app.
      Si lo que buscas es cambiar una columna existente lo que tienes que hacer es tener tanto la columna vieja como la nueva funcionado durante un tiempo y cuando puedes garantizar de que todo funciona con la nueva columna haces otro despliegue para quitar la vieja.
      en dbs no vas a poder hacer blue green, pero si vas a poder hacer rolling o canary sin problemas y sería lo ideal.
      En empresas pequeñas la BBDD va a tener una instancia, asi que un despliegue será suficiente.
      un saludo

  • @wilsonmori949
    @wilsonmori949 3 หลายเดือนก่อน

    Hay muchas empresas que hoy en dia hasta usan el famoso metodo de "aprobado por Chayanne". Basicamente autoaprobaciones sin una revision de pares minima.

  • @luisalamo2658
    @luisalamo2658 3 หลายเดือนก่อน

    Hay empresas grandes que aplican “you built it, you owned it” lo que significa que no hay un proceso de QA, un rol separado solo para eso

    • @NetMentor
      @NetMentor  3 หลายเดือนก่อน

      "you built it, you owned it" no significa que te comas el proceso de calidad, significa que cada equipo tiene que hacerlo y ser responsable.

  • @j0seant
    @j0seant 3 หลายเดือนก่อน

    El problema es cuando despliegas drivers (que tienen el máximo privilegio en el sistema) sin hacer pruebas suficientes, que la puedes liar bien, el resto del software no tiene tanto privilegio como para tumbar las maquinas..

  • @a0z9
    @a0z9 3 หลายเดือนก่อน

    Si despliegan y haces un crowdstrike te suben el sueldo o te echan.todo dependerá del día de la semana

  • @m3mbrillo_
    @m3mbrillo_ 3 หลายเดือนก่อน +1

    Concuerdo con todo. Pero sigo sosteniendo, desplegar los viernes no esta mal. Esta mal que se tenga miedo, por que significa que sabes que el pipeline o proceso no es seguro y no se le esta poniendo foco en solucionarlo.
    No tener miedo de deployar un viernes significa que tus pipelines y procesos aseguran un sistema solido como una roca.