0
474
VisualizaçõesActualización de base de datos postgreSQL a través de migraciones de EFCore en Azure DevOps
En Azure DevOps, la forma en que solía actualizar la base de datos de SQL Server era con Entity Framework Core, usando dos tareas:
- En mi Build Pipeline: esta tarea generó un script sql con mis migraciones de base de datos.
- En la canalización de lanzamiento: esta tarea para actualizar la base de datos mediante este script.
El caso es que ahora que estoy usando una base de datos PostgreSQL , no puedo encontrar una manera fácil y limpia de actualizar la base de datos de la misma manera. He visto que hay otra tarea para MySQL que hace exactamente lo mismo que hizo mi tarea de canalización de versión con SQL Server, pero nada para PostgreSQL.
Así que pensé que básicamente podría ejecutar la base de datos de dotnet ef update database (con las opciones adecuadas configuradas) en la tubería, pero me preguntaba si realmente hay una manera de seguir actualizando la base de datos sin problemas como lo hice antes.
1 Respostas
Responde à pergunta0
Finalmente pude arreglarlo.
Hay dos soluciones que encontré para solucionar el problema.
- Primero, hay una solución común para todas las bases de datos que admiten las migraciones de Entity Framework :
- Usando una tarea de .NET Core , tendremos que instalar la herramienta dotnet ef : la tarea se vería así:
Y este sería el YAML (en caso de que quiera usarlo fuera de la tubería de lanzamiento):
- task: DotNetCoreCLI@2 displayName: 'dotnet custom' inputs: command: custom custom: tool arguments: 'install --global dotnet-ef --version 3.1.4 --ignore-failed-sources'- Y una vez que tengamos instaladas las herramientas necesarias, con un CMD o una Bash Task, tendremos que ejecutar un script como este:
dotnet ef database update -c <DBCONTEXT> -p <PROJECT> -s <STARTUP_PROJECT> -v --no-buildSolo tiene que agregar el indicador -c en caso de que tenga más de un contexto en su proyecto (a veces, los otros DbContexts pueden provenir de algunos paquetes nugget).
Tenga en cuenta que agregué el indicador --no-build porque ya construí el proyecto en la canalización de compilación para seguir las buenas prácticas.
- La otra opción (y la que finalmente usé), ha sido usar esta tarea que básicamente hace el mismo proceso, con la diferencia de que lo hace usando tus archivos .dll ya compilados, por lo que no tendrás que copiar el todo el proyecto para que las migraciones funcionen. La configuración de la tarea, aunque debe completar muchas entradas, es bastante sencilla y se supone que también funciona con otras bases de datos.
Sin embargo, si tuviera que usar SQL Server o MySQL , usaría un script de migraciones, ya que el proceso es mucho más fácil (solo necesita generar un script .sql y luego es el único archivo requerido para implementar las migraciones).