0
votes

I have two DBContext in the same solution. When I run the EF migration command for any of the DBContext locally it executes successfully in under 30 secs.

 dotnet ef migrations script -s $(Build.SourcesDirectory)/MyProject.Web/ --output $(build.artifactstagingdirectory)\myproject-DBScript-$(build.SourceBranchName)\$(build.SourceBranchName)-migrationScript.sql --context DBContext  --idempotent

But when I run the same command as part of azure build it takes anywhere between 7 to 15 minutes. Please note I can see the build logs, it is the actual command which is taking longer and not the agent availability or any tool like dotnet download issue. The build agent is windows with Vs2017.

Why the timeline is different for local and Azure-Devops, is something wrong with the above command or is it the normal time for an EF migration to run on Azure-Devops. Logs

1

1 Answers

0
votes

A Microsoft-hosted agent can take longer to start your build. While it often takes just a few seconds for your job to be assigned to a Microsoft-hosted agent, it can sometimes take several minutes for an agent to be allocated depending on the load on our system.

If Microsoft-hosted agents don't meet your needs, as a workaround you can deploy your own self-hosted agents. Self-hosted agents give you more control to install dependent software needed for your builds and deployments. Also, machine-level caches and configuration persist from run to run, which can boost speed.

Potential performance advantages that you might get by using self-hosted agents which might start and run builds faster. For details ,please refer to this docs.