@Ahmi Dd A few ways, but the easiest is probably to use a DACPAC when deploying changes to your SQL Database. You can read more here

@John C Not sure there is a best practice with Lakehouse deployments currently, as not much support it given from Microsoft to make it easy (yet), but there are a few workarounds! The approach I go for is to use Notebooks as your deployment object for the Lakehouse. This means creating Notebooks with all your CREATE SCHEMA/ CREATE TABLE logic, and then if you want to update the schema of your tables, use separate "migrations" notebooks for that too (with Spark SQL alter table statements). Use the migration notebook to test the schema changes in TEST - obviously different types of changes will need to be managed differently! This repo from a Microsoft employee is quite nice for explaining additive vs destructive schema-changing. This is the approach we're using for the real-world projects in the Dojo @John C !

@David Allen welcome aboard David - great to have you here!

@Elodie Aumaitre Welcome Elodie!

The Warehouse has the concept of a restore point (read more here), which is kind of similar. Otherwise, the main option is the Disaster Recovery - which replicates data in OneLake (aka Lakehouse and Warehouse) across to a paired region in Azure (see here).

You can use the semantic model refresh activity in a Pipeline, or use Semantic Link Labs