Git
PowerShell Universal es capaz de sincronizar los scripts de configuración con un repositorio git remoto.
Configuración
Consola de administración
La sincronización con git se puede configurar en la base de datos ajustando la configuración dentro de la consola de administración. Este es el enfoque preferido. La ventaja es que, cuando conecte nuevas instancias de PowerShell Universal a su instancia de SQL, no necesitará configurar de nuevo la sincronización con git.
Para configurar la sincronización con git, navegue a Configuración \ Git dentro de la consola de administración. Podrá hacer clic en el botón Create Git Settings.
appsettings.json
También puede usar la configuración para establecer la sincronización con git. Esto resulta útil si tiene una única instancia de PSU y desea hacer una copia de seguridad de su fichero appsettings.json. Ajustar la configuración dentro de la consola de administración no actualizará el fichero appsettings.json. Deberá hacerlo manualmente y reiniciar PowerShell Universal después de cambiar la configuración.
Si la configuración de sincronización con git se especifica en la base de datos, se ignoran los ajustes definidos en appsettings.json.
Configuración de sincronización con Git
Rama
De forma predeterminada, PowerShell Universal se sincronizará con la rama master. Si desea usar una rama diferente, especifique el ajuste GitBranch dentro de su appsettings.json.
Corregir el seguimiento upstream ausente
Si encuentra el error "There is no tracking information for the current branch", la rama local no está vinculada a la remota. Para corregirlo:
Abra PowerShell en
%ProgramData%\UniversalAutomation\Repository(o la ruta del repositorio configurada)Ejecute:
Remoto
Los remotos no son obligatorios. Si no se especifica un remoto, el repositorio git se almacena localmente en el directorio Repository. Si se especifica, PowerShell Universal se sincronizará con el remoto. Se requieren credenciales adecuadas para acceder a ese remoto.
Formato de URL de Azure DevOps
Los repositorios de Azure DevOps deberían usar el formato de URL moderno dev.azure.com en lugar del dominio heredado visualstudio.com:
Formato correcto:
Ejemplos:
Si el nombre de su repositorio contiene espacios, deben codificarse como %20 en la URL. Evite usar URL con el dominio antiguo visualstudio.com, ya que pueden provocar bucles de redirección o fallos de autenticación con el error "too many redirects or authentication replays".
Para Azure DevOps, su token de acceso personal debe tener el ámbito Code (Read & Write). Los tokens de granularidad fina funcionan, pero se recomiendan los PAT clásicos por compatibilidad entre versiones de PSU.
Nota para usuarios de GitLab: si su instancia de GitLab requiere autenticación basada en encabezados, puede que necesite usar la opción de cliente Git externo y configurar los ayudantes de credenciales de Git, ya que el cliente Git integrado de PSU usa autenticación HTTP Basic con el PAT como contraseña. Algunas configuraciones de GitLab esperan en su lugar un encabezado Private-Token.
Autenticación
Necesitará configurar la autenticación con su repositorio git remoto. Recomendamos un token de acceso personal.
Cliente Git externo
Puede optar por usar un cliente git externo en lugar de la biblioteca integrada en PowerShell Universal. Esto le permite opciones de configuración adicionales, como el uso de autenticación SSH. PowerShell Universal no usará el nombre de usuario, las contraseñas ni los PAT configurados al habilitar este método. Necesitará tener instalado un cliente git.
Uso de claves SSH
Puede usar PowerShell Universal para generar y gestionar claves SSH. Dentro de la consola de administración, haga clic en Platform \ SSH Keys. Genere una nueva clave SSH. A continuación, haga clic en el botón de copiar junto a la clave SSH para obtener la clave pública.
Registre la clave pública con el repositorio o la cuenta de destino. Por ejemplo, puede seguir la guía de GitHub aquí.
Dentro de la ventana de configuración de Git, seleccione la clave SSH que desea usar con la sincronización con git. Cuando use claves SSH, asegúrese de que se selecciona la URL SSH para clonar su repositorio.
Establecer credenciales
Cuando use el cliente git externo, usted es responsable de configurar las credenciales antes de realizar una sincronización.
Puede configurar las credenciales mediante la configuración de git o la URL pasada a PowerShell Universal.
El siguiente comando almacenará las credenciales en texto plano en el servidor de PowerShell Universal. Deberá ejecutar este comando como el usuario de la cuenta de servicio para que tenga acceso a las credenciales. Esto creará un fichero .git-credentials que se usará al autenticarse contra la URL de destino. Puede que necesite cambiar la URL en función de su remoto git.
También puede almacenar las credenciales directamente en la URL proporcionada a PowerShell Universal.
Ejemplo: nombre de usuario y PAT
Para usar un cliente git externo y pasar un nombre de usuario y un PAT con los que autenticarse, puede especificarlos en la URL del remoto git. Por ejemplo:
Ejemplo: SSH y GitHub
En primer lugar, necesitará configurar su ssh-agent local y su cuenta de GitHub con claves SSH.
Puede seguir su guía aquí.
A continuación, proporcionará un URI SSH para la URL del remoto git en PowerShell Universal. La clave SSH configurada se usará para la conexión.
Problema con el certificado SSL
SSL Certificate problem: unable to get local issuer certificate
Si está ejecutando en Windows y recibe un problema con el certificado SSL, puede que necesite asegurarse de que ha habilitado el soporte de schannel.
Persistencia de credenciales
Unable to persist credentials with the 'wincredman' credential store.
Si está en Windows y recibe un error acerca de la persistencia de credenciales en wincredman, puede que necesite establecer la persistencia de credenciales en DAPI. Puede aprender cómo hacerlo aquí.
Modo manual
El modo manual requiere que los usuarios que editen la instancia de PowerShell Universal hagan clic en Edit para realizar cambios en el sistema.
Una vez completados los cambios, el usuario puede hacer clic en Save Changes para iniciar un commit
En la página de commit de git, puede ver los ficheros modificados e introducir un mensaje de commit.
Una vez que se han confirmado los cambios, se enviarán al remoto y el servicio comenzará a sincronizarse de nuevo con git. También existe la posibilidad de que se produzca un conflicto de fusión de git en ese momento. Consulte Tratar los conflictos para obtener más información.
El modo manual se puede establecer en la configuración de git dentro de la consola de administración o dentro de appsettings.json.
Método uno: enviar ficheros locales al remoto
Debe asegurarse de que su carpeta local no sea un repositorio git preexistente. Su directorio de repositorio debería ser simplemente una carpeta con sus ficheros de PowerShell Universal. Si existe una carpeta .git y no desea usar ese repositorio, debería eliminarla y PowerShell Universal creará un nuevo repositorio.
Si está poblando un nuevo repositorio git, debe asegurarse de que el remoto no tenga ningún fichero en él. Debería ser un repositorio completamente vacío. Por ejemplo, al crear un repositorio en GitHub, no seleccione la creación de una licencia ni de un fichero readme.md.
Una vez creado el repositorio, puede obtener la URL del remoto git y proporcionarla al fichero appsettings.json de PowerShell Universal.
Una vez que tenga la rama, la URL del remoto git y las credenciales, puede proporcionarlas a su fichero appsettings.json y el remoto git se poblará con sus ficheros locales.
Método dos: extraer desde un remoto Git
Puede configurar PowerShell Universal para extraer desde un remoto git. En esta configuración, debe asegurarse de que su carpeta de repositorio local esté completamente vacía. Cualquier fichero dentro de la carpeta hará que la sincronización con git falle y le impedirá recuperarse.
Configure el fichero appsettings.json para incluir la rama, las credenciales y la URL del remoto git que está clonando. Una vez establecidos los campos, puede iniciar el servicio de PowerShell Universal. Lo primero que hará el servicio será clonar el repositorio y configurarlo localmente.
Tiempo de espera de la sincronización con Git
La sincronización con git superará el tiempo de espera si no puede contactar con el remoto después de 60 minutos. Esto permite disponer de tiempo para descargar repositorios grandes o para retrasos en redes lentas. Puede ver que el servicio de PowerShell Universal se queda bloqueado en "Synchronizing with git" durante el inicio mientras el servidor espera a que esto ocurra. Si desea reducir este tiempo, puede usar el siguiente ajuste de appsetting.json. El valor está en minutos.
Intervalo de sincronización
Tipo: Entero
Predeterminado: 60
appsettings.json: GitSyncInterval
El intervalo, en segundos, entre los intentos automáticos de sincronización con Git cuando la sincronización automática está habilitada. El valor predeterminado es de 60 segundos (1 minuto).
Para ajustar la frecuencia de sincronización, edite appsettings.json:
Esto cambiaría el intervalo de sincronización a 5 minutos. Los valores más bajos aumentan la frecuencia de sincronización, pero pueden afectar al rendimiento en repositorios grandes o redes lentas. No se recomienda establecer este valor demasiado bajo (por debajo de 30 segundos) en entornos de producción.
Solución de problemas
Azure DevOps: "Too many redirects or authentication replays"
Este error normalmente indica uno de los siguientes problemas:
Formato de URL heredado: asegúrese de que está usando
https://dev.azure.com/<org>/<project>/_git/<repo>en lugar del dominio antiguovisualstudio.comÁmbito de PAT no válido: su token de acceso personal debe tener permisos Code (Read & Write) en Azure DevOps
Credenciales caducadas: genere un nuevo PAT y vuelva a introducirlo en la configuración de Git de PSU
Espacios codificados: si el nombre de su repositorio tiene espacios, asegúrese de que están codificados como
%20en la URL
Resolución:
Actualice la URL remota para usar
dev.azure.comGenere un nuevo PAT con el ámbito Code (Read & Write)
Habilite Use External Git Client e instale Git para Windows si el cliente integrado continúa fallando
Seguimiento upstream ausente
Error: "There is no tracking information for the current branch"
Causa: la rama local de Git no está configurada para seguir una rama remota.
Resolución: abra PowerShell en el directorio del repositorio y ejecute:
Sustituya main por el nombre real de su rama. Después, haga clic en Synchronize Now en PSU.
La sincronización con Git se detiene tras cambiar la configuración en la interfaz de usuario
Síntomas: después de editar la configuración de Git (URL remota, credenciales, intervalo de sincronización, etc.) en la interfaz de usuario de PSU y hacer clic en OK, la sincronización deja de funcionar aunque la configuración parezca correcta.
Causa: en PSU 5.x, las credenciales de Git se almacenan en la base de datos SQL. Realizar cualquier cambio en la configuración de Git a través de la interfaz de usuario puede borrar las credenciales almacenadas, incluso si el campo de contraseña sigue apareciendo rellenado en el formulario.
Resolución:
Vuelva a introducir el token de acceso personal en Configuración → Git
Haga clic en OK para guardar
En entornos de varios nodos, repita este proceso en cada nodo: las credenciales deben introducirse individualmente en cada servidor
Haga clic en Synchronize Now para verificar que la sincronización vuelve a funcionar
El sistema no propaga automáticamente las credenciales entre nodos en una configuración con balanceo de carga o de alta disponibilidad.
Problemas de agente y de red
Síntomas: la sincronización funciona en un nodo pero falla en otros, o ve errores RpcException o "service is unavailable" en los registros.
Causas comunes:
Discrepancia de versiones: asegúrese de que todos los servidores y agentes de PSU ejecutan la misma versión
Reglas de cortafuegos: los agentes se comunican con el servidor de PSU mediante gRPC en los puertos 5000 (HTTP) o 5001 (HTTPS)
Bloqueo de proxy o WebSocket: los proxies corporativos pueden bloquear o inspeccionar el tráfico gRPC; configure git para usar el proxy o habilite el cliente Git externo
Resolución:
Verifique que todos los nodos ejecutan la misma versión de PSU
Compruebe que las reglas de cortafuegos permiten el tráfico en los puertos 5000/5001
Pruebe la conectividad gRPC entre nodos
Si usa un proxy, configure las variables de entorno
http_proxyyhttps_proxypara la cuenta de servicio de PSU
Despliegues en Docker y en contenedores
Asegúrese de que la imagen del contenedor incluye
git(ejecutegit --versionpara verificarlo)Verifique el acceso de red saliente al remoto git
Monte volúmenes persistentes para
/datao%ProgramData%\UniversalAutomationpara preservar el estado de git entre reiniciosSi la sincronización falla silenciosamente, revise los registros del contenedor para detectar errores de git o de red
Edición de .git/config sin la CLI de Git
Si la herramienta de línea de comandos de Git no está instalada en el servidor y encuentra errores de seguimiento de la rama upstream, puede editar la configuración del repositorio directamente a través del explorador de ficheros de PSU:
Vaya a Platform → Configuration → Repository → .git → config
Añada las siguientes líneas (ajuste el nombre de la rama para que coincida con su repositorio):
Haga clic en Save
Vuelva a Settings → Git y haga clic en Synchronize Now
Este enfoque le permite configurar el seguimiento de la rama upstream sin necesidad de comandos git, lo cual resulta especialmente útil cuando Git para Windows no está instalado o cuando se ejecuta con cuentas de servicio restringidas.
La configuración de Git no se conserva
Si los cambios en la configuración de Git no se guardan o se revierten inmediatamente después de hacer clic en OK:
Compruebe los permisos del sistema de ficheros:
Detenga el servicio de PowerShell Universal
Intente editar manualmente
%ProgramData%\PowerShellUniversal\appsettings.json(o%ProgramData%\UniversalAutomation\appsettings.jsonen versiones anteriores)Añada una línea de comentario, guarde y vuelva a abrir el fichero para verificar que sus cambios se conservan
Si los cambios se revierten, compruebe si algún software antivirus, objetos de directiva de grupo (GPO) o permisos NTFS están bloqueando la escritura en el directorio de datos de PSU
Habilite el registro de depuración para la resolución de problemas:
Detenga el servicio de PowerShell Universal
Edite
appsettings.jsony establezca:
Guarde y reinicie el servicio
Intente guardar de nuevo la configuración de Git
Revise
%PROGRAMDATA%\PowerShellUniversal\systemLog.txtpara buscar errores relacionados con las escrituras de configuración
Rellene manualmente la configuración de Git:
Con el servicio detenido, puede rellenar directamente los campos de Git en appsettings.json:
Reinicie el servicio y compruebe que la configuración aparece en Settings → Git. Si vuelve a desaparecer, los registros de depuración indicarán si un problema de permisos, un software de protección de puntos finales o un error de validación de la configuración está causando el restablecimiento.
unknown certificate lookup failure: 16777280
Al utilizar la biblioteca git integrada, puede encontrar problemas con el certificado al conectarse a repositorios git alojados localmente. En esta configuración, recomendamos utilizar el cliente git externo para disponer de mayor compatibilidad con la configuración del proceso de búsqueda del certificado.
Ficheros incluidos
Los ficheros que se incluyen en una sincronización de git son todos los ficheros del repositorio local. Esto incluye los ficheros de configuración PS1, los ficheros XML de páginas y cualquier otro fichero que pueda añadir manualmente.
No se incluyen los siguientes:
appsettings.json
database.db
web.config
Binarios de la aplicación PowerShell Universal
Múltiples repositorios Git
PowerShell Universal admite el almacenamiento de múltiples configuraciones de repositorios git en la base de datos. De este modo, puede cambiar rápidamente entre distintas configuraciones de PowerShell Universal. Haga clic en la pestaña Repositories para ver los repositorios configurados actualmente. Desde aquí puede eliminar y editar las configuraciones de los repositorios.
PowerShell Universal no elimina la carpeta .git al eliminar una configuración de repositorio. Deberá hacerlo manualmente para poder configurar un nuevo repositorio.
Cuando añade una nueva configuración de repositorio, puede hacer clic en el botón Apply para cambiar al repositorio seleccionado. Esto eliminará todos los ficheros del directorio del repositorio y clonará el repositorio seleccionado. No puede aplicar una configuración de repositorio si hay cambios sin confirmar en su repositorio. Después de clonar el repositorio, PowerShell Universal recargará completamente su configuración.
Página de historial y estado de Git
La pestaña de historial muestra todo el historial de commits de git del repositorio actual.
La pestaña de estado de sincronización muestra el estado actual de los nodos del clúster de PSU.
Prueba de la sincronización de Git
La mejor forma de asegurarse de que su sincronización de git funciona correctamente es hacer clic en el botón Synchronize Now. Esto forzará la ejecución de una sincronización y podrá verificar si la configuración introducida funcionó correctamente.
Visualización de los cambios
Puede ver los cambios en la tabla de sincronizaciones de git. Cada sincronización incluye el número de cambios encontrados desde la última sincronización, el SHA del commit y una lista de los cambios entre ese SHA y el anterior. Cuando los ficheros están en estado modificado, podrá ver las diferencias mediante la herramienta de comparación de ficheros.
Gestión de conflictos
Cuando varios usuarios editan los ficheros de configuración de PowerShell Universal, pueden producirse conflictos. PowerShell Universal mostrará que un nodo concreto se encuentra en estado de conflicto al intentar confirmar los cambios. Verá una lista de los cambios en conflicto en la página de commits de git. Haga clic en el botón Resolve Conflict para ver el conflicto en un editor.
En este ejemplo, la cadena de este endpoint se editó tanto en el repositorio remoto como en el local.
Edite el texto para eliminar el conflicto.
Guarde los cambios y vuelva a la página de commits de git. Introduzca un nuevo mensaje de commit para el conflicto de fusión y haga clic en Commit Changes.
Esto resolverá el conflicto de fusión y realizará el push al remoto.
Comportamiento de la sincronización de Git
Bidireccional
De forma predeterminada, la sincronización de git funciona en ambos sentidos. Si realiza cambios en la consola de administración de PSU, esos cambios se confirmarán y se sincronizarán con el remoto configurado.
Cualquier cambio realizado en el remoto se descargará localmente.
Si configura la sincronización de git con un remoto de git preexistente, los cambios se descargarán y se sincronizarán localmente. No puede tener ningún cambio localmente.
Si configura la sincronización de git con un repositorio vacío (bare), los cambios locales se sincronizarán y el repositorio se inicializará.
Unidireccional
Puede ajustar el comportamiento de la sincronización de git cambiando el ajuste GitSyncBehavior en appsettings.json. Cuando se establece en OneWay, la consola de administración y la API de gestión pasarán a ser de solo lectura. El sistema PowerShell Universal descargará desde el remoto, pero nunca hará push ni confirmará cambios localmente.
Solo push
El modo de sincronización de git solo push no descargará los cambios del remoto. Cualquier cambio realizado localmente se enviará al remoto. La consola no será de solo lectura. Esta configuración es útil para escenarios en los que se dispone de una máquina que se utiliza como configuración de referencia (fuente de verdad) para un conjunto de servidores de solo lectura.
Token de acceso personal
Recomendamos que utilice un token de acceso personal (PAT) en lugar de un nombre de usuario y una contraseña. Puede configurar un token de acceso personal estableciendo la propiedad de contraseña en appsettings.json u otros métodos de configuración.
Tokens de granularidad fina de GitHub
En GitHub, puede obtener un token de granularidad fina haciendo clic en su avatar en la esquina superior derecha, seleccionando Settings, Developers Settings, Personal Access Tokens y, a continuación, Fine-Grained Tokens.
Ámbitos del token
Al generar el token, asegúrese de otorgar al repositorio el permiso Read-Write sobre Content. Esto añadirá automáticamente el permiso de lectura sobre Metadata. Puede proporcionar acceso únicamente al repositorio que desea clonar.
Tokens de GitHub (clásicos)
En GitHub, puede obtener un token de acceso personal haciendo clic en su avatar en la esquina superior derecha, seleccionando Settings, Developer Settings, Personal Access Tokens y, a continuación, Tokens (Classic).
Al generar su token de acceso, asegúrese de seleccionar los permisos Repo.
Tenga en cuenta que, si utiliza BitBucket, deberá especificar el nombre de usuario además del PAT en appsettings.json.
Nombre de usuario y contraseña
También puede configurar un remoto de git para autenticarse con un nombre de usuario y una contraseña. Establezca el nombre de usuario y la contraseña mediante el fichero appsettings.json u otro método de configuración.
Errores comunes
Git synchronization failed. unknown certificate lookup failure: 16777280
La biblioteca lib2gitsharp no pudo validar el certificado del repositorio git remoto. Deberá utilizar el cliente git externo y una configuración de git personalizada para solucionarlo.
Algunas opciones comunes para la compatibilidad con HTTPS en git incluyen:
"too many redirects" o repeticiones de autenticación
El remoto de git ha rechazado sus credenciales para acceder al repositorio. Puede que su token de acceso personal haya caducado o que no tenga acceso al remoto.
repository not owned by current user
El repositorio git local no tiene los controles de acceso adecuados para el usuario que intenta acceder a él. Esto puede ocurrir si PowerShell Universal clonó el repositorio y después se estableció una cuenta de servicio diferente en el servicio. Como los controles de acceso no coinciden, git no accederá a la carpeta. Se trata de una característica de seguridad de git.
Puede actualizar el propietario de la carpeta para evitarlo o configurar git para que confíe en la carpeta. Establezca el siguiente valor en la configuración global de git.
La configuración global se encuentra en: C:\Program Files\git\etc\gitconfig
Ventajas de la sincronización de Git frente a la sincronización manual de Git
Es posible sincronizar manualmente un repositorio con git. PowerShell Universal utiliza comandos muy básicos al trabajar con git. Cualquier cambio realizado en PowerShell Universal a través de la consola de administración o la API invoca un git commit y el autor se establece como la identidad del usuario que realiza el cambio. Durante una operación de sincronización de git, primero realizamos un git pull para asegurarnos de tener la última versión de los ficheros del remoto. A continuación, realizamos un git push para enviar los commits locales que se hayan producido desde la última sincronización.
Podría lograr esta funcionalidad con un trabajo programado.
Dicho esto, una de las funciones de la sincronización de git es que analiza el commit para asegurarse de que solo se recarguen los ficheros que se modificaron durante la sincronización. Esto evitará que los dashboards se despliguen automáticamente cuando no han cambiado o que los servicios de API se reinicien cuando los entornos no se han actualizado. Por lo tanto, aquí se obtiene una mejora de rendimiento.
El otro problema es que, debido a la forma en que PowerShell Universal vigila los ficheros (con un FileSystemWatcher) y a la forma en que git actualiza los ficheros, las configuraciones no se recargarán automáticamente después de un pull. Tendrá que asegurarse de forzar que las configuraciones se vuelvan a evaluar.
Estrategias de ramificación
Las estrategias de ramificación en git determinan cómo se trasladan los cambios de una rama a otra. Utilizar distintos tipos de estrategias de ramificación en PowerShell Universal puede garantizar que equipos de diferentes tamaños trabajen juntos de forma eficaz en la plataforma.
Usuarios individuales y equipos pequeños
Para usuarios individuales y equipos pequeños, puede que no sea necesario tener más de una única rama. La rama se utiliza para el seguimiento del historial y ofrece la posibilidad de revertir cambios. Los usuarios accederán directamente a PowerShell Universal para realizar cambios o confirmarán los cambios en la rama única desde clones locales del directorio del repositorio utilizando una herramienta como VS Code.
main: rama única que acepta todos los cambios directamente
Usuarios individuales y equipos pequeños con una rama de staging
Incluso los usuarios individuales y los equipos pequeños pueden encontrar ventajoso emplear una rama de staging o dev. Esta rama recibirá los cambios durante el desarrollo. Se configurará una instancia independiente de PowerShell Universal para ejecutarse contra esta rama dev, de modo que los usuarios puedan validar los cambios antes de enviarlos a producción.
Cuando se utiliza una configuración con una rama de staging, los entornos de PowerShell Universal están completamente separados. Utilizan una base de datos y un planificador diferentes. Los datos como las identidades, los tokens de aplicación y el historial de trabajos no se comparten entre los entornos.
A continuación, se puede configurar una instancia separada de PowerShell Universal para que apunte a una rama main, o de producción, que recibirá actualizaciones mediante fusiones o Pull Requests en un sistema como GitHub. En esta configuración, es posible utilizar la sincronización de git unidireccional para descargar los cambios de main, pero sin enviar nunca cambios desde la plataforma. Esto también evita la mayoría de los conflictos de fusión, ya que se resolverán en la rama dev o mediante la herramienta de fusión del repositorio de origen.
main: rama de producción que recibe los cambios de los pull requests de la rama dev
dev: la rama de staging utilizada para aceptar commits y validar los cambios antes de enviarlos a master.
Equipos de tamaño medio a grande
Cuando se trata de equipos con más de un par de desarrolladores, una estrategia de ramificación más compleja puede resultar útil para evaluar mejor los cambios de código y evitar conflictos de fusión. PowerShell Universal proporciona herramientas de fusión básicas, pero existen herramientas mejores para este propósito, como los pull requests de GitHub, los merge requests de GitLab y herramientas locales como GitKraken.
En equipos de tamaño medio, puede ser deseable disponer de ramas de funcionalidades adicionales que aíslen cambios concretos en una rama determinada. Por ejemplo, un desarrollador puede estar creando un nuevo conjunto de APIs para gestionar Azure en PowerShell Universal. Para evitar cambios que rompan la rama dev, los desarrolladores crearán su propia rama de funcionalidad que contenga todos sus cambios hasta que esté lo suficientemente completa para fusionarse en la rama de desarrollo.
En este tipo de configuración, el desarrollo local es ideal, ya que los desarrolladores trabajarán en su instancia local de PowerShell Universal dentro de su rama de funcionalidad. Cuando la funcionalidad esté completa, crearán un Pull o Merge request en el repositorio de origen para trasladar los cambios a la rama dev. Las pruebas se completarán en la rama dev antes de fusionar a producción.
De forma similar a una estrategia de ramificación main\dev, todas las instancias de PowerShell Universal estarán aisladas y no compartirán base de datos ni planificador.
Una vez que un conjunto de funcionalidades esté listo para producción, se realizará un Pull o Merge request de dev a la rama main.
main: rama de producción que solo recibirá cambios de dev
dev: rama de staging que recibe cambios de las ramas de funcionalidades, pero que no se modifica directamente
feature: rama de funcionalidad en la que los desarrolladores confirman directamente y que se fusiona con dev cuando está lista
Según la complejidad de su entorno, puede ser aconsejable utilizar Deployments en lugar de git en producción. Consulte la sección Equipos grandes que aparece más abajo para obtener más información.
Equipos grandes
En equipos grandes, recomendamos utilizar git con fines de desarrollo, pero emplear Deployments, o un concepto similar, para producción.
Deployments proporciona paquetes de configuración inmutables que han sido probados exhaustivamente en entornos de nivel inferior. Al utilizar Deployments, puede elegir cómo desarrolla y gestiona su código y simplemente publicar el resultado en sus entornos de desarrollo, staging, QA y producción. Esto garantiza que todo el código esté bien probado antes de desplegarlo en sus sistemas críticos.
Puede utilizar flujos de trabajo automatizados, como GitHub Actions, para publicar sus Deployments sin tener que actualizar manualmente ningún sistema.
Alojamiento de Git
PowerShell Universal admite cualquier solución estándar de alojamiento de git. Nuestros clientes utilizan con frecuencia las siguientes:
GitHub
GitHub Enterprise
GitLab
Bitbucket
Azure DevOps
Aunque estas son las plataformas más habituales, admitimos cualquier plataforma que utilice el protocolo git.
Ejemplo: Gitea
También puede utilizar soluciones sencillas y autoalojadas como Gitea. Aquí tiene un ejemplo de cómo configurar fácilmente un contenedor docker de Gitea para su uso con PowerShell Universal.
Última actualización
¿Te fue útil?