Skip to main content

Ensure your migrations are linear across environments.

Project description

======================== django_migralign

Imagine you fall into situation where you are working in a big team, Both teams are working on different branchs BUT when both of you deploy one of you will get conflict because there will be 2 migrations point to the same dependency.

Or another situation where you deploy migration 002 and 003 on DEV and the other team deploy 004 and 005, But the other team deployed first on UAT or Prod, they will need to change the file name and dependency as well, And when u deploy your files you gonna do the exact same thing, So your migration order will not be the same across the servers.


Make sure your migration files are stable and linear across different environments with django-migralign.

Requirements

Python 3 and upwards.

Installation

First, install with pip:

.. code-block:: bash

python -m pip install django_migralign

Second, add the app to your INSTALLED_APPS setting:

.. code-block:: python

INSTALLED_APPS = [
    ...,
    "django_migralign",
    ...,
]

The package is a middle command that should run between makemigrations and migrate, the package expects a variable in your settings file called INSTALLED_PROJECT_APPS, That variable should have all your apps that contain migration files.

.. code-block:: python

# project/settings/base.py
INSTALLED_PROJECT_APPS = ['first_app', 'second_app', ...]

INSTALLED_APPS = INSTALLED_PROJECT_APPS + THIRD_PARTY_APPS + ...
    ...

The package goes through your project as the following:

First : It get's all you project apps and goes into each app migration folder and start creating a max_migration.txt file and then query the database to get the last migration applied within the app and saves it inside max_migration.txt file NOTE: max_migration.txt file gets reset each time the command run, But we don't remove it after the command finish working for logging purposes that could help

Second : The app get's all unapplied migrations in the system and order then by file number

Third : After that the package overide the dependencies value to the latest migration applied, And after that it set's that migration name as the max migration in the txt file so it can be used for the next migration in that app (If any!).

Fourth : After handling all migration files you will see prompt with status and will keep the max_migration.txt file in case you need to track or log anything, But the next time you run the command to fix the migration it will get removed and recreated with the correct max migration from database.

Why This Package?

This package focus on solving the migration errors by making sure each migratino file is depending on the last committed migration in the database, So all Nodes will be correct, You Could just edit it manually and regenerate or rename the migration file and change the dependencies but this is going to cause another problem. When doing that you could fall into the following sitiuation:

  • You are working with a team that pushes the code regurally, And both of you could work on the same app which causing new migration files
  • You created migration (002, 003) and the other team created (004, 005), Now Both of you pushed it to DEV env
  • Be aware that 002 will depend on 001 and 004 depends on 003
  • Now the other taem pushed migrations to the UAT or Prod, So they will face conflict because 004 depends on 003 which is not exist
  • The other team will rename 004 to 002 because the UAT only have (001) because you didn't push you migrations yet
  • When the other team renames 004 to 002 and 005 to 0023 and their dependencies as well, Then code will work
  • Now when you deploy your code to UAT (002,003) you gonna get migration conflict because you depend on 001 just like the other team and this will cause conflict
  • So to solve this you have to change dependencies in both of your migration files and the file names as well to 004 and 005

In the above situation the following happend:

  • You manually editted the code and renamed the files
  • The migration files will be different in DEV and UAT

So to solve the above issue just use django_migralign

When using it, It will change dependency on your behalf and will keep file names as it is, So you can align and make sure all migration names and inner code are the same across environments, The package will change dependecies only which will not affect anything in the code, It just matter of ordering.

Usage

You can use the following command: .. code-block:: python python manage.py migralign ...

NOTE: You have to use it after makemigrations and before migrate, So it could align your migrations and making them ready for migrating.

Final Words!

I have made this package because i personally fall into that conflict many times, I have tested it in different scienarios and projects, But maybe there are special cases that are not covered, So in this case please open an ISSUE in this repo to discuss it further and make it work under all circumstances.

Project details


Download files

Download the file for your platform. If you're not sure which to choose, learn more about installing packages.

Source Distribution

django_migralign-1.0.0.tar.gz (7.2 kB view details)

Uploaded Source

Built Distribution

If you're not sure about the file name format, learn more about wheel file names.

django_migralign-1.0.0-py3-none-any.whl (8.3 kB view details)

Uploaded Python 3

File details

Details for the file django_migralign-1.0.0.tar.gz.

File metadata

  • Download URL: django_migralign-1.0.0.tar.gz
  • Upload date:
  • Size: 7.2 kB
  • Tags: Source
  • Uploaded using Trusted Publishing? No
  • Uploaded via: twine/4.0.2 CPython/3.7.5

File hashes

Hashes for django_migralign-1.0.0.tar.gz
Algorithm Hash digest
SHA256 d9eeab2aa5843de83d66fe732ef99e3fbf8378ee0a47e6751f8f32e2cb383950
MD5 b806a70df091895cd05c6a9f3999fe23
BLAKE2b-256 d7de4ef9c4836c08c6ba6f96f037800709fe20f51a9f14ffdb0b3e619ce94ff0

See more details on using hashes here.

File details

Details for the file django_migralign-1.0.0-py3-none-any.whl.

File metadata

File hashes

Hashes for django_migralign-1.0.0-py3-none-any.whl
Algorithm Hash digest
SHA256 f7749d2296470c79752480bb70c2b2bdfffe8f281b068d6be3fcf99f6fba8f97
MD5 499e1c9c71557fa5c7c2c2f27adb5c4c
BLAKE2b-256 f34434ce469d94dfd74208d5fd6cd47b4929051cedf80bd8fe8dbf1f17476993

See more details on using hashes here.

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Depot Continuous Integration Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page