Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Azure DevOps Pipelines para Power Platform: despliegues fiables con service principals, validación y rollback (Doblaje IA)

Transcript

Azure DevOps Pipelines para Power Platform: despliegues fiables con service principals, validación y rollback (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Listo para 10 días de Microsoft 365, Copilot y Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del trabajo.
0:06
Speaker 2: Este enero, M365 con regreso y venimos con más fuerza.
0:12
Speaker 2: Únase a nosotros para sesiones en vivo, demostraciones reales y
0:15
Speaker 2: conocimientos prácticos de MVP y expertos de la industria de
0:17
Speaker 2: todo el mundo. Nada de diapositivas genéricas, nada de palabras demonables.
0:22
Speaker 2: Abordaremos desafíos reales. Copilot Studio, agentes de IA, Fabric, Seguridad,
0:26
Speaker 2: Gobernanza y Automatización. Ya sea usted un profesional de TI,
0:31
Speaker 2: desarrollador o líder empresarial, hay sesiones diseñadas para usted. Con
0:35
Speaker 2: 10 días completos, podrá explorar múltiples tecnologías y conectar con
0:39
Speaker 2: una comunidad global. Véalo en vivo y lleve información práctica
0:43
Speaker 2: de vuelta a su organización. Enero de 2027. 10 días.
0:48
Speaker 2: Una comunidad de Microsoft. Las inscripciones ya están abiertas. Visite m365com.net
0:52
Speaker 2: y asegure su lugar hoy mismo. Eso es m365com.net. Únase
1:01
Speaker 2: ahora en m365con.net y nos veremos en vivo en enero.
1:05
Speaker 3: Alguna vez siente que implementar soluciones de Power Platform es
1:07
Speaker 3: un paso adelante y dos atrás? Si está cansado de
1:10
Speaker 3: ver que sus cambios en Dataverse fallan en QA o
1:12
Speaker 3: que las dependencias arruinen sus despliegues, este video es para usted.
1:16
Speaker 3: Hoy analizaremos el pipeline de Azure DevOps componente por componente
1:19
Speaker 3: para que sus despliegues funcionen como una máquina bien engrasada,
1:22
Speaker 3: no como una apuesta.¿ Tiene curiosidad sobre cómo funciona realmente
1:26
Speaker 3: el rollback cuando la automatización se complica? Vamos a revelar
1:28
Speaker 3: lo que la documentación nunca le dice. Despliegues manuales frente
1:31
Speaker 3: a pipelines automatizados, donde realmente comienza el problema. Si trabaja
1:35
Speaker 3: con Power Platform, probablemente haya tenido ese momento. Horas ajustando
1:39
Speaker 3: una aplicación basada en modelos, perfeccionando un flujo de Power Automate,
1:42
Speaker 3: configurando cuidadosamente roles de seguridad, toda la lista de verificación,
1:46
Speaker 3: toda verificación. Ha verificado cada campo, hizo clic en exportar solución,
1:49
Speaker 3: subió su archivo zip y cruzó los dedos mientras que
1:51
Speaker 3: UA recibió una nueva compilación. Luego, justo cuando todos se
1:55
Speaker 3: preparan para una demostración o lanzamiento, algo falla. Una tabla
2:00
Speaker 3: no aparece. Un flujo se activa en el entorno equivocado,
2:02
Speaker 3: o peor aún, la importación falla con uno de esos
2:04
Speaker 3: códigos de error crípticos que solo significan que algo no coincidió.
2:10
Speaker 3: Sara se siente de repente más silencio. Esa familiar sensación
2:12
Speaker 3: de angustia aparece y toca volver a intentar encontrar qué falló,
2:16
Speaker 3: dónde y por qué. Esta es la realidad diaria de
2:19
Speaker 3: los equipos que dependen de despliegues manuales en Power Platform.
2:22
Speaker 3: Hace malabares exportando soluciones a su escritorio, moviendo archivos zip
2:25
Speaker 3: entre entornos, a veces usando una hoja de Excel antigua
2:27
Speaker 3: o un chat de Teams para registrar qué se movió
2:29
Speaker 3: y cuándo, para registrar qué se movió y cuándo. Si
2:32
Speaker 3: omite una personalización, tal vez una tabla nueva o una
2:34
Speaker 3: referencia de conexión para un flujo, su despliegue queda medio camino,
2:37
Speaker 3: pero totalmente roto. El clásico funciona en desarrollo, pero QA
2:41
Speaker 3: no tiene idea de lo que acaba de enviar. Ahora
2:43
Speaker 3: todos están en Slack o Teams tratando de averiguar qué
2:46
Speaker 3: falta o quién exportó la última versión real de la aplicación.
2:49
Speaker 3: Las implementaciones manuales son más frágiles de lo que los
2:51
Speaker 3: equipos esperan. No se trata solo de pasos omitidos. Te
2:54
Speaker 3: enfrentas a entornos que se desalinean silenciosamente tras semanas de cambios.
3:00
Speaker 3: En desarrollo, añaden un conector o permiso, pero nadie lo
3:03
Speaker 3: registra para la siguiente implementación. Quizás alguien ajusta los detalles
3:06
Speaker 3: del activador de un flujo, pero solo en desarrollo. Para
3:08
Speaker 3: cuando llegas a producción, hay un mosaico de desviaciones en
3:11
Speaker 3: la configuración. Incluso si intentas documentarlo todo, el error humano
3:14
Speaker 3: siempre encuentra la forma de aparecer Un cambio nocturno tras
3:17
Speaker 3: la reunión, un rol de seguridad pasado por alto o
3:19
Speaker 3: una variable de entorno migrada a mano. De repente persigues
3:22
Speaker 3: un problema que no era evidente hace dos días pero
3:25
Speaker 3: que ahora bloquea la adopción de los usuarios o corrompe
3:27
Speaker 3: datos en una integración crítica. Aquí hay una historia que
3:31
Speaker 3: probablemente te resulte familiar. Un flujo de Power Automate crítico
3:35
Speaker 3: para el negocio funcionaba a la perfección en desarrollo moviendo
3:37
Speaker 3: filas entre tablas de Dataverse usando nuevas referencias de conexión.
3:41
Speaker 3: Se exporta QA, la importación parece correcta pero no se
3:44
Speaker 3: activa nada. Tras horas de revisar registros y permisos, alguien
3:47
Speaker 3: se da cuenta de que el entorno de QI nunca
3:49
Speaker 3: tuvo la referencia de conexión correcta. No hay advertencias en
3:53
Speaker 3: la interfaz, nada se señaló en el paso de importación.
3:56
Speaker 3: Requería una inmersión profunda en capas de solución y dependencia
3:58
Speaker 3: de componentes. Y mientras tanto, el negocio tuvo un proceso
4:01
Speaker 3: interrumpido durante casi una semana. Microsoft menciona abiertamente este punto
4:06
Speaker 3: débil en su documentación, lo cual es casi tranquilizador, lo
4:08
Speaker 3: cual es casi tranquilizador. Incluso los administradores experimentados, quienes viven
4:12
Speaker 3: y respiran Dataverse, pierden el rastro de dependencias ocultas o
4:15
Speaker 3: diferencias sutiles entre entornos, o diferente entorno. Cosas que apenas
4:18
Speaker 3: tienen una línea en la documentación son, a menudo, lo
4:20
Speaker 3: que arruina una puesta en marcha. Estos no son errores
4:23
Speaker 3: de novato. Son las consecuencias de una plataforma flexible, pero
4:26
Speaker 3: llena de enlaces y dependencias internas. Cuando dependes de que
4:30
Speaker 3: las personas recuerden cada configuración, es solo cuestión de tiempo
4:33
Speaker 3: antes de que algo falle. La gran propuesta es la automatización.
4:37
Speaker 3: Azure DevOps aborda este problema, prometiendo convertir esos pasos manuales
4:41
Speaker 3: y propensos a errores en tuberías repetibles, trazables y, con suerte, infalibles.
4:47
Speaker 3: La idea se ve bien sobre el pocket. Conectas una tubería,
4:50
Speaker 3: le alimentas tu Power Platform y dejas que se encargue
4:52
Speaker 3: del trabajo pesado. La solución se exporta, se importa, se
4:56
Speaker 3: verifican las dependencias y, si algo falla, lo detectas de inmediato.
5:00
Speaker 3: Obtienes registros reales con marca de tiempo. Ya no hay
5:02
Speaker 3: que preguntarse si Alice o Bob tienen la última copia.
5:05
Speaker 3: Bien hecho, cada implementación está versionada y es rastreable hasta
5:08
Speaker 3: su origen. Se acabó la ruleta de dependencias y las
5:10
Speaker 3: sorpresas de último minuto. Y aquí está el número que
5:12
Speaker 3: a todos les gusta compartir en las presentaciones. Los equipos
5:15
Speaker 3: que pasan de procesos manuales a flujos automatizados ven ciclos
5:18
Speaker 3: de retroalimentación que no solo son más rápidos, sino que
5:21
Speaker 3: realmente evitan la mayoría de los despliegues fallidos. Claro, los
5:24
Speaker 3: errores siguen ocurriendo, pero se detectan a tiempo y no
5:26
Speaker 3: pasas horas tratando de descifrar qué salió mal o qué
5:29
Speaker 3: salió mal. Lo más importante aún obtienes capacidad de tutorial.
5:31
Speaker 3: Puedes rastrear cada despliegue, saber exactamente quién envió qué y, sí,
5:35
Speaker 3: identificar dónde y cómo falló algo. Pero la realidad es
5:38
Speaker 3: que esto se trata de confianza, no solo de velocidad.
5:41
Speaker 3: Si tu equipo no puede confiar en el proceso de despliegue,
5:42
Speaker 3: si cada lanzamiento parece una apuesta, entonces cada buena función
5:45
Speaker 3: que creas está en riesgo. Las partes interesadas dudan de
5:48
Speaker 3: la lista de lanzamiento. Los usuarios se frustran por las
5:50
Speaker 3: interrupciones o la falta de función. La promesa de una
5:52
Speaker 3: innovación rápida y código bajo se desvanece cuando la última
5:55
Speaker 3: milla sigue siendo poco confiable. La automatización no se trata
5:59
Speaker 3: solo de ahorrar tiempo o impresionar a la gerencia adoptando DevOps.
6:03
Speaker 3: Es la única forma realista de entregar soluciones de Power
6:05
Speaker 3: Platform que funcionen igual cada vez en todos los entornos. Entonces,
6:10
Speaker 3: con flujos automatizados obtienes previsibilidad. Obtienes un registro confiable de
6:14
Speaker 3: cada tendencia de despliegue y cada paso realizado. Un verdadero
6:18
Speaker 3: 6D para Power Platform se vuelve posible y la resolución
6:20
Speaker 3: de problemas se reduce a registros, no a suposiciones. Por supuesto,
6:25
Speaker 3: nada de esto sucede por arte mágico. La automatización es
6:27
Speaker 3: tan fuerte como los enlaces entre tu flujo y tus entornos.
6:30
Speaker 3: Ahí es donde las cosas todavía pueden salir mal. Así que,
6:34
Speaker 3: a continuación, hablemos de conectar a Azure DevOps, a tu
6:37
Speaker 3: Power Platform, de una manera estable, segura y que no
6:40
Speaker 3: se rompa a las 3 de la mañana. El pegamento,
6:44
Speaker 3: las conexiones de servicio y los grupos de agentes que
6:46
Speaker 3: no fallan. Si has intentado conectar Azure DevOps a Power
6:50
Speaker 3: Platform y ves que el flujo arroja un error de
6:52
Speaker 3: permisos al instante o simplemente se queda colgado por lo
6:55
Speaker 3: que parece una eternidad, no eres el único. Casi todos
6:58
Speaker 3: los equipos chocan con este muro en algún momento. El
7:01
Speaker 3: flujo podría estar hermosamente diseñado. Tu YAML podría ser impecable,
7:05
Speaker 3: pero con una sola conexión de servicio mal configurada o
7:08
Speaker 3: un ajuste de gente faltante, te verás enfrentando errores de
7:11
Speaker 3: autenticación o preguntándote por qué nada comienza nunca. La realidad
7:14
Speaker 3: es que Los despliegues de Power Platform dependen totalmente de
7:17
Speaker 3: lo que sucede detrás de escena, lo que me gusta
7:19
Speaker 3: llamar la tubería invisible. Estamos hablando de conexiones de servicio,
7:22
Speaker 3: flujos de autenticación, grupos de agentes y esos pequeños ajustes
7:25
Speaker 3: que mantienen todo unido silenciosamente o arruinan tu diada sin aviso.
7:29
Speaker 3: Seamos honestos, el concepto parece engañosamente simple. Creas una conexión
7:34
Speaker 3: de servicio en Azure DevOps, le das unas credenciales, la
7:36
Speaker 3: apuntas a tu entorno y vuelves a construir tus flujos.
7:41
Speaker 3: Sin embargo, bajo el capó es una red de permisos,
7:43
Speaker 3: tokens y apretones de manos de API, API Si pierdes uno,
7:47
Speaker 3: podrías romper no solo tu canalización, sino potencialmente la integración
7:50
Speaker 3: subyacente de todos los demás que usan el mismo director
7:52
Speaker 3: de servicio. Esto no es solo teórico. He visto equipos
7:55
Speaker 3: trabajar a la perfección durante meses solo para encontrarse con
7:58
Speaker 3: una implementación que se negaba a realizarse. Siempre se reduce
8:02
Speaker 3: algún detalle interno, un secreto expirado, un rol faltante en
8:05
Speaker 3: la cuenta de servicio o un alcance de permisos cambiado
8:08
Speaker 3: en Azure Active Directory. En el peor de los casos,
8:12
Speaker 3: puedes dejarte a ti mismo o a tu equipo fuera
8:14
Speaker 3: de los entornos si eres demasiado agresivo con las asignaciones
8:16
Speaker 3: de roles. Página de configuración. Finalmente obtienes aprobación para usar
8:20
Speaker 3: un director de servicio para tu canalización, buscando seguridad real
8:24
Speaker 3: y separación de funciones. Batería de sentido. Tienes una identidad
8:28
Speaker 3: por entorno y todo debería funcionar, pero llega el día
8:30
Speaker 3: de la implementación. Ejecutas tu canalización y falla en el
8:33
Speaker 3: primer paso de autenticación. Los mensajes de error son confusos.¿
8:37
Speaker 3: Revises los registros solo para descubrir que olvidaste una pequeña
8:40
Speaker 3: asignación de rol de Dataverse, una casilla de verificación y
8:43
Speaker 3: ahora tu agente no puede acceder al entorno? Por supuesto,
8:45
Speaker 3: los registros no mencionan esto. Solo devuelven un mensaje genérico
8:48
Speaker 3: de no autorizado, así que estás revisando el portal de
8:51
Speaker 3: Azure a las 11pm, cambiando permisos y esperando no romper
8:55
Speaker 3: algo más en el proceso. Es igual de frustrante que
8:58
Speaker 3: completamente evitable. Hay un patrón. Un permiso olvidado o una
9:03
Speaker 3: configuración no estándar pueden bloquear todo el proceso. Esta es
9:07
Speaker 3: la razón por la que la mejor práctica es usar
9:08
Speaker 3: un director de servicio dedicado. Y aquí está lo importante.
9:12
Speaker 3: No le asignes derechos de administrador en todas partes, solo
9:14
Speaker 3: por conveniencia. Asigna solo los roles mínimos de Dataverse necesarios
9:18
Speaker 3: para su entorno y tarea específica. Puede parecer excesivo si
9:22
Speaker 3: eres nuevo en DevOps, pero en el mundo real esto
9:24
Speaker 3: evita que alguien elimine o corrompa datos accidentalmente porque un
9:27
Speaker 3: director de servicio todopoderoso tenía acceso a todo. También significa
9:31
Speaker 3: que rotar claves o cambiar secretos es más limpio. Si
9:34
Speaker 3: necesitas revocar una conexión desde QA, no corres el riesgo
9:37
Speaker 3: de arruinar la producción. Los equipos que mantienen esta separación
9:41
Speaker 3: rara vez tienen el pánico de que todos los entornos
9:43
Speaker 3: se caigan. Ahora, hablemos de los grupos de agentes, porque curiosamente,
9:48
Speaker 3: suelen tratarse como algo secundario. Tienes dos opciones principales, agentes
9:52
Speaker 3: alojados por Microsoft y agentes auto-hospedados. La mayoría elige lo
9:56
Speaker 3: que viene por defecto en su proyecto de Azure DevOps
9:58
Speaker 3: y espera que simplemente... funcione. Para trabajos básicos de. NET
10:03
Speaker 3: o web, esto suele ser suficiente, pero con Power Platform
10:07
Speaker 3: eventualmente chocarás con una pared. Los agentes alojados por Microsoft
10:10
Speaker 3: son excelentes para tareas de compilación básicas, pero como se
10:12
Speaker 3: provisionan dinámicamente y se comparten, no puedes garantizar que todos
10:15
Speaker 3: los requisitos previos estén presentes. Como versiones específicas de las
10:19
Speaker 3: herramientas de compilación de Power Platform, módulos personalizados de PowerShell
10:23
Speaker 3: necesarios para tareas de solución complejas. Además, si necesitas software
10:26
Speaker 3: o integración personalizada, cualquier cosa que no esté en imagen
10:28
Speaker 3: estándar está sin problemas. Y buena suerte resolviendo fallos aislados
10:32
Speaker 3: en entornos que no te pertenecen. Los agentes auto hospedados
10:35
Speaker 3: te dan control total sobre el entorno, lo cual es
10:37
Speaker 3: una bendición y una maldición. Por un lado, puedes preinstalar
10:41
Speaker 3: herramientas de compilación, SDK, scripts, lo que sea que tu
10:44
Speaker 3: proyecto requiera. Si tienes conectores únicos o un conjunto estable
10:48
Speaker 3: de dependencias, esto puede ahorrarte mucho tiempo. Por otro lado,
10:52
Speaker 3: eres totalmente responsable de las actualizaciones de la máquina, los
10:54
Speaker 3: parches y de mantener a la gente en funcionamiento. Aún así,
10:58
Speaker 3: muchos equipos prefieren esta ruta, especialmente si su trabajo en
11:01
Speaker 3: Power Platform incluye muchos pasos de compilación personalizados o integraciones
11:04
Speaker 3: que no funcionan bien con las imágenes compartidas de Microsoft.
11:07
Speaker 3: Un consejo que se pasa por alto es ejecutar siempre
11:09
Speaker 3: una prueba en site. Prueba tu conexión de servicio y
11:11
Speaker 3: realiza una exportación de prueba antes de procesar algo importante
11:13
Speaker 3: a través de tu canalización. Que tu canalización diga que
11:16
Speaker 3: está conectada no significa que tenga el nivel de acceso
11:18
Speaker 3: adecuado para cada operación que deseas realizar.¿ Esa exportación de
11:21
Speaker 3: prueba es tu red de seguridad? Detectarás brechas de permisos,
11:24
Speaker 3: problemas de errores e incluso rarezas básicas de red antes
11:26
Speaker 3: de estar inmerso en una implementación de producción. Es mejor
11:29
Speaker 3: descubrirlo ahora que cuando estás compitiendo contra los plazos de lanzamiento.
11:32
Speaker 3: Así que lo que realmente quieres es fiabilidad sin sorpresas.
11:35
Speaker 3: Las conexiones de servicio duraderas y los grupos de agentes
11:37
Speaker 3: son la base de todo lo que viene después. Si
11:40
Speaker 3: te equivocas en esto, no importa cuán pulido sea tu
11:42
Speaker 3: YAML o cuán sofisticadas sean tus tareas de canalización, fallarán
11:45
Speaker 3: porque los conceptos básicos no están bien configurados. Una vez
11:49
Speaker 3: que dominas esta infraestructura invisible, el resto del proceso de
11:51
Speaker 3: canalización encaja con mucha menos tensión y mucha más previsibilidad.
11:57
Speaker 3: Los dolores de cabeza pasan de por qué nunca inició
11:58
Speaker 3: mi canalización a cómo hago mi canalización lo más inteligente,
12:02
Speaker 3: que es un problema mucho más divertido de resolver. Con
12:04
Speaker 3: esas conexiones estables y tu agente funcionando de manera fiable,
12:07
Speaker 3: acabas de superar el primer obstáculo real. pero una infraestructura
12:10
Speaker 3: sólida no garantiza la detección de problemas en la solución
12:12
Speaker 3: antes de que llegue a producción. A continuación, profundicemos en
12:15
Speaker 3: cómo las verificaciones automatizadas protegen tus entornos de errores silenciosos
12:18
Speaker 3: antes de que se propaguen. Barreras de seguridad automatizadas con
12:22
Speaker 3: probaciones de dependencias y validaciones previas a la implementación. Si
12:25
Speaker 3: alguna vez has visto una implementación de Power Platform pasar
12:27
Speaker 3: en desarrollo, cumplir con el trámite en control de calidad
12:30
Speaker 3: y luego activar alarmas en cuanto llega a producción, sabes
12:33
Speaker 3: hacia dónde se dirige esto. Los problemas casi nunca se
12:36
Speaker 3: anuncian con antelación. En su lugar, obtienes esas dependencias ocultas silenciosamente,
12:41
Speaker 3: esas que están a dos o tres clics de profundidad
12:43
Speaker 3: en una aplicación de lienzo o enterradas dentro de los
12:45
Speaker 3: subflujos de una aplicación basada en modelos. Para el desarrollo
12:48
Speaker 3: todo parece estar bien, pero la producción, con sus propios conectores,
12:51
Speaker 3: usuarios con diferentes licencias o una diferencia sutil en los
12:53
Speaker 3: roles de seguridad de Dataverse, encuentra el eslabón débil de inmediato. Ahora,
12:57
Speaker 3: la gente está entrando en pánico. A veces el único
12:59
Speaker 3: aviso que recibes es un usuario diciendo, oye, estos datos
13:01
Speaker 3: no se están actualizando. O un ticket de soporte como
13:03
Speaker 3: un seguimiento de errores que no ofrece nada útil. El
13:06
Speaker 3: problema es subyacente. Nadie verificó si todas las piezas móviles
13:08
Speaker 3: realmente sobrevivieron al traslado. Es por esto que las comprobaciones
13:11
Speaker 3: de dependencias y las validaciones previas a la implementación no
13:14
Speaker 3: son solo algo de ser. Son el sistema inmunológico de trabajo.
13:17
Speaker 3: Piénsalas como si viajaran antes de tu despliegue y alumbraran
13:19
Speaker 3: con una linterna todos los rincones donde a los problemas
13:21
Speaker 3: les encanta esconderse. Estas protecciones automatizadas detectan cosas como flujos
13:26
Speaker 3: secundarios faltantes, referencias de conexión ausentes o componentes no administrados
13:30
Speaker 3: que nunca se agregaron a tu exportación. Sin estas comprobaciones,
13:33
Speaker 3: cada despliegue es un acto de fe. Solo esperas que
13:36
Speaker 3: la infraestructura debajo de tu aplicación sea igual en cada
13:38
Speaker 3: entorno y solo te das cuenta de que no lo
13:40
Speaker 3: es cuando el informe de incidentes llega a tu bandeja
13:42
Speaker 3: de entrada. He visto esto suceder más veces de las
13:44
Speaker 3: que me gustaría admitir. Un proyecto tuvo una pesadilla recurrente,
13:47
Speaker 3: un flujo de Power Automate que funcionaba perfectamente en cada
13:50
Speaker 3: prueba de desarrollo, pero que desaparecía por completo al desplegarlo
13:52
Speaker 3: en producción.¿ Qué sucedió? Resultó que una solución rápida tenía
13:56
Speaker 3: un flujo secundario como dependencia, y el proceso de exportación
13:58
Speaker 3: no detectó que el flujo secundario estaba fuera de la
14:00
Speaker 3: solución administrada. Cuando ese flujo secundario no apareció en QA
14:04
Speaker 3: ni en producción, la lógica principal falló silenciosamente. Sin error,
14:09
Speaker 3: sin advertencia, solo un proceso que se apagó en silencio
14:11
Speaker 3: y usuarios confundidos sobre por qué sus tareas estaban repentinamente atascadas.
14:15
Speaker 3: Solo nos dimos cuenta después de que suficientes usuarios reportaron
14:17
Speaker 3: actualizaciones faltantes y alguien finalmente encontró el eslabón perdido. Para
14:21
Speaker 3: entonces se habían invertido horas revisando archivos XML de exportación
14:24
Speaker 3: y realizando comprobaciones manuales. Una dependencia pasada por alto causó
14:28
Speaker 3: un caos que podría haberse señalado con la protección adecuada
14:30
Speaker 3: en su lugar. Lo más sorprendente es lo prevenible que
14:33
Speaker 3: es esto ahora. Herramientas como el comprobador de soluciones en
14:36
Speaker 3: Power Platform te permiten configurar escaneos automatizados como un paso
14:39
Speaker 3: del proceso, dándote advertencias previas sobre problemas de capas de soluciones,
14:43
Speaker 3: dependencias faltantes, rendimiento de la aplicación e incluso recomendaciones de seguridad.
14:49
Speaker 3: Las herramientas de compilación de Power Platform para Azure DevOps
14:52
Speaker 3: acercan esto aún más a la realidad de CACD. Con
14:56
Speaker 3: el paso del proceso correcto estás haciendo mucho más que
14:58
Speaker 3: una simple importación o exportación. Estás ejecutando comprobaciones de validación
15:01
Speaker 3: tanto en la solución como en sus conexiones con el
15:03
Speaker 3: entorno de destino. Si tienes requisitos adicionales, los scripts personalizados
15:07
Speaker 3: de PowerShell te permiten profundizar aún más, escaneando variables de
15:12
Speaker 3: entorno necesarias, validando conexiones para APIs Premium o verificando ámbitos
15:16
Speaker 3: de permisos en flujos integrados con ADN. Lo interesante es
15:21
Speaker 3: ver cuánto detectan estas protecciones automatizadas en comparación con los
15:23
Speaker 3: antiguos métodos de exportar y cruzar los dedos. Los estudios
15:27
Speaker 3: de la comunidad indican que estas comprobaciones señalan hasta el
15:29
Speaker 3: 70% de los problemas antes de cualquier lanzamiento. Eso significa
15:33
Speaker 3: menos llamadas fuera de horario, menos sprints de emergencia para
15:36
Speaker 3: arreglar lo que se rompió y muchas menos reuniones incómodas
15:40
Speaker 3: explicando a la dirección por qué un lanzamiento falló. La
15:43
Speaker 3: propia investigación y los casos de estudio de Microsoft lo respaldan.
15:47
Speaker 3: Los equipos que aplican validaciones antes del despliegue ven una
15:49
Speaker 3: caída drástica en las fallas de producción y los problemas
15:51
Speaker 3: se detectan tan pronto que apenas se registran como incidentes.
15:54
Speaker 3: Un paso sólido en la canalización para esto es sencillo
15:56
Speaker 3: pero efectivo. Exporta tu solución desde el origen, pero antes
16:00
Speaker 3: de pensar en importarla al entorno de destino, inicia una
16:02
Speaker 3: secuencia que ejecute el verificador de soluciones y cualquier prueba
16:05
Speaker 3: personalizada que hayas añadido. No te detengas sobre la compilación.
16:09
Speaker 3: Ejecuta consultas contra el database de producción para asegurarte de
16:12
Speaker 3: que las entidades que vas a sobreescribir no tengan diferencias
16:14
Speaker 3: de esquema que causen un error silencioso. Valida las referencias
16:18
Speaker 3: de conexión. No asumes que todos los que tenían permisos
16:20
Speaker 3: en desarrollo y control de calidad tendrán el mismo rol
16:22
Speaker 3: en producción. Tener estos pasos en la canalización significa que
16:25
Speaker 3: el script falla pronto si falta algo y obtienes registros
16:28
Speaker 3: útiles que te indican exactamente dónde está el vacío. Estas
16:31
Speaker 3: comprobaciones automatizadas son la diferencia entre pasar el día creando
16:34
Speaker 3: funciones útiles y pasar la noche apagando fuegos de despliegues fallidos.
16:39
Speaker 3: No solo mantienen el entorno estable, sino que dan a
16:42
Speaker 3: todo el equipo la confianza de que los cambios en
16:44
Speaker 3: la canalización no se han saltado pasos cruciales ni dependencias
16:47
Speaker 3: de último minuto. Convierten el día del despliegue de algo
16:51
Speaker 3: tenso a algo rutinario. Cuando alguien pregunta,¿ terminó el despliegue?
16:56
Speaker 3: Puedes responder con algo más que un creo que sí,
16:58
Speaker 3: porque tienes las protecciones para demostrarlo. Es fácil descartar las
17:02
Speaker 3: comprobaciones previas al despliegue como otro requisito más, pero en
17:05
Speaker 3: el mundo de Power Platform ahorran más tiempo y prestigio
17:08
Speaker 3: que casi cualquier otra automatización. En lugar de trabajar a
17:12
Speaker 3: partir de interrupciones y quejas, recibes alertas proactivas, tempranas, procesables
17:16
Speaker 3: y vinculadas directamente a los componentes. Piensa en ellas menos
17:21
Speaker 3: como una red de seguridad y más como un sistema
17:22
Speaker 3: de radar. Por supuesto, incluso con las mejores protecciones, las
17:25
Speaker 3: cosas pueden salir mal. Nada es infalible y cada equipo
17:28
Speaker 3: necesita una forma de revertir los cambios cuando algo se escapa.
17:33
Speaker 3: Así que veamos cómo es un plan real de reversión
17:35
Speaker 3: y respaldo para Power Platform más allá de solo esperar
17:38
Speaker 3: que funcione el botón de deshacer. Cuando las cosas fallan,
17:42
Speaker 3: crear una estrategia real de reversión y respaldo. Hablemos de
17:46
Speaker 3: lo que realmente significa un rollback en Power Platform, porque
17:49
Speaker 3: es fácil asumir que hay un gran botón de deshacer
17:51
Speaker 3: esperando rescatarte cuando una implementación fracasa. Pero, a diferencia de
17:56
Speaker 3: los proyectos de código donde un rollback es solo un
17:58
Speaker 3: git reset o volver a desplegar un paquete, el mundo
18:00
Speaker 3: de Power Platform es mucho menos indulgente. No existe una
18:03
Speaker 3: opción nativa para revertir una implementación. Una vez que ocurre
18:06
Speaker 3: una importación, los cambios se integran en el entorno, las
18:09
Speaker 3: tablas pueden actualizarse, los componentes cambian de versión y las
18:11
Speaker 3: relaciones de datos pueden reorganizarse silenciosamente. Si algo falla durante
18:17
Speaker 3: la importación, el resultado podría ser una solución implementada a medias,
18:20
Speaker 3: integraciones rotas o usuarios bloqueados de las aplicaciones que necesitan.
18:24
Speaker 3: Los riesgos rara vez son obvios hasta que ocurren y
18:26
Speaker 3: para entonces la solución requiere mucha destreza. La cruda realidad
18:30
Speaker 3: es que una importación fallida deja a tu entorno en
18:31
Speaker 3: una especie de limbo, elim. Algunos componentes pueden actualizarse, otros
18:36
Speaker 3: quedarse en su versión antigua, las conexiones o roles pueden
18:39
Speaker 3: quedar en un estado indefinido. Las configuraciones se desincronizan rápidamente
18:43
Speaker 3: y terminas con un sistema que no coincide con lo
18:45
Speaker 3: que nadie pretendía. Lo que parece un ajuste menor en
18:49
Speaker 3: una solución administrada pueden utilizar procesos de negocio completos a futuro.
18:53
Speaker 3: Aquí es donde la mayoría de los administradores se ven atrapados.
18:55
Speaker 3: Existe la sensación de que puedes simplemente ejecutarlo de nuevo
18:58
Speaker 3: o deshacer un paso cuando en la práctica estás lidiando
19:00
Speaker 3: con una aplicación en vivo de la que los usuarios dependen.
19:04
Speaker 3: Ahora visualiza los riesgos con un ejemplo real. Una gran
19:07
Speaker 3: empresa financiera tenía una nueva función lista para su portal
19:10
Speaker 3: de Power Apps, algunos ajustes de flujo de trabajo, un
19:13
Speaker 3: par de paneles nuevos y una tabla de datos reconfigurada.
19:17
Speaker 3: El cambio pasó rápidamente por control de calidad, por lo
19:20
Speaker 3: que aprobaron la importación a producción un viernes por la tarde,
19:22
Speaker 3: esperando tener todo listo para la fecha límite de informes
19:24
Speaker 3: de lunes. La importación dio error a mitad de proceso.
19:27
Speaker 3: El resultado final, los usuarios que iniciaron sesión el lunes
19:30
Speaker 3: por la mañana encontraron paneles rotos, automatizaciones fallidas y varias
19:33
Speaker 3: aplicaciones fallidas y varias aplicaciones de lienzo que no cargaban.
19:35
Speaker 3: Para empeorar las cosas, su última copia de seguridad completa
19:38
Speaker 3: del entorno tenía semanas de antigüedad y no habían exportado
19:41
Speaker 3: la última versión de la solución tras los cambios de
19:42
Speaker 3: último minuto. Las opciones de restauración eran limitadas y la
19:46
Speaker 3: empresa perdió un día entero de trabajo mientras los administradores
19:49
Speaker 3: reconstruían el entorno. Ningún paso único causó el desastre. Una
19:53
Speaker 3: ventana de respaldo perdida la creen sin soluciones rápidas y
19:55
Speaker 3: la falta de una planificación de rollback flexible lo que
19:57
Speaker 3: los dejó expuestos. Entonces,¿ qué puedes hacer realmente para evitar
20:01
Speaker 3: terminar en el limbo de un rollback? La primera y
20:04
Speaker 3: más confiable capa es automatizar las exportaciones de soluciones en
20:08
Speaker 3: cada etapa. En lugar de confiar en esa última versión
20:11
Speaker 3: en una carpeta de desarrollo, tu pipeline debería exportar automáticamente
20:14
Speaker 3: la solución a una ubicación segura, idealmente al control de fuente,
20:17
Speaker 3: idealmente al control de fuente. De esa manera, cada lanzamiento,
20:19
Speaker 3: sea exitoso o fallido, tiene una copia de seguridad correspondiente.
20:22
Speaker 3: Si la implementación de hoy sale mal, no te quedarás
20:24
Speaker 3: atrapado con lo que sea que tengas en tu escritorio.
20:27
Speaker 3: Siempre tienes acceso al último paquete que funcionó correctamente. Las
20:30
Speaker 3: copias de seguridad nocturnas del entorno son otra medida práctica,
20:33
Speaker 3: incluso si crees que nunca las necesitarás. Microsoft ofrece funciones
20:36
Speaker 3: completas de copia de seguridad del entorno, especialmente para entornos Dataverse,
20:39
Speaker 3: pero te sorprendería cuántos equipos realmente no automatizan su uso.
20:43
Speaker 3: La guía oficial es clara, siempre ejecuta una copia de
20:45
Speaker 3: seguridad completa del entorno antes de tocar la producción. Sin embargo,
20:48
Speaker 3: en la práctica muchos equipos confían en el, lo haremos
20:50
Speaker 3: si nos acordamos, si nos acordamos. Eso funciona tan bien
20:53
Speaker 3: como cabría esperar hasta que deja de funcionar. Configurar copias
20:56
Speaker 3: de seguridad nocturnas o previas a la implementación significa que
20:59
Speaker 3: tienes una instantánea completa para restaurar sitios alemanes. Al combinarlas
21:02
Speaker 3: con exportaciones a nivel de solución, puedes decidir si restaurar
21:05
Speaker 3: todo un entorno o solo revertir una única solución dependiendo
21:09
Speaker 3: de la escala del problema. Versionar archivos de solución en
21:12
Speaker 3: el control de código fuente puede sonar básico, pero es
21:14
Speaker 3: un salvavidas. Rastrear cada zip exportado con historial de confirmaciones,
21:18
Speaker 3: nombres de ramas y solicitudes de extracción. Acerca las implementaciones
21:21
Speaker 3: de Power Platform a los ciclos de vida de aplicaciones clásicos.
21:23
Speaker 3: Obtienes un registro de auditoría completo de qué cambió cuándo
21:26
Speaker 3: y quién lo hizo. Si se vuelve necesaria una reversión,
21:28
Speaker 3: no tienes por qué entrar en pánico Simplemente vuelve a
21:30
Speaker 3: implementar la compilación exitosa anterior. Esto no es solo conveniente.
21:34
Speaker 3: Es una de las formas más confiables de restaurar cambios
21:36
Speaker 3: críticos para el negocio sin impacto colateral. Cuando llegue el
21:39
Speaker 3: momento de ejecutar una reversión real, los archivos de solución
21:42
Speaker 3: exportados son tu salvavidas. Comienza restaurando la versión de solución
21:46
Speaker 3: anterior que ya validaste en un entorno inferior. Revertir a
21:51
Speaker 3: ese estado conocido como bueno restablecerá tus componentes, flujos y
21:53
Speaker 3: personalizaciones relacionadas. No tendrás una máquina del tiempo perfecta. Los
21:57
Speaker 3: registros o datos transaccionales modificados desde la última implementación podrían
22:01
Speaker 3: seguir en riesgo, pero puedes devolver la aplicación a una
22:03
Speaker 3: configuración funcional, a menudo en una hora. Para algo más grave,
22:07
Speaker 3: como una entidad corrupta, relaciones perdidas o problemas de integración
22:10
Speaker 3: de datos, es posible que debas usar esa copia de
22:13
Speaker 3: seguridad a nivel de entorno o restauraciones de tablas individuales
22:16
Speaker 3: según lo disponible.¿ Una lección aprendida por las malas? Nunca
22:20
Speaker 3: sumas que tu plan de reversión es robusto a menos
22:22
Speaker 3: que lo hayas probado en un entorno de pruebas. La
22:25
Speaker 3: diferencia entre un proceso de recuperación teórico y uno real
22:27
Speaker 3: es enorme. Sin pruebas te arriesgas a restaurar dependencias incompletas
22:31
Speaker 3: o encontrarte con conflictos de importación que no anticipaste. Practicar
22:35
Speaker 3: tu reversión es una...