Backward-Compatible Migrations for Blue-Green Deployments in Django

Your approach to backward-compatible migrations for blue-green deployments is well thought out. Let me provide some insights based on Django's migration capabilities and database backend support.

Database Backend Considerations

Your assumption about using PostgreSQL ≥ 11 is a good choice, as PostgreSQL is the most capable database for schema migrations in Django. As the documentation notes:

PostgreSQL is the most capable of all the databases here in terms of schema support.

Other databases have limitations that could impact your migration strategy:

• MySQL lacks transaction support for schema alterations, making rollbacks difficult if migrations fail
• SQLite has limited schema alteration capabilities and is not recommended for production environments

Your Migration Strategies

Adding Columns

Your approach using RunSQL with state_operations is correct for adding columns with database defaults. This ensures Django's ORM state matches the actual database schema.

For NOT NULL columns without defaults, your three-step approach within a transaction is ideal:

PYTHONCopied
# Within a migration file with atomic=True
operations = [
    migrations.AddField(
        model_name='foo',
        name='quantity',
        field=models.IntegerField(null=True),
    ),
    migrations.RunPython(
        populate_quantity_field,
        reverse_code=migrations.RunPython.noop,
    ),
    migrations.AlterField(
        model_name='foo',
        name='quantity',
        field=models.IntegerField(null=False, default=1),
    ),
]

Deleting and Renaming Columns

Your multi-release approaches for these operations align with best practices for zero-downtime deployments.

Additional Considerations

1. Testing Migrations: Create comprehensive tests that verify both forward and backward migrations work correctly, especially for complex operations.

2. History Consistency: Django will refuse to run migrations if it detects an inconsistent history state. As the documentation notes:

   While editing migration dependencies, you can inadvertently create an inconsistent history state where a migration has been applied but some of its dependencies haven't. This is a strong indication that the dependencies are incorrect, so Django will refuse to run migrations or make new migrations until it's fixed.

3. Custom Fields: If you're using custom fields, be aware of the constraints mentioned in the documentation:

   You can't modify the number of positional arguments in an already migrated custom field without raising a TypeError. The old migration will call the modified init method with the old signature.

4. Model Managers: If your migrations involve model managers, ensure they have the use_in_migrations = True attribute if you need them available in RunPython operations.

5. Tracking Pending Deletions: To address your concern about inadvertently leaving fields pending deletion:

   • Consider implementing a code linting rule that flags fields marked with editable=False
   • Add comments with deadlines for field removal
   • Create a documentation process for tracking fields pending deletion
   • Use automated tests that verify no code references fields marked for deletion

6. Database Feature Support: Be aware of database feature support when planning migrations. For example, if you're using JSONField or other specialized fields, ensure your database backend supports them.

7. Monitoring During Migrations: Implement monitoring to detect any issues during the migration process, especially for large tables where migrations might take significant time.

Your approach is solid, and with these additional considerations, you should be able to implement smooth, backward-compatible migrations for blue-green deployments.