True. Entity Framework and Entity Framework Core both have built-in support to generate a migration after changes to the schema definition have been made.
False. Most migration-based approaches use an extra table to keep track of which migrations have already been applied to the database.
True. End state-based approaches work by comparing the current schema to the target schema. This results in the generation of a one-time SQL script that is run against the database to update the schema. There is no state stored between runs.
The correct answers are numbers 1 and 2. Running side by side, if done correctly, reduces change risks dramatically. If there are issues, you can always remove all new code, along with the database copy, and restart afresh from a working situation. Having both situations working correctly also allows for very precise performance measurements regarding the production workload. However, one of the disadvantages is that the cycle time is actually very likely to increase. You have to move multiple smaller changes to production one by one, which increases the total time taken.
False. Your schema (either implicit or captured in data objects) still changes. However, this only becomes visible when reading an object back from the database that was persisted with a previous version of the object. In essence, you are only delaying coping with the issue of schema changes.
You can choose to not use database-level coding techniques, such as stored procedures and triggers. The more of your logic you capture outside of the database, the smaller the total number of database changes you have to make.
