WEBVTT 00:00:00.340 --> 00:00:06.480 Listo para 10 días de Microsoft 365, Copilot, IAE, Azure y las personas que están dando forma al futuro del trabajo. 00:00:06.480 --> 00:00:11.800 Y este enero, M365 con regresa y venimos con más fuerza. 00:00:12.860 --> 00:00:18.140 Únete a nosotros para sesiones en vivo, demostraciones reales y conocimientos prácticos de MVPs y expertos de la industria de todo el mundo. 00:00:18.820 --> 00:00:21.220 Nada de diapositivas genéricas, nada de tecnicismos interminables. 00:00:22.080 --> 00:00:23.400 Abordamos los desafíos reales. 00:00:23.720 --> 00:00:28.620 Copilot Studio, agentes de IA, Fabric, seguridad, gobernanza y automatización. 00:00:28.620 --> 00:00:34.380 Ya seas un profesional de TI, desarrollador o líder empresarial, hay sesiones diseñadas para ti. 00:00:35.580 --> 00:00:40.000 Con 10 días completos, puedes explorar múltiples tecnologías y conectar con una comunidad global. 00:00:40.940 --> 00:00:44.280 Míralo en vivo y lleva ideas prácticas de vuelta a tu organización. 00:00:45.220 --> 00:00:48.980 Enero de 2027, 10 días, una sola comunidad Microsoft. 00:00:49.460 --> 00:00:50.540 El registro ya está abierto. 00:00:52.160 --> 00:00:55.000 Asegura tu lugar hoy mismo. 00:00:55.000 --> 00:00:58.820 Eso es m365con.net. 00:00:59.960 --> 00:01:03.360 Únete ahora en m365con.net y te veremos. 00:01:03.660 --> 00:01:04.540 En vivo en enero. 00:01:05.160 --> 00:01:08.080 ¿Alguna vez has sentido que tus implementaciones en Power Platform son una caja nega? 00:01:08.420 --> 00:01:12.680 Envías una actualización, contienes la respiración y solo esperas que funcione en desarrollo, pruebas y producción. 00:01:12.680 --> 00:01:20.820 Y si pudieras controlar y ver cada etapa de tu proceso de ALM usando GitHub Actions sin más conjeturas, ni parches manuales, 00:01:21.420 --> 00:01:28.660 corramos el velo sobre cómo se conectan realmente cada componente, el control de versiones, la automatización y las variables seguras y las variables seguras. 00:01:28.860 --> 00:01:29.900 Esto no es solo un tutorial común. 00:01:30.560 --> 00:01:34.320 Este es el porqué que la mayoría de las guías omiten para que tu próxima implementación no te deje con dudas. 00:01:34.960 --> 00:01:37.760 Entonces, ¿por qué el ALM de Power Platform parece un laberinto? 00:01:37.760 --> 00:01:44.900 Si alguna vez has intentado implementar una Power App y has sentido esa incertidumbre creciente, como si algo importante se hubiera escapado, ¿no estás solo? 00:01:46.320 --> 00:01:52.460 En teoría, Power Platform promete un desarrollo de aplicaciones sencillo, pero detrás de esa fachada amigable, la ALM es todo menos directo. 00:01:53.360 --> 00:01:59.060 Una aplicación web se implementa desde el control de código, se compila en un pipeline y llega a producción con un comportamiento predecible. 00:01:59.800 --> 00:02:07.460 Power Platform, en cambio, oculta la mitad de la lógica dentro de interfaces de arrastrar y soltar pantallas de conectores y fórmulas que no ves en ningún repositorio Git, 00:02:07.460 --> 00:02:16.680 Git. Por eso, incluso si sigues cada paso de esas guías de administración de alto nivel, sigues encontrando fallos extraños y difíciles de diagnosticar cuando las apps críticas salen de desarrollo. 00:02:17.420 --> 00:02:19.580 Echemos un vistazo a las guías de ALM que circulan por ahí. 00:02:20.020 --> 00:02:24.100 La mayoría te guiará a través de la exportación de un archivo SIP de solución y su importación en otro lugar. 00:02:24.600 --> 00:02:26.720 Bastante simple, pero el cómo es solo una capa. 00:02:27.400 --> 00:02:28.520 Lo que omiten es el porqué. 00:02:29.620 --> 00:02:33.400 ¿Por qué las implementaciones de Power Platform fallan de maneras que el código tradicional nunca lo hace? 00:02:33.840 --> 00:02:35.360 Eso es lo que causa una confusión interminable. 00:02:35.360 --> 00:02:41.500 La raíz del problema es que la lógica, las conexiones y la configuración en Power Apps no se almacenan como el código clásico. 00:02:42.460 --> 00:02:44.940 No solo estás clonando un repositorio y viendo las pruebas unitarias. 00:02:45.680 --> 00:02:53.960 Así que, cuando intentas mover tu aplicación, todas esas dependencias ocultas, conexiones a Outlook, SharePoint o APIs personalizadas no siempre viajan bien dentro de ese archivo SIP. 00:02:54.720 --> 00:02:55.240 Este escenario. 00:02:55.800 --> 00:02:57.800 Logras que una aplicación nueva funcione en el entorno de desarrollo. 00:02:58.220 --> 00:03:01.780 Exportas una solución, la importas a pruebas y de repente el flujo deja de funcionar. 00:03:02.060 --> 00:03:03.140 Rara vez es solo un problema de archivos. 00:03:03.140 --> 00:03:11.180 En cambio, las conexiones apuntan al lugar equivocado, los permisos no coinciden y las políticas de datos bloquean conexiones que parecían estar bien hace un momento. 00:03:11.180 --> 00:03:21.100 Ahora, imagina hacer esto en tres entornos, desarrollo, pruebas y producción, cada uno con diferentes conexiones, políticas de protección de datos, aprobadores y controles de administración. 00:03:21.940 --> 00:03:23.400 No puedes seguir de esto simplemente copiando. 00:03:24.160 --> 00:03:27.020 La investigación respalda lo que los administradores y creadores ven cada semana. 00:03:27.820 --> 00:03:33.500 La mayoría de las implementaciones fallidas en Power Platform provienen de referencias de conectores faltantes o variables de entorno mal gestionadas. 00:03:33.500 --> 00:03:39.480 Que falte una referencia de conector significa simplemente que el flujo no puede encontrar su conexión a Outlook o Dataverse. 00:03:40.420 --> 00:03:45.500 Por lo tanto, en el momento en que intentas ejecutar tu aplicación o flujo en otro entorno, obtienes errores de tiempo de ejecución. 00:03:47.300 --> 00:03:52.480 Y como las variables de entorno funcionan de forma distinta en Power Platform comparado con otros productos de Microsoft 365, 00:03:52.780 --> 00:03:54.920 confunden incluso a los desarrolladores experimentados. 00:03:55.680 --> 00:03:59.280 Se supone que las variables deben manejar endpoints claves o configuraciones específicas del inquilino. 00:03:59.280 --> 00:04:05.680 Pero si alguien olvida actualizarlas después de exportar una solución hasta un cambio inofensivo, puede romper una aplicación en vivo. 00:04:06.740 --> 00:04:08.740 Muchos de nosotros caemos en la misma trampa al principio. 00:04:09.400 --> 00:04:14.260 Podrías pensar que exportar un zip de la solución agrupa todo lo necesario, pero en realidad omite las referencias de conectores dinámicos. 00:04:14.920 --> 00:04:19.020 Por ejemplo, supongamos que tienes una aplicación que usa un conector HTTP para un servicio de terceros en desarrollo. 00:04:19.820 --> 00:04:23.380 Cuando importas a pruebas o producción, ¿esa instancia exacta del conector no existirá? 00:04:23.380 --> 00:04:34.420 La referencia del conector dentro de tu aplicación apunta a un objeto faltante, y los flujos dentro de la solución fallan silenciosamente hasta que un usuario o administrador recrea y reasigna las conexiones manualmente. 00:04:35.360 --> 00:04:39.980 Si tienes más de un creador o administrador, es aún más fácil perder el rastro de qué referencia va a dónde. 00:04:40.260 --> 00:04:42.840 Nadie quiere ese análisis posterior de Endesarrollo si funcionaba. 00:04:44.560 --> 00:04:46.700 Otra complicación, las entidades de servicio. 00:04:46.700 --> 00:04:52.580 La mayoría empiezan usando cuentas de usuario para exportar e importar soluciones porque es más rápido comenzar. 00:04:53.580 --> 00:04:59.620 Pero cuando intentas automatizar conexiones de GitHub o cualquier sistema de integración continua, usar las credenciales de una persona lleva rápidamente a un versión sin salir. 00:04:59.960 --> 00:05:09.480 Te chocarás con muros de permisos, a veces sin mensajes de error claros o incluso activarás auditorías de cumplimiento porque estás ejecutando despliegues críticos bajo una cuenta personal en lugar de algo diseñado para la automatización. 00:05:09.480 --> 00:05:18.280 Las identidades de servicio, básicamente identidades de aplicación creadas en Azure AD, manejan todos los permisos, registros y auditorías que su pipeline necesita. 00:05:19.300 --> 00:05:25.040 Sin ellas, su cadena de automatización se convierte en un mosaico de entregas manuales y nunca sabrá quién cambió qué. 00:05:25.760 --> 00:05:27.480 El control de código fuente también se vuelve incómodo. 00:05:28.380 --> 00:05:31.320 Con el código convencional tiene historiales de confirmación y herramientas de seguimiento. 00:05:32.120 --> 00:05:36.780 Los archivos de solución de Power Platform solo representan instantáneas, lo que significa que pierde el seguimiento detallado de los cambios. 00:05:36.780 --> 00:05:43.500 La lógica oculta en las fórmulas de pantalla de una aplicación de lienzo o en flujos poco documentados no es visible hasta que vuelve a exportar. 00:05:44.120 --> 00:05:49.620 Alguien ajusta un parámetro de flujo en la interfaz y buena suerte tratando de averiguar por qué los entornos posteriores se comportan de repente de reforma. 00:05:49.980 --> 00:05:56.600 El resultado final es que estrenar el ALM para Power Platform parece resolver un rompecabezas al que le faltan la mitad de las piezas o que están escondidas bajo la caja. 00:05:57.660 --> 00:06:05.340 Las dependencias invisibles, los conectores específicos del entorno y las variables que no puede ver en el código alteran el flujo de trabajo habitual del desarrollador. 00:06:05.340 --> 00:06:15.800 Y eso sin contar que los entornos de producción casi siempre tienen permisos más estrictos, políticas de datos distintas y requisitos de auditoría que no son evidentes en desarrollo o pruebas. 00:06:16.760 --> 00:06:17.940 Pero aquí está lo positivo. 00:06:18.420 --> 00:06:19.760 Esta complejidad no es aleatoria. 00:06:20.460 --> 00:06:26.840 Hay una razón práctica por la que Power Platform maneja el código fuente, las variables y los conectores de una manera tan única. 00:06:27.600 --> 00:06:31.460 Intenta permitir que los usuarios de negocio creen aplicaciones potentes sin preocuparse por el código. 00:06:31.460 --> 00:06:37.780 El efecto secundario es que usted, como responsable de configurar la automatización, debe rastrear lo que se esconde bajo el capó. 00:06:38.740 --> 00:06:46.400 Si sabe por dónde pasan esos cables invisibles, podrá solucionar o evitar la mayoría de los errores que descarrilan el ALM de Power Platform. 00:06:46.900 --> 00:06:49.700 Ahora bien, si todo esto le parece mucho que gestionar, no se equivoca. 00:06:50.300 --> 00:06:53.500 Pero existen cuatro pilares de ALM que realmente ayudan a desenredar este lío. 00:06:53.980 --> 00:06:55.640 Código fuente, compilación, pruebas y despliegue. 00:06:55.640 --> 00:07:01.080 Cada uno tiene sus peculiaridades en Power Platform, pero juntos devuelven la estructura a lo que de otro modo parecería un caos. 00:07:02.480 --> 00:07:05.180 Sistema ALM principal, código fuente, compilación, pruebas y despliegue. 00:07:05.780 --> 00:07:08.920 Cada vez que alguien pide un pipeline de Power Platform que simplemente funcione, 00:07:09.220 --> 00:07:11.780 lo primero que viene es los cuatro pilares básicos de la ALM. 00:07:12.120 --> 00:07:14.440 Código fuente, compilación, pruebas y despliegue. 00:07:15.980 --> 00:07:18.580 En el mundo del desarrollo tradicional casi puede ejecutarlos mientras duerme. 00:07:19.020 --> 00:07:20.620 Power Platform no se lo pone tan fácil. 00:07:21.520 --> 00:07:23.400 De repente código fuente no significa código. 00:07:24.140 --> 00:07:28.460 Significa lidiar con archivos de solución, exportar paquetes comprimidos repletos de aplicaciones, 00:07:28.640 --> 00:07:32.480 flujos y, a veces, conectores que pretenden ser parte del código fuente. 00:07:33.860 --> 00:07:37.860 Empecemos por lo básico y analicemos, ¿qué hace que cada pilar sea un poco extraño en este mundo? 00:07:38.680 --> 00:07:39.980 Tiene su archivo zip de solución. 00:07:40.300 --> 00:07:41.240 No es código hígado habitual. 00:07:42.300 --> 00:07:45.200 Ábrelo y te recibirán archivos XML y JSON de configuración, 00:07:45.380 --> 00:07:47.640 no la lógica que verías en TypeScript o C-Shirtable. 00:07:48.640 --> 00:07:50.420 Pero este es el código fuente de Power Platform. 00:07:50.860 --> 00:07:52.240 Los equipos suelen tropezar aquí. 00:07:52.240 --> 00:07:55.420 Parece portátil hasta que te das cuenta de que la mayoría de los cambios, 00:07:55.560 --> 00:07:58.660 como actualizar una fórmula en una pantalla o ajustar la lógica de un flujo, 00:07:58.760 --> 00:08:01.560 no son evidentes hasta que exportas un nuevo archivo zip de solución. 00:08:02.320 --> 00:08:04.820 Así que sí, puedes versionar estos archivos de solución en Git, 00:08:05.120 --> 00:08:07.820 pero a menos que seas disciplinado al exportar tras cada edición relevante, 00:08:07.920 --> 00:08:09.520 tu historial tendrá vacíos evidentes. 00:08:10.600 --> 00:08:11.700 Ahora viene la configuración. 00:08:12.420 --> 00:08:16.940 Para aplicaciones normales, podrías guardar las cadenas de conexión en un archivo de configuración y listo, y listo. 00:08:16.980 --> 00:08:20.560 Power Platform introduce datos específicos del entorno dentro de estas soluciones. 00:08:20.560 --> 00:08:24.740 No se trata solo de variables de entorno, sino de referencias de conectores, 00:08:24.880 --> 00:08:28.740 puntos de conexión dinámicos, roles y permisos agrupados junto con la lógica de negocio. 00:08:29.800 --> 00:08:33.220 Si olvidas actualizarlos antes de exportar desde desarrollo o pruebas, 00:08:33.420 --> 00:08:35.720 estarás fijando punteros al lugar equivocado. 00:08:36.460 --> 00:08:39.320 He visto equipos enviar religiosamente sus archivos zip de solución, 00:08:40.280 --> 00:08:44.300 solo para implementar y darse cuenta de que la mitad de su aplicación sigue conectada al database de desarrollo 00:08:44.300 --> 00:08:47.400 en lugar del de producción, porque nadie reasignó las referencias de los conectores. 00:08:47.400 --> 00:08:49.180 Luego tenemos la compilación. 00:08:50.100 --> 00:08:55.220 La palabra compilación suele traer imágenes de compilar código y ver marcas verdes en un trabajo de integración continua. 00:08:55.980 --> 00:08:59.500 En Power Platform, el proceso de compilación trata sobre almacenar esos paquetes zip, 00:08:59.620 --> 00:09:01.500 verificar el esquema y confirmar las dependencias. 00:09:02.520 --> 00:09:06.340 En una tubería de GitHub Actions, un trabajo de compilación toma tu archivo de solución enviado, 00:09:06.800 --> 00:09:11.580 lo usará CLI de Power Platform de Microsoft para descomprimir, validar y volver a empaquetar la solución. 00:09:11.580 --> 00:09:14.440 El paso de validación es donde ocurre la magia o el caos. 00:09:14.920 --> 00:09:16.940 Puede detectar referencias rotas o acciones no compatibles. 00:09:18.100 --> 00:09:22.540 Peor aún, si un cambio en tu flujo depende de un conector personalizado que nunca llegó al control de versiones, 00:09:22.780 --> 00:09:25.800 tu compilación empaquetará silenciosamente algo incompleto. 00:09:26.600 --> 00:09:27.560 ¿Y dónde las cosas se complican? 00:09:28.280 --> 00:09:30.840 Esos trabajos de compilación no tratan tanto de compilar, 00:09:30.960 --> 00:09:35.280 sino de orquestar una explotación confiable y asegurar que lo que hay dentro sea apto para envío. 00:09:36.180 --> 00:09:39.540 Los equipos que se saltan esto o lo hacen con prisas terminan rápidamente en situaciones 00:09:39.540 --> 00:09:44.060 donde una compilación tiene éxito técnico, pero lo que llega o atea producción carece de la mitad de sus funciones previstas. 00:09:45.760 --> 00:09:49.280 Microsoft sigue impulsando el mensaje de que los archivos de solución hacen que hay una nota al pie. 00:09:50.400 --> 00:09:53.060 La portabilidad depende de que los conectores estén correctamente asignados 00:09:53.060 --> 00:09:54.920 y los roles configurados en todos los entornos. 00:09:55.280 --> 00:09:56.440 Las pruebas son el siguiente botón de fuente. 00:09:56.920 --> 00:10:01.580 En una tubería de aplicación web, las pruebas automatizadas podrían ejecutar pruebas unitarias o comprobaciones de interfaz. 00:10:02.440 --> 00:10:05.380 Para Power Platform, lo que cuenta como prueba está sujeto a debate. 00:10:05.380 --> 00:10:11.640 A veces es la validación de la solución, es decir, se abre la solución y se resuelven las dependencias clave. 00:10:12.640 --> 00:10:17.460 Otras veces es ejecutar flujos de prueba o verificar que los conectores respondan en un entorno de prueba. 00:10:18.300 --> 00:10:22.840 Muchas veces las pruebas son manuales ya que la validación de la lógica de negocios dentro de una aplicación de lienzo 00:10:22.840 --> 00:10:24.840 aún no está integrada en los procesos automatizados. 00:10:25.500 --> 00:10:29.700 Pero puedes automatizar comprobaciones para detectar conectores faltantes, validar flujos críticos 00:10:29.700 --> 00:10:33.360 o incluso hacer ping a un entorno de prueba solo para verificar que las credenciales funcionan. 00:10:34.120 --> 00:10:35.480 La implementación es donde se siente difícil. 00:10:35.840 --> 00:10:39.320 Cuando se implementa una aplicación estándar, podrías simplemente subir un artefacto web a Azure. 00:10:40.020 --> 00:10:43.620 Con Power Platform debes asignar conexiones, otorgar permisos, actualizar secretos, 00:10:43.860 --> 00:10:47.780 intercambiar variables de entorno y finalmente activar una importación mediante una entidad de servicio, 00:10:48.000 --> 00:10:48.880 nunca una cuenta normal. 00:10:49.760 --> 00:10:52.520 De lo contrario, te verás atrapado en auditorías y denegaciones de permisos. 00:10:53.760 --> 00:10:55.640 GitHub Actions puede unificar este proceso, 00:10:55.640 --> 00:10:59.200 pero solo si cada tarea sabe qué entorno debe elegir y qué secretos utilizar. 00:11:00.360 --> 00:11:04.640 He visto equipos intentar tomar atajos usando un mismo conjunto de credenciales para desarrollo y producción, 00:11:04.980 --> 00:11:08.820 lo cual es una receta para el caos, filtraciones de datos, errores de permisos y funciones rotas 00:11:08.820 --> 00:11:10.020 que solo aparecen en un entorno. 00:11:11.140 --> 00:11:13.220 Tomemos como ejemplo un equipo RR con el que trabajé hace unos meses. 00:11:14.060 --> 00:11:18.020 Hacían casi todo bien, repositorios Git estándar, archivos zip de soluciones versionados y ramas claras. 00:11:18.620 --> 00:11:20.420 Pero su proceso siempre fallaba en la implementación. 00:11:20.820 --> 00:11:21.080 ¿Por qué? 00:11:21.380 --> 00:11:24.820 Nunca se molestaron en cambiar las variables de entorno o actualizar las referencias de los conectores 00:11:24.820 --> 00:11:25.920 antes de importar la producción. 00:11:25.920 --> 00:11:30.880 Nah, eso dejaba flujos clave apuntando a los puntos finales incorrectos y enviando datos a los sistemas equivocados. 00:11:31.780 --> 00:11:35.440 La solución fue incluir pasos con scripts en su flujo de GitHub que cambiaban las variables 00:11:35.440 --> 00:11:37.700 y resignaban cada conector durante la importación. 00:11:38.460 --> 00:11:40.200 La propia guía de Microsoft es directa al respecto. 00:11:40.200 --> 00:11:44.820 Usa archivos de solución para mover elementos entre entornos, pero siempre gestiona las referencias 00:11:44.820 --> 00:11:47.580 de los conectores y la asignación de errores como parte de tu proceso. 00:11:48.380 --> 00:11:51.400 Señalan que omitir estos pasos es la causa principal de que las aplicaciones fallan, especialmente 00:11:51.400 --> 00:11:54.160 a medida que los entornos se vuelven más restringidos, se vuelven a restringir. 00:11:54.540 --> 00:11:58.640 Cuando tratas el código fuente, la compilación, las pruebas y la implementación como partes 00:11:58.640 --> 00:12:02.420 conectadas y no como pasos aislados, es más fácil ver por qué fracasan tantos intentos 00:12:02.420 --> 00:12:05.500 de LM y cómo puedes solucionar problemas en lugar de solo cruzar los dedos. 00:12:05.500 --> 00:12:10.740 A continuación, veamos cómo GitHub Actions coordina esta danza, los activadores, la 00:12:10.740 --> 00:12:14.540 ramificación y la separación de tareas que mantienen la automatización de tu Power 00:12:14.540 --> 00:12:16.440 Platform flexible y segura. 00:12:17.720 --> 00:12:20.340 GitHub Actions, conectando los puntos mediante activadores y tareas. 00:12:21.220 --> 00:12:24.700 Si has esperado que termine un flujo de trabajo de GitHub Actions tras actualizar tu Power 00:12:24.700 --> 00:12:27.900 App, ya sabes que la automatización no es instantánea y definitivamente no es magia. 00:12:28.980 --> 00:12:32.060 La mayoría de los equipos chocan contra esa pared justo después de la moción de ver 00:12:32.060 --> 00:12:33.340 su primer flujo de trabajo ejecutado. 00:12:33.340 --> 00:12:38.980 Configuras un script, lo conectas a tu repositorio y esperas que cada nueva confirmación se despliegue 00:12:38.980 --> 00:12:41.300 limpiamente en todos los entornos. 00:12:41.780 --> 00:12:42.880 Entonces la realidad te golpea. 00:12:43.380 --> 00:12:47.340 En lugar de simplemente iniciar un script, GitHub Actions utiliza una cadena lógica basada 00:12:47.340 --> 00:12:50.240 en activadores, trabajos y transferencias entre entornos. 00:12:50.860 --> 00:12:54.260 Ese orden y estructura es lo que evita que los despliegues se conviertan en un enredo de 00:12:54.260 --> 00:12:55.780 pasos fallidos y errores extraños. 00:12:56.340 --> 00:12:58.780 El punto de partida en este sistema es el activador trigger. 00:12:58.780 --> 00:13:04.180 La mayoría de los principiantes crean un flujo de trabajo que se dispara con cada envío 00:13:04.180 --> 00:13:08.040 o cuando una solicitud de extracción llega a la rama principal. 00:13:08.580 --> 00:13:10.140 A primera vista eso parece ser la mejor pregunta. 00:13:10.540 --> 00:13:12.540 ¿Por qué no ejecutar tu canalización cada vez que hay cambios en el trabajo? 00:13:12.720 --> 00:13:13.300 Aquí está el problema. 00:13:13.760 --> 00:13:16.720 Cuando solo configuras un activador en la rama principal, todo se canaliza a través de 00:13:16.720 --> 00:13:17.180 una única vía. 00:13:17.180 --> 00:13:20.180 ¿Qué sucede si los cambios deben ir a desarrollo pero no a prueba o producción? 00:13:20.520 --> 00:13:23.840 ¿Qué pasa si estás listo para enviar a producción pero la prueba aún está validando? 00:13:24.600 --> 00:13:28.880 Los equipos que se ciñen a activadores universales suelen tener problemas donde funciones destinadas 00:13:28.880 --> 00:13:33.320 a entornos de desarrollo se cuelan en producción o despliegues de prueba que sobreescriben configuraciones 00:13:33.320 --> 00:13:34.140 de producción. 00:13:35.220 --> 00:13:38.580 Puedes ramificar los flujos de trabajo para cada entorno de desarrollo, prueba y producción 00:13:38.580 --> 00:13:41.420 y configurar activadores muy específicos para cada una. 00:13:42.180 --> 00:13:45.820 Por ejemplo, configura un flujo que solo se ejecute con envíos a una rama de desarrollo 00:13:45.820 --> 00:13:49.400 o dispara un flujo distinto cuando alguien realiza una fusión en la rama de lanzamiento 00:13:49.400 --> 00:13:49.940 o producción. 00:13:50.900 --> 00:13:54.040 Este enfoque brinda más control y crea una barrera clara entre el trabajo en curso y 00:13:54.040 --> 00:13:57.660 los cambios en vivo, pero muchos equipos nunca revisan sus activadores después de crearlos. 00:13:58.880 --> 00:14:03.140 Así es como los secretos de un entorno pueden filtrarse a otro y la configuración destinada 00:14:03.140 --> 00:14:05.320 a desarrollo termina en producción por accidente. 00:14:05.980 --> 00:14:09.620 Un equipo con el que trabajé intentó ejecutar todo su proceso de ALM desde un solo flujo 00:14:09.620 --> 00:14:10.000 de trabajo. 00:14:10.740 --> 00:14:15.020 Por un tiempo pareció estar bien hasta que alguien notó que la cadena de conexión a la base 00:14:15.020 --> 00:14:17.620 de datos de producción apareció en el entorno de desarrollo. 00:14:18.240 --> 00:14:21.040 No se dieron cuenta de que esos secretos se estaban compartiendo entre los trabajos. 00:14:21.700 --> 00:14:24.640 Y una vez que el código se movía entre entornos, esos secretos se filtraban con él. 00:14:25.080 --> 00:14:26.360 No fue un choque o error evidente. 00:14:26.800 --> 00:14:27.360 Fue silencioso. 00:14:28.660 --> 00:14:31.940 Este tipo de fuga de datos es más común de lo que piensas, especialmente si no configuras 00:14:31.940 --> 00:14:33.980 tus flujos para separar secretos y variables de entorno. 00:14:35.280 --> 00:14:38.900 Cada trabajo en un flujo de trabajo de GitHub Actions maneja una pieza clara del proceso. 00:14:39.860 --> 00:14:42.900 Un trabajo podría encargarse de exportar la solución desde un entorno de origen. 00:14:42.900 --> 00:14:47.420 De origen, otro trabajo se ocupa de la validación, desempaquetado, escaneo de metadatos de la 00:14:47.420 --> 00:14:51.560 solución, verificación de dependencias y asegurar que existan referencias de conectores. 00:14:52.900 --> 00:14:56.600 Luego viene el trabajo que prepara las variables específicas del entorno, traduciendo la solución 00:14:56.600 --> 00:14:58.240 para que se ajuste a su entorno de destino. 00:14:59.040 --> 00:15:02.940 El último trabajo activa el proceso de importación, usando entidades de servicio para escribir los 00:15:02.940 --> 00:15:04.380 cambios en el entorno correcto. 00:15:05.120 --> 00:15:08.380 Podrías pensar en las variables de entorno y los secretos como simples marcadores de posición, 00:15:08.380 --> 00:15:11.180 pero en la práctica son el pegamento que mantiene todo unido. 00:15:12.560 --> 00:15:17.100 Las cadenas de conexión, claves API y contraseñas compartidas deben intercambiarse entre tareas, 00:15:17.240 --> 00:15:19.460 pero nunca deben filtrarse entre entornos. 00:15:20.740 --> 00:15:24.480 En ILM para Power Platform puede tener una conexión de Dataverse diferente para cada entorno, 00:15:24.940 --> 00:15:28.060 o necesitar cambiar puntos de enlace según el flujo o PowerApp que use. 00:15:29.820 --> 00:15:33.640 Si reutiliza variables o codifica secretos de forma fija, terminará con una canalización 00:15:33.640 --> 00:15:36.240 frágil o peor aún, con riesgos de seguridad significativos. 00:15:36.240 --> 00:15:40.520 El proceso de importación depende de extraer secretos solo del almacén correcto para que 00:15:40.520 --> 00:15:43.600 la producción no quede expuesta por errores de prueba o desarrollo. 00:15:44.280 --> 00:15:47.980 Un buen modelo mental para los secretos en GitHub Actions es imaginar que cada entorno 00:15:47.980 --> 00:15:52.140 tiene su propio almacén digital, una caja cerrada que solo las tareas correctas pueden 00:15:52.140 --> 00:15:52.380 ver. 00:15:53.360 --> 00:15:54.860 GitHub le brinda controles precisos. 00:15:56.020 --> 00:15:59.320 Puede limitar los secretos a entornos específicos de modo que una tarea en desarrollo no pueda 00:15:59.320 --> 00:16:01.560 acceder a credenciales de producción y viceversa. 00:16:02.760 --> 00:16:03.680 Configura estos almacenes. 00:16:03.680 --> 00:16:07.080 Aunque alguien intente algo arriesgado en la canalización, las reglas de protección 00:16:07.080 --> 00:16:09.440 de entornos evitarán que un error se propague. 00:16:10.300 --> 00:16:13.140 La documentación tanto de Microsoft como de GitHub insiste en este punto. 00:16:14.000 --> 00:16:17.300 Recomiendan reglas de protección de entorno y un alcance estricto de secretos para detener 00:16:17.300 --> 00:16:19.420 las filtraciones entre entornos antes de que ocurran. 00:16:20.580 --> 00:16:24.200 Sin ese tipo de protección, incluso los flujos de trabajo de ALM mejor diseñados se vienen 00:16:24.200 --> 00:16:24.540 abajo. 00:16:25.480 --> 00:16:28.780 Imagina un flujo de trabajo que se despliega en producción manteniendo una cadena de conexión 00:16:28.780 --> 00:16:32.100 de desarrollo o un entorno de prueba con exceso a datos de producción. 00:16:32.100 --> 00:16:34.260 No siempre causa fallos visibles. 00:16:35.100 --> 00:16:38.760 A veces simplemente activan alertas de cumplimiento o llenan los registros con errores sutiles 00:16:38.760 --> 00:16:40.760 que poco a poco se convierten en problemas mayores. 00:16:41.180 --> 00:16:44.320 Por eso, ramificar flujos de trabajo y limitar el alcance de los secretos no son solo temas 00:16:44.320 --> 00:16:44.800 avanzados. 00:16:45.160 --> 00:16:48.240 Son la red de seguridad que evita que su automatización se desmorone silenciosamente. 00:16:48.760 --> 00:16:52.660 También es valioso dividir los flujos de trabajo, no solo por entorno, sino por responsabilidad. 00:16:52.920 --> 00:16:53.740 Sino por responsabilidad. 00:16:53.740 --> 00:16:57.640 El código que exporta y valida soluciones ni siquiera debería saber cómo desplegar 00:16:57.640 --> 00:16:59.100 o intercambiar secretos. 00:16:59.680 --> 00:17:04.640 Si cada tarea maneja una pieza del rompecabezas, es mucho más fácil detectar dónde fallan las 00:17:04.640 --> 00:17:07.360 cosas, revertir cambios y auditarlos después. 00:17:08.400 --> 00:17:10.120 Los secretos permanecen en sus almacenes. 00:17:10.260 --> 00:17:14.340 Las tareas siguen permisos claramente definidos y los fallos de la canalización señalan directamente 00:17:14.340 --> 00:17:15.340 que debe repararse. 00:17:15.340 --> 00:17:21.520 Entender cómo GitHub Actions transfiere el trabajo entre tareas, manteniendo los secretos 00:17:21.520 --> 00:17:26.400 protegidos y los activadores bien definidos, convierte a la ALM en una práctica fiable, 00:17:26.760 --> 00:17:27.880 segura y predecible. 00:17:29.420 --> 00:17:33.040 Esta segmentación de flujos de trabajo no es solo para cumplir con las mejores prácticas. 00:17:34.120 --> 00:17:38.360 Es lo que bloquea filtraciones de seguridad silenciosas y sobrescrituras accidentales, eliminando 00:17:38.360 --> 00:17:41.540 toda una clase de errores invisibles antes de que afecten a sus entornos. 00:17:41.540 --> 00:17:46.540 Ahora que las piezas funcionan juntas mediante una automatización correctamente definida, 00:17:46.600 --> 00:17:48.620 es momento de abordar otro punto conflictivo. 00:17:49.260 --> 00:17:53.000 Conectores, principios de servicio y los pequeños pero críticos escollos que pueden 00:17:53.000 --> 00:17:55.460 detener sus implementaciones justo cuando gana confianza. 00:17:56.980 --> 00:17:59.720 Secretos de los principios de servicio y los problemas con los conectores. 00:18:00.340 --> 00:18:04.260 Si alguna vez ha intentado mover una power-up o un flujo de desarrollo a producción, conoce 00:18:04.260 --> 00:18:04.660 la historia. 00:18:06.040 --> 00:18:10.280 Todo funciona a la perfección en un entorno, pero en cuanto cambia, todo se detiene o le 00:18:10.280 --> 00:18:12.160 da esos misteriosos errores de conexión. 00:18:13.260 --> 00:18:15.240 No es algo exclusivo de un equipo específico. 00:18:15.840 --> 00:18:18.680 Todo administrador de Power Platform termina topándose con este muro. 00:18:19.680 --> 00:18:23.480 La raíz del problema reside en cómo se comportan los conectores y secretos detrás de escena. 00:18:23.900 --> 00:18:24.260 Decena. 00:18:24.840 --> 00:18:28.320 No puedes simplemente exportar un zip de solución desde desarrollo y esperar que funcione 00:18:28.320 --> 00:18:32.560 en otro lugar, porque las conexiones de las que depende cambian en cada entorno. 00:18:33.240 --> 00:18:34.820 Tomamos como ejemplo las referencias de conector. 00:18:34.820 --> 00:18:39.180 En Power Platform, un conector nunca es solo una pieza estática de información integrada 00:18:39.180 --> 00:18:39.960 en su aplicación. 00:18:40.820 --> 00:18:43.360 Es dinámico, mutable y a menudo único por entorno. 00:18:44.120 --> 00:18:47.360 Cuando exporta su solución, las referencias de conector actúan casi como marcadores. 00:18:48.200 --> 00:18:51.720 Apuntan a objetos de conexión que solo existen en el entorno donde se crearon. 00:18:52.680 --> 00:18:57.520 Por lo tanto, no importará prueba o producción, su sofisticado punto final HTTP o enlace a Dataverse 00:18:57.520 --> 00:19:00.400 no necesariamente se recrea de la misma manera, o a veces ni siquiera se recrea. 00:19:00.960 --> 00:19:02.240 Aquí es donde los equipos quedan atrapados. 00:19:02.240 --> 00:19:08.300 Si desarrollo usa un conector para probar datos y esa configuración exacta no se refleja 00:19:08.300 --> 00:19:13.400 en producción, su flujo o aplicación fallará silenciosamente o se bloqueará al primer 00:19:13.400 --> 00:19:14.700 intento de conexión. 00:19:16.300 --> 00:19:20.440 Muchas personas intentan evitar esto compartiendo credenciales de usuario entre entornos. 00:19:21.060 --> 00:19:25.380 Piensan que si usan la misma cuenta o contraseña que creó la conexión en desarrollo, tal vez 00:19:25.380 --> 00:19:26.780 funcione en producción. 00:19:27.780 --> 00:19:30.580 La realidad es que esto genera una serie de problemas, desde denegaciones de permisos hasta 00:19:30.580 --> 00:19:31.920 activación de auditores de cumplimiento. 00:19:32.560 --> 00:19:34.060 La guía de Microsoft es clara. 00:19:34.280 --> 00:19:37.520 Usar credenciales de usuario individuales para implementaciones automatizadas no es 00:19:37.520 --> 00:19:38.280 viable ni seguro. 00:19:39.320 --> 00:19:42.960 Pone su automatización a merced de los cambios de contraseña y puede dejar un rastro confuso 00:19:42.960 --> 00:19:44.000 en sus registros de auditoría. 00:19:44.740 --> 00:19:48.880 No hay una responsabilidad clara y, finalmente, los permisos bloquean la canalización cuando 00:19:48.880 --> 00:19:52.740 el usuario original es marcado, eliminado o pierde el acceso. 00:19:53.700 --> 00:19:54.780 Entra en el juego los principios de servicio. 00:19:54.780 --> 00:19:58.540 Si no ha trabajado con ellos, imagina un principio de servicio como un par de manos digitales 00:19:58.540 --> 00:20:00.900 adicionales diseñadas específicamente para la automatización. 00:20:01.660 --> 00:20:05.620 A diferencia de un usuario normal, un principio de servicio está vinculado a un registro de 00:20:05.620 --> 00:20:08.280 aplicación en Azure ADDI, no a una persona real. 00:20:09.060 --> 00:20:12.180 Le otorga los permisos mínimos necesarios para ejecutar sus tareas de implementación. 00:20:12.760 --> 00:20:14.600 Eso suena simple, pero la recompensa es grande. 00:20:15.100 --> 00:20:18.280 En lugar de depender de un usuario que podría dejar la organización o cambiar de rol, las 00:20:18.280 --> 00:20:20.900 implementaciones se mantienen consistentes, auditables y rastreables. 00:20:20.900 --> 00:20:26.220 Cada entorno obtiene acceso solo a las conexiones y recursos correctos, y cualquier cambio se 00:20:26.220 --> 00:20:27.800 registra bajo esta cuenta robot. 00:20:28.660 --> 00:20:32.800 Cuando algo falla, tienes una pista de auditoría clara y no terminas con flujos huérfanos que 00:20:32.800 --> 00:20:33.660 nadie puede arreglar. 00:20:34.700 --> 00:20:38.880 Sobre el problema de mapear conectores, considera que sucede cuando los entornos se desvían 00:20:38.880 --> 00:20:39.360 entre sí. 00:20:39.860 --> 00:20:40.260 Entre sí. 00:20:40.760 --> 00:20:43.500 Quizás el equipo de desarrollo obtuvo aprobación por un nuevo conector personista. 00:20:43.820 --> 00:20:45.540 Supongamos que accede a una API de sandbox. 00:20:46.380 --> 00:20:49.980 Cuando llega el momento de pasar a producción, ese conector no solo falta, sino que quizás ni 00:20:49.980 --> 00:20:52.480 siquiera esté permitido por las políticas de datos de la organización. 00:20:52.980 --> 00:20:57.160 Si olvidas volver a mapear, la aplicación llama al endpoint incorrecto o se rompe por 00:20:57.160 --> 00:20:57.680 completo. 00:20:58.780 --> 00:21:01.000 Vi que esto afectó gravemente a un grupo de atención médica recientemente. 00:21:01.640 --> 00:21:04.800 Un mapeo de conector omitido provocó el uso de datos de prueba en producción y casi 00:21:04.800 --> 00:21:06.300 generó un incidente de cumplimiento. 00:21:07.240 --> 00:21:11.000 Su canalización automatizada exportó todo según lo planeado, pero la referencia del 00:21:11.000 --> 00:21:14.900 conector dentro de la solución aún apuntaba a una base de datos de prueba antigua que Power 00:21:14.900 --> 00:21:17.960 Platform no marcó hasta que los datos reales comenzaron a fluir por los conductos 00:21:17.960 --> 00:21:19.380 incorrectos incorrectos. 00:21:20.080 --> 00:21:22.780 Las variables de entorno intervienen para aliviar parte de este dolor. 00:21:23.420 --> 00:21:27.640 A diferencia de codificar endpoints o claves API, las variables de entorno te permiten separar 00:21:27.640 --> 00:21:30.260 lo que cambia entre entornos de lo que permanece igual. 00:21:31.060 --> 00:21:34.760 Puedes intercambiar endpoints, claves API u otros secretos con cada despliegue sin tener 00:21:34.760 --> 00:21:36.860 que reescribir tu aplicación o flujo. 00:21:38.020 --> 00:21:42.040 Por ejemplo, un flujo que funciona con una tabla de Dataverse de desarrollo puede reconfigurarse 00:21:42.040 --> 00:21:46.120 al importar para usar la tabla de producción simplemente cambiando la variable de entorno en tu 00:21:46.120 --> 00:21:50.440 proceso de despliegue. Las canalizaciones de GitHub Actions hacen que esto sea práctico. 00:21:50.780 --> 00:21:55.040 Cada trabajo puede inyectarle valor correcto en el momento adecuado, pero incluso aquí la disciplina 00:21:55.040 --> 00:21:59.580 es clave. Si olvidas actualizar una variable o permites que los secretos se filtren entre 00:21:59.580 --> 00:22:04.980 entornos, de repente tu flujo de trabajo queda expuesto. Microsoft enfatiza la necesidad de 00:22:04.980 --> 00:22:08.480 limitar cuidadosamente los secretos y mapear intencionalmente las referencias de los conectores. 00:22:09.520 --> 00:22:13.460 Sus políticas de prevención de pérdida de datos, DLP, existen por una razón, para evitar que la 00:22:13.460 --> 00:22:17.200 información confidencial pase de un entorno a otro o aparezca en el lugar incorrecto o aparezca 00:22:17.200 --> 00:22:22.560 en el lugar incorrecto. Si intentas evitarlas compartiendo variables o conexiones, tropezarás 00:22:22.560 --> 00:22:28.020 con los controles de seguridad o cumplimiento corporativo. Más importante aún, pierdes 00:22:28.020 --> 00:22:31.160 predictibilidad porque ya no existe una línea entre lo destinado al desarrollo frente a las 00:22:31.160 --> 00:22:36.320 pruebas o la producción. El beneficio cuando haces todo esto bien es difícil de exagerar. 00:22:37.120 --> 00:22:40.280 Los principios de servicio combinados con variables de entorno bien gestionadas y conectores 00:22:40.280 --> 00:22:45.140 mapeados correctamente transforman tu canalización. Tus despliegues se vuelven predecibles. Cuando 00:22:45.140 --> 00:22:48.580 las cosas se rompen, tienes una cadena de custodia clara y sabes exactamente dónde buscar. 00:22:49.120 --> 00:22:53.820 ¿Fue un mapeado de conector, una variable o un permiso emitido? Los auditores pueden seguir 00:22:53.820 --> 00:22:57.300 los cambios si no hay incertidumbre cuando alguien deja la organización o cambia sus contraseñas. 00:22:57.940 --> 00:23:01.620 Todo se reduce a manejar los secretos, conectores y principios de servicio como si fueran importantes.