Introduction to database migrations - what, why and how
Database migrations are one of the best ways of altering your database in a reproducible way. When running a migration, you can deploy a multitude of operations, including inserting data, changing tables and schemas, and making sure that the same data schema is available for your whole team across all your environments.
The goal of this module is to give you a good understanding of why you would want to use migrations in your project, and an idea of the common practices. The knowledge we will gain will stand us in good stead when we come to work on a Deno project in a team where a database is utilized.
Why do we need migrations?#
Imagine you are working in a team of two (I know, it's a small team to imagine, but bear with me) and you are creating an application with a database. As you are adding new data models, you are also adding new tables to the database. Now your teammate wants to continue developing the application with some other models, but they also need to use the models and tables you created. Now imagine that having created the tables manually in the database, you now have to explain to your teammate exactly how the tables need to be set up, so that you can both work to the exact same schema. Then imagine that you want to continue with the application, but you need the tables that your teammate developed!
If you are already sweating just thinking about this scenario, just consider how this would play out in a larger team, or when you want to deploy your application to a live production environment. This is exactly the use case for database migrations: a reproducible way of setting up your database with code, no matter the environment or team size.
⚠️ The migration code should never reference any of the code or interfaces used in the rest of the application. This is to ensure that it will run the same migration at any time, no matter the state of the rest of the code at that time.