2

I have a project that uses Entity Framework 6.x, ASP .NET WebApi 5.x. Data Access is in a secondary project inside the solution. I want to use VSTS (aka Visual Studio Online) to build and release it as a website to environments for integration/dev, qa, stage, and production. There are some great videos on Channel 9 that deal with the generic high-level description. (for example https://channel9.msdn.com/Series/DevOps-Release-Management and https://channel9.msdn.com/Series/DevOps-Fundamentals/Infrastructure-as-Code) There are all kinds of articles and videos about how to do migrations from inside Visual Studio including generating scripts.

Searching around the web I don't even find any older resources or concrete examples of continuous deployment with code first migrations. There must be examples and best practices for methods other than auto-migrations or SQL scripts.

I have configured a Web Deployment Package publish profile. I use it via the PublishProfile msbuild.exe directive. The package is added to the artifacts and then deployed by the Azure Web App Deployment task in each Release environment. However once this package is built, I don't know of a way of changing the connection string in the build package for each time it is released to an environment.

There is probably something I am overlooking, but how should environment specific migrations be done with via VSTS Release?

Zoe
  • 27,060
  • 21
  • 118
  • 148
AC4
  • 642
  • 1
  • 7
  • 22
  • I found this on user voice: http://j.mp/1PAQXjJ it seems to indicate that something for this is in the works? – AC4 Feb 03 '16 at 21:25

2 Answers2

0

For Code First Migration, you can "Write App_Start code to run Migrations" or "Write Web.config transforms to configure the MigrateDatabaseToLatestVersion initializer to run", refer to this article for details: http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx

For the connection string transformation with profile, you need to add a web.config file for the publish profile and then enter the connection string in this web.config. Refer to this link for details: http://awaitwisdom.com/publish-profile-config-transform/

Eddie Chen - MSFT
  • 29,708
  • 2
  • 46
  • 60
  • The issue with having a web.config with the publish profile is that I want to follow the practice of using the same bits in every environment. Thus I only have one Web Deployment Package profile. If I am thinking of it correctly, wouldn't I have to have a separate publish profile for each 'environment'? – AC4 Jan 12 '16 at 23:26
  • @DrydenMaker Can you explain a bit more details on this? Web.config can be transformed by the profile or configuration. Do you mean you want the web.config transformed by the configuration rather than profile? – Eddie Chen - MSFT Jan 13 '16 at 01:13
  • Sure. It is probably just my lack of understanding surrounding VSTS Build and Release. I have a step in 'Build' that creates all the assemblies and publishes them as artifacts. It also creates the deployment package. I want to use this exact deployment package in all my environments (dev, integration, qa, uat, production). The issue is triggering migrations with the correct connection string for the environment. – AC4 Jan 13 '16 at 23:31
  • @DrydenMaker Get it. Then you can use Parameterization to do this. See this link for details: http://vishaljoshi.blogspot.com/2010/07/web-deploy-parameterization-in-action.html – Eddie Chen - MSFT Jan 14 '16 at 01:46
  • I will be trying this in the next couple days, I will let you know how it goes. – AC4 Jan 20 '16 at 22:42
  • I don't see how to set the parameters in an automated way. From the documentation you have a single SetParameters.xml. I would prefer to set the parameters via 'Additional Arguments'. Is there a way to do this? Otherwise I could hack it in with a batch file that renames the needed parameter file to SetParameters.xml? – AC4 Feb 03 '16 at 21:16
  • Web.config transforms are a no-go if you don't want to check-in your connection string. I don't see Parameters working for automated deployments, particularly Azure deployments where you don't have access to IIS. App_Start isn't the best solution, but it could work in some scenarios. I'm working with Azure Functions, so that won't work for me either. – Dan Friedman Apr 21 '17 at 04:17
0

I hate to answer my own questions here but, ultimately my research took me to the conclusion I am posting at length here. In sort, Web.config and Parameters.xml require some custom scripting that will require you to maintain your own deployment automation. These routes will still require you to additionally create your resource groups or manage them manually.

To avoid these complications and cobbling tools and scripts together, the whole operation can be achieved with two JSON files. These JSON deployment templates allow you to create or update your resource group when your deployment runs. They also allow you to automate setting appsettings and connectionstrings that overwrite your Web.config values in the same manner as you can through the Azure Portal.

the steps: (1) Add the two JSON files to the project setting the name of you connection string on line 88 (2) Add a Azure Resource Group Deployment task to the Release environment. (3) Set Template (WebSite.json) and Template Parameters (WebSite.parameters.json) paths in the task. (4) Set Override Template parameters to -hostingPlanName "myHostingPlan" -webSiteName "myWebsiteName" -connectionString "the-actual-connection-string" (5) make sure you are using the same website name in your Azure App Deployment task.

This does depend on having your code first migrations run via App_Start or something similar. I took the first part of @Eddie's suggestion since App_Start is easy to deal with and doesn't seem to run too often.

As a bonus you can add environment variables for any of this configuration so you can clone the environment and then just change the variables. This ultimately makes your application or api connection string a Release variable.

Jed Fox
  • 2,979
  • 5
  • 28
  • 38
AC4
  • 642
  • 1
  • 7
  • 22