Using Code First and Entity Framework, I have created my web application on my dev machine, used migrations and published to my beta application to my production server and database.
Then on my dev system I’ve done lots of changes created several migrations and applied them to my local dev database. When I use update-database this updates my local dev database, but how then do I apply the migrations to my production server database?
I've been using update-database -script to get the SQL to manually apply to my production server. Is there a better way?
You should ideally employ some kind of actual database deployment system like ReadyRoll. Short of that, you should generate SQL scripts that you can commit and deploy manually, preferably via a DBA role in your organization. Code-based migrations can do all sorts of potentially bad things to your database with no notice, but in a SQL script, you can easily see that a table is about to be dropped or a column with lots of irreplaceable data is about to be removed.
Your in Web.config is what establishes which database the application is pointing to. When you point it to production and run the same EF commands (dotnet ef migrations add migrationName, and dotnet ef database update) it should update your production environment.
For my setup I just don't deploy my web.config so in production it always points to production database. When I run the EF update scripts in production it updates production and I'm good to go.
Related
I have a production server in Azure SQL. I have created a another empty server(dev) for development purpose. I need a copy of the tables, views, stored procedure in the dev server as well. Please suggest some way to transfer the data to dev server database
#John11 : You can take a backup of your Production Database and then simply restore on your Dev server
Ideally Production data restore to Dev is not advisable if it is a highly confidential data
If you just need to move the schema without data then you can use DevOps / CI-CD to deploy the artifacts to Dev
I have a Microsoft Azure SQL Database project. I also have a Python3.9 project that uses unittest to unit test this database project. I have an Azure DevOps build pipeline defined in YAML that runs the unit test against the development-integration environment.
I do not want to publish changes to the development-integration environment before running the tests. If you think this is the wrong approach, I will consider your arguments.
I want to 'virtually' test the changes. I want to deploy the new objects to a temporary ad-hoc database instance. It must be equivalent to Azure Database Instance. When the tests have been executed I want to clear everything away. I do not want to deploy a database in Azure for this purpose due to billing, although if I were to use a serverless instance this would not be a problem.
Any ideas?
If you are on cloud and you need to test you need to test that on the cloud too.
You cannot "virtually" test, there is nothing equivalent to Azure SQL database on-prem.
Go with the serverless instance as you said.
I cloned an ASP.NET Core 2 project with git and it uses Entity Framework Core with MySQL database.
services.AddDbContext<ApplicationDbContext>(options =>
options.UseMySql(Configuration.GetConnectionString("Default")));
Is it possible for me to contribute on this project but use my local SQL Server instead of MySQL and don't change this on source?
I tried changing UseMySql to UseSqlServer with the right connection string but it threw exception in migrations.
Not easily. If the application wasn't designed with this scenario in mind, you may have to update a lot of it to work on Microsoft SQL Server.
If you're just trying to avoid installing MySQL locally, I've found using Docker ideal for that. (See the mysql/mysql-server image.)
Hanami has some commands to create a database.
But both db create and db prepare are not available in production environment.
http://hanamirb.org/guides/command-line/database/
How can I create a database in production?
It depends.
We deliberately disabled these commands in production, because they can be potentially destructive and we can't guess where you're gonna deploy your project.
Is that Heroku? Well, add it via their CLI. Do you use a VPS? Is the database on the same node? Does the Unix user who runs the Ruby process have the permissions to create the database? We can't guess.
It depends where you're gonna deploy.
We are a team of two developers, building an ASP.Net MVC app in Azure and are wondering what is the best way to go about setting up the database.
We had been using a local db in the App_Data folder that attached to SQL Express, this seemed to be working fine until it came time to check in and conflicts occur.
We are using git to check into BitBucket and a deployment is ran off the master branch into Azure deploying the database as well.
We were/are using database code first migrations and all the data is seeded.
Can anyone help please?
Moving the discussion to an answer.
Regarding migrations:
I work in a team of 2 developers too. What works for us is at the early stages of development (model changes a lot) each one runs its own database locally (data seeded in the initializer). Once the project is relatively stable, we deploy to a website with a SQL Azure database. Whenever the model changes, we add a migration and run it against that database. Our team, like yours is small so this works for us. If the team grows, I recommend setting up a CI server (Team City).
Regarding Database connections
We don't use the .mdf file in App_Data. Each one has a local instance of SQL server Express running in their machine. For the connection strings, we have 4 environments set up (Local, Development, Staging, Production). These are set in the web.config (you can set them up in code too it's your choice). When we ran the application, we choose the environment we want to develop against. We deploy using VS2013 to an Azure Website, each web.config is configured accordingly per environment.
We get the environment from the web.config and depending on which environment we're at, the connection string is injected into the application using an IOC container (Ninject).
<configuration>
<appSettings>
<add key="environment" value="Development"/>
</appSettings>
</configuration>
Hope this helps,