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
バッドをするには、ログインかつ
こちらの条件を満たす必要があります。