DevOps ProjectsでDatavase Server Login DetailsのLocationが出ない

Question

AzureのDevOpsでSQL Database有りのASP.NET Coreの新規プロジェクトを作成しようとしています。
DevOps Projectsからプロジェクト作成を行おうとしていますが、最後のCreateページにて、Additional settingsからDatabase Server Login Detailsの入力を行っていますが、Locationのコンボボックスが空です。
アカウントは無料アカウント、サブスクリプションは無料試用版で作成を試みています。
無料は無理、事前準備不足、他項目の入力誤りがあるのでしょうか。

作成の流れは以下になります。
①無料アカウント作成
②DevOps Projectsで「DevOps projectの作成」をクリック
③Runtimeで「.NET」を選択してNext
④Frameworkで「ASP.NET Core」を選択
⑤Frameworkで「Add a database」を有りに変更してNext
⑥Serviceで「Windows Web App」を選択してNext
⑦Createで各種入力

ProjectName：任意
Azure DevOps Organization：任意
Subscription：無料試用版
Web app name：ProjectNameの値と同じ（自動入力）
Location：Japan West

⑧CreateでAdditional settingsをクリック
⑨Additional settingsのDevOps projectに入力

Location：East Asia

⑩Additional settingsのWeb App on Windowsに入力

Resource group：ProjectName + "-rg"（自動入力されている）
Pricing tier：B1 Basic（1 Core, 1.75 GB RAM）
Application Insights Location：Southeast Asia

⑪Additional settingsのDatabase Server Login Detailsに入力

Server name：ProjectName + "-server"（自動入力されている）
Enter username：dbadmin（自動入力されている）
Location：　←コンボボックスが空
Database Name：ProjectName + "-db"（自動入力されている）

Answer 1

問題自体が解決したわけではないのですが、データベースは一旦ソースコード編集で参照設定するようにしました。

Answer 2

When it comes to websites, it's easy to build and deploy in an automated fashion: Check your code in, create the build process, run the website through your pipeline, transform the web.configs (or app.settings), and you are on your way.

It's only after the fact you realize you didn't deploy the database.

Darnit!

Databases have always been a problem when automating deploys. Back in the '90s, it took a little bit of effort to deploy a website with a database (mainly because it was all manual).

How do you automate the process of changing the structure of a database in a DevOps world? What if you need data as well as a schema change?

In today's post, I'll go through a process of how to deploy a database to a database server as well as send it through the Azure DevOps Pipeline.

It's All in the PACs
Before we move forward with a pipeline discussion, we need to understand the SQL Server world a bit.

There are two types of "snapshotting" you can do with a SQL Server database: DACPAC and BACPAC.

A DACPAC file is a snapshot of the database's structure and functionality (stored procedures, views, etc.)

A BACPAC file is a snapshot of the database's structure, functionality, AND data.

It's that simple.

When you create a database project in Visual Studio, it automatically generates a DACPAC for deployment. That's out-of-the-box functionality. You don't need to worry about it.

While I can appreciate how BACPACs work, for our specific project, I felt there wasn't a need for it.

Getting Started
As mentioned, you first need a database project. You can either add it to an existing solution (which we did) or make it a standalone project/solution.

Create a New Project
Under Installed, there should be a SQL Server category. Clicking on it shows the SQL Server Database Project on the right.
Screenshot of New Database Project
Name your project and click OK.
Once your project is loaded, we need a schema. To import the schema into the project,

Right-click on the project.
In the context menu, select "Import..." and pick Database.
Enter your connection details by pressing the "Select Connection..." button (usually, I just select the database and click Start).
Click Start
After showing the details of the import, click Finish.
You now have the entire database schema in your project. Not only that, but you also have a DACPAC.

When you build your database project, guess what? It generates it for you every time.

Screenshot of DACPAC Generated

When you check your code into VSTS, the build server can build the project just like a solution and create the DACPAC for distribution to any of your database environments.

The database structure can be modified.

(How to) Release the Hounds!
Before we get into releasing the DACPAC into the wild, there is one issue we ran into while building our project.

We have an on-premise build server and when we check code in, it immediately starts a build. When completed, it deploys it to DEV. In our solution, we had a .NET Core (API) project and database project in one solution.

While running locally, we could open the solution and compile just fine. However, when we built the solution on the server, we ran into errors.

After a day or two trying to figure out the issue, we broke down and installed Visual Studio 2017 on the server.

As soon as it was done installing, we immediately started a build and it built the solution flawlessly.

Build
To perform the database build, you create the build just as you would your web project.

The only difference is when you finish building your project, you'll have an additional file (DACPAC) to place into a separate artifact folder. you want more detials learn devops online training