Procedimientos recomendados de administración del ciclo de vida
En este artículo se proporcionan instrucciones para los creadores de análisis y datos que administran su contenido a lo largo de su ciclo de vida en Microsoft Fabric. El artículo se centra en el uso de la integración de Git para las canalizaciones de implementación y control de código fuente como herramienta de versión. Para obtener instrucciones generales sobre la publicación de contenido empresarial, vea Publicación de contenido empresarial.
Importante
Esta característica se encuentra en versión preliminar.
El artículo se divide en cuatro secciones:
Preparación del contenido: prepare el contenido para la administración del ciclo de vida.
Desarrollo: conozca las mejores formas de crear contenido en la fase de desarrollo de las canalizaciones de implementación.
Prueba: aprenda cómo usar una fase de prueba de las canalizaciones de implementación para probar el entorno.
Producción: use una fase de producción de las canalizaciones de implementación para poner el contenido a disposición para su consumo.
Preparación del contenido
Para preparar mejor el contenido para la administración continua a lo largo de su ciclo de vida, revise la información de esta sección antes de:
Publicar el contenido en producción.
Empezar a usar una canalización de implementación para un área de trabajo específica.
Desarrollo independiente entre equipos
Los distintos equipos de la organización suelen tener diferentes conocimientos, propiedad y métodos de trabajo, incluso cuando trabajan en el mismo proyecto. Es importante establecer límites a la vez que se da a cada equipo su independencia para que funcione como quiera. Considere la posibilidad de tener áreas de trabajo independientes para distintos equipos. Con áreas de trabajo independientes, cada equipo puede tener permisos diferentes, trabajar con diferentes repositorios de control de código fuente y enviar contenido a producción en una cadencia diferente. La mayoría de los elementos pueden conectarse y usar datos entre áreas de trabajo, por lo que no se bloqueará la colaboración en los mismos datos y proyectos.
Planeamiento del modelo de permiso
Tanto la integración de Git como las canalizaciones de implementación requieren permisos diferentes a solo los permisos del área de trabajo. Obtenga información sobre los requisitos de permisos para las integración de Git y canalizaciones de implementación.
Para implementar un flujo de trabajo seguro y sencillo, planee quién obtiene acceso a cada parte de los entornos que se usan, tanto el repositorio de Git como las fases de desarrollo, pruebas y producción en una canalización. Algunas consideraciones a tener en cuenta son las siguientes:
¿Quién debe tener acceso al código fuente en el repositorio de Git?
¿Qué operaciones deben realizar los usuarios con acceso de canalización en cada fase?
¿Quién está revisando el contenido en la fase de prueba?
¿Tienen acceso los revisores de la fase de pruebas a la canalización?
¿Quién supervisará la implementación en la fase de producción?
¿Qué área de trabajo asigna a una canalización o se conecta a Git?
¿A qué rama se conecta el área de trabajo? ¿Cuál es la directiva definida para esa rama?
¿Varios miembros del equipo comparten el área de trabajo? ¿Deben realizar cambios directamente en el área de trabajo o solo a través de solicitudes de incorporación de cambios?
¿En qué fase está asignando el área de trabajo?
¿Necesita realizar cambios en los permisos del área de trabajo que está asignando?
Conexión de distintas fases a diferentes bases de datos
Una base de datos de producción siempre debe ser estable y estar disponible. Es mejor no sobrecargarlo con las consultas generadas por los creadores de BI para sus modelos semánticos de desarrollo o de prueba. Cree bases de datos separadas para desarrollo y pruebas, con el fin de proteger los datos de producción y no sobrecargar la base de datos de desarrollo con todo el volumen de datos de producción.
Uso de parámetros para configuraciones que cambiarán entre fases
Siempre que sea posible, agregue parámetros a cualquier definición que pueda cambiar entre fases de desarrollo, pruebas y producción. El uso de parámetros le ayuda a cambiar las definiciones fácilmente al mover los cambios a producción. Aunque todavía no hay ninguna manera unificada de administrar parámetros en Fabric, se recomienda usarlo en elementos que admitan cualquier tipo de parametrización.
Los parámetros tienen diferentes usos, como definir conexiones a orígenes de datos o a elementos internos de Fabric. También se pueden usar para realizar cambios en las consultas, filtros y el texto que se muestra a los usuarios.
En las canalizaciones de implementación, puede configurar reglas de parámetros para establecer diferentes valores para cada fase de implementación.
Desarrollo
En esta sección se proporcionan instrucciones para trabajar con las canalizaciones de implementación y utilizarlas en función de la fase de desarrollo en la que se encuentre.
Copia de seguridad del trabajo en un repositorio de Git
Con la integración de Git, cualquier desarrollador puede realizar una copia de seguridad de su trabajo confirmando en Git. Para hacer una copia de seguridad de su trabajo correctamente en Fabric, siga estas reglas básicas:
Asegúrese de que tiene un entorno aislado en el que trabajar, para que otros no sobrescriban el trabajo antes de confirmarlo. Esto significa trabajar en una herramienta de escritorio (como VS Code, Power BI Desktop u otras) o en un área de trabajo independiente a la que otros usuarios no puedan acceder.
Confirme en una rama que haya creado y que ningún otro desarrollador esté usando. Si usa un área de trabajo como entorno de creación, lea sobre cómo trabajar con ramas.
Confirme los cambios que se deben implementar juntos. Este consejo se aplica a uno o a varios elementos relacionados con el mismo cambio. La confirmación conjunta de todos los cambios relacionados puede ayudarle más adelante al realizar la implementación en otras fases, crear solicitudes de incorporación de cambios o revertir los cambios.
Las confirmaciones grandes pueden alcanzar un límite máximo de tamaño de confirmación. Tenga en cuenta el número de elementos que se confirman juntos o el tamaño general de un elemento. Por ejemplo, los informes pueden aumentar de tamaño al agregar imágenes grandes. Es una mala práctica almacenar elementos de gran tamaño en sistemas de control de código fuente, incluso si funciona. Considere formas de reducir el tamaño de los elementos si tienen muchos recursos estáticos, como imágenes.
Revirtiendo cambios
Después de realizar una copia de seguridad del trabajo, puede haber casos en los que quiera revertir a una versión anterior y restaurarla en el área de trabajo. Hay varias maneras de revertir a una versión anterior:
Botón Deshacer: la operación Deshacer es una manera fácil y rápida de revertir los cambios inmediatos realizados, siempre y cuando aún no se hayan confirmado. También puede deshacer cada elemento por separado. Obtenga más información sobre la operación de deshacer.
Revertir a confirmaciones anteriores: no hay ninguna manera directa de volver a una confirmación anterior en la interfaz de usuario. La mejor opción es promover una confirmación anterior para que sea HEAD mediante git revert o git reset. Esto muestra que hay una actualización en el panel de control de código fuente y puede actualizar el área de trabajo con esa nueva confirmación.
Como los datos no se almacenan en Git, tenga en cuenta que revertir un elemento de datos a una versión anterior podría interrumpir los datos existentes y requerir que quite los datos, o causar un error en la operación. Compruébelo de antemano antes de revertir los cambios.
Trabajar con un área de trabajo "privada"
Cuando quiera trabajar de forma aislada, use un área de trabajo independiente como entorno aislado. Obtenga más información sobre cómo aislar el entorno de trabajo en trabajar con ramas. Para obtener un flujo de trabajo óptimo para usted y su equipo, tenga en cuenta lo siguiente:
Configuración del área de trabajo: antes de empezar, asegúrese de que puede crear una nueva área de trabajo (si aún no tiene una), que puede asignarla a una capacidad de Fabric y que tiene acceso a los datos para que funcionen en el área de trabajo.
Creación de una rama: cree una nueva rama desde la rama principal, ya que así tendrá la versión más actualizada del contenido. Asegúrese también de conectarse a la carpeta correcta de la rama, de modo que pueda extraer el contenido correcto en el área de trabajo.
Cambios pequeños y frecuentes: Es un procedimiento recomendado de Git para realizar pequeños cambios incrementales que sean fáciles de combinar y menos probabilidades de entrar en conflictos. Si no es posible, asegúrese de actualizar la rama desde la rama principal para que pueda resolver los conflictos por su cuenta en primer lugar.
Cambios de configuración: si es necesario, cambie las configuraciones del área de trabajo para ayudarle a trabajar de forma más productiva. Algunos cambios pueden incluir la conexión entre elementos o a orígenes de datos diferentes o cambios en los parámetros de un elemento determinado. Recuerde que todo lo que confirme formará parte de la confirmación y se puede combinar accidentalmente en la rama principal.
Uso de herramientas de cliente para editar el trabajo
En el caso de elementos y herramientas que lo admiten, es posible que sea más fácil trabajar con herramientas de cliente para la creación, como Power BI Desktop para modelos semánticos e informes, VSCode para cuadernos, etc. Estas herramientas pueden ser su entorno de desarrollo local. Después de completar el trabajo, inserte los cambios en el repositorio remoto y sincronice el área de trabajo para cargar los cambios. Solo tiene que asegurarse de que está trabajando con la estructura admitida del elemento que está creando. Si no está seguro, primero clone un repositorio con contenido ya sincronizado con un área de trabajo y, a continuación, empiece a crear desde allí, donde la estructura ya está en su lugar.
Administración de áreas de trabajo y ramas
Puesto que un área de trabajo solo se puede conectar a una sola rama a la vez, se recomienda tratar esto como una asignación 1:1. Sin embargo, para reducir la cantidad de área de trabajo que implica, tenga en cuenta estas opciones:
Si un desarrollador configura un área de trabajo privada con todas las configuraciones necesarias, puede seguir usando esa área de trabajo para cualquier rama futura que cree. Cuando un sprint termine, los cambios se hayan combinado y esté iniciando una nueva tarea, simplemente cambie la conexión a una nueva rama en la misma área de trabajo. También puede hacerlo si de repente necesita corregir un error en medio de un sprint. Piense en ella como un directorio de trabajo en la web.
Los desarrolladores que usan una herramienta de cliente (como VS Code, Power BI Desktop u otras), no necesitan siempre un área de trabajo. Pueden crear ramas y confirmar los cambios en esa rama localmente, insertarlas en el repositorio remoto y crear una solicitud de incorporación de cambios en la rama principal, todas sin un área de trabajo. Un área de trabajo solo es necesaria como entorno de prueba para comprobar que todo funciona en un escenario real. Depende de usted decidir cuándo debería ocurrir.
Duplicación de un elemento en un repositorio de Git
Para duplicar un elemento en un repositorio de Git:
- Copie todo el directorio de elementos.
- Cambie el logicalId a algo único para esa área de trabajo conectada.
- Cambie el nombre para mostrar para diferenciarlo del elemento original y evitar un error de duplicidad en el nombre para mostrar.
- Si es necesario, actualice el logicalId o los nombres para mostrar de cualquier dependencia.
Prueba
En esta sección se proporcionan instrucciones para trabajar con una fase de prueba de canalizaciones de implementación.
Simulación del entorno de producción
Es importante ver cómo afectará el cambio propuesto a la fase de producción. Una fase de prueba de canalizaciones de implementación permite simular un entorno de producción real con fines de prueba. También puede simularlo mediante la conexión de Git a un área de trabajo adicional.
Asegúrese de que estos tres factores se aborden en el entorno de prueba:
Volumen de datos
Volumen de uso
Una capacidad similar a la de producción
Al realizar pruebas, puede usar la misma capacidad que la fase de producción. Sin embargo, si se utiliza la misma capacidad, puede hacer que la producción sea inestable durante las pruebas de carga. Para evitar una producción inestable, realice las pruebas en una capacidad diferente que sea similar en recursos a la capacidad de producción. Para evitar costos extra, use una capacidad donde pueda pagar solo por el tiempo que duren las pruebas.
Uso de reglas de implementación con un origen de datos real
Si usa la fase de prueba para simular un uso de datos de la vida real, es mejor separar los orígenes de datos de desarrollo y prueba. La base de datos de desarrollo debe ser relativamente pequeña y la base de datos de prueba debe ser lo más parecida posible a la base de datos de producción. Use reglas de origen de datos para cambiar los orígenes de datos en la fase de prueba o parametrizar la conexión si no se trabaja a través de canalizaciones de implementación.
Comprobación de elementos relacionados
Los cambios que realice también pueden afectar a los elementos dependientes. Durante las pruebas, compruebe que los cambios no afecten o interrumpan el rendimiento de los elementos existentes, que pueden depender de los actualizados.
Puede buscar fácilmente los elementos relacionados mediante el análisis de impacto.
Actualización de elementos de datos
Los elementos de datos son elementos que almacenan datos. La definición del elemento en Git define cómo se almacenan los datos. Al actualizar un elemento del área de trabajo, se importa su definición en el área de trabajo y se aplica en los datos existentes. La operación de actualización de elementos de datos es la misma para las canalizaciones de Git e implementación.
Dado que los distintos elementos tienen diferentes funcionalidades en lo que respecta a la retención de datos cuando se aplican cambios en la definición, tenga esto en cuenta al aplicar los cambios. Algunas prácticas que pueden ayudarle a aplicar los cambios de la manera más segura:
Conozca de antemano cuáles son los cambios y cuáles podrían ser sus efectos en los datos existentes. Use mensajes de confirmación para describir los cambios realizados.
Para ver cómo ese elemento controla el cambio con datos de prueba, cargue primero los cambios en un entorno de desarrollo o prueba.
Si todo va bien, también se recomienda comprobarlo en un entorno de ensayo, con datos reales (o lo más cerca posible), para minimizar los comportamientos inesperados en producción.
Tenga en cuenta el mejor momento al actualizar el entorno de Producción para minimizar los daños que pueden causar errores a los usuarios empresariales que consumen los datos.
Después de la implementación, las pruebas posteriores a la implementación en Producción comprueban que todo funcione según lo previsto.
Algunos cambios siempre se considerarán cambios importantes. Esperemos que los pasos anteriores le ayuden a realizar un seguimiento antes de la producción. Cree un plan para aplicar los cambios en Producción y recuperar los datos para volver al estado normal y minimizar el tiempo de inactividad para los usuarios empresariales.
Prueba de la aplicación
Si va a distribuir contenido a los clientes finales por medio de una aplicación, revise la nueva versión de la aplicación antes de que llegue a producción. Puesto que cada fase de una canalización de implementación tiene su propia área de trabajo, puede publicar y actualizar fácilmente las aplicaciones para las fases de desarrollo y pruebas. La publicación y actualización de las aplicaciones le permite probar la aplicación desde el punto de vista del usuario final.
Importante
El proceso de implementación no incluye la actualización del contenido o la configuración de la aplicación. Para aplicar cambios al contenido o a la configuración, debe actualizar manualmente la aplicación en la fase requerida de la canalización.
Producción
En esta sección se proporcionan instrucciones para la fase de producción de canalizaciones de implementación.
Administración de quién puede realizar la implementación en producción
Como la implementación en producción debe controlarse con cuidado, se recomienda que solo personas específicas administren esta operación sensible. Sin embargo, es probable que quiera que todos los creadores de BI de un área de trabajo específica tengan acceso a la canalización. Utilice los permisos del área de trabajo en producción para administrar los permisos de acceso. Otros usuarios pueden tener un rol de visor de áreas de trabajo de producción para ver el contenido del área de trabajo, pero no realizar cambios en las canalizaciones de Git o de implementación.
Además, debe limitar el acceso al repositorio o la canalización concediendo permisos para la canalización solo a los usuarios que forman parte del proceso de creación de contenido.
Establecimiento de reglas para garantizar la disponibilidad de la fase de producción
Las reglas de implementación son una manera eficaz de garantizar que los datos de producción estén siempre conectados y disponibles para los usuarios. Con las reglas de implementación aplicadas, las implementaciones se pueden ejecutar mientras tenga la seguridad de que los clientes finales podrán ver la información pertinente sin perturbaciones.
Asegúrese de establecer reglas de implementación de producción para orígenes de datos y parámetros definidos en el modelo semántico.
Actualización de la aplicación de producción
La implementación en una canalización a través de la UI actualiza el contenido del área de trabajo. Para actualizar la aplicación asociada, use la API de canalizaciones de implementación. No es posible actualizar la aplicación a través de la interfaz de usuario. Si usa una aplicación para la distribución de contenido, no se olvide de actualizar la aplicación después de implementarla en producción, para que los usuarios finales puedan usar inmediatamente la versión más reciente.
Implementación en producción mediante ramas de Git
Como el repositorio actúa como "origen único de verdad", es posible que algunos equipos quieran implementar actualizaciones en distintas fases directamente desde Git. Esto es posible con la integración de Git, con algunas consideraciones:
Se recomienda usar ramas de versión. Debe cambiar continuamente la conexión del área de trabajo a las nuevas ramas de versión antes de cada implementación.
Si la canalización de compilación o versión requiere que cambie el código fuente o ejecute scripts en un entorno de compilación antes de la implementación en el área de trabajo, la conexión del área de trabajo a Git no le ayudará.
Después de implementar en cada fase, asegúrese de cambiar toda la configuración específica de esa fase.
Correcciones rápidas del contenido
A veces surgen problemas en producción que requieren una corrección rápida. La implementación de una corrección sin probarla primero es una práctica incorrecta. Por tanto, implemente siempre la corrección en la fase de desarrollo e insértela en el resto de las fases de la canalización de implementación. La implementación en la fase de desarrollo permite comprobar que la corrección funciona antes de implementarla en producción. La implementación en toda la canalización solo tarda unos minutos.
Si usa la implementación desde Git, se recomienda seguir los procedimientos descritos en Adopción de una estrategia de ramificación de Git.
Contenido relacionado
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de