Migrasi dan Version Control (makemigrations, migrate, migrasi reversible, best practice Git)

Sebelumnya kita sudah mendesain model dan relasi. Tetapi kode model di models.py itu baru setengahnya saja. Skema database yang sebenarnya hanya berubah ketika migration dibuat dan di-apply.

Bayangkan seperti ini:

models.py = maunya kita
file migration = rencana perubahannya
tabel database = realita yang sebenarnya

Kalau maunya kita dan realita tidak sinkron, API kita tidak akan bekerja dengan benar.

Apa Sebenarnya Migration Itu

Migration di Django adalah file Python yang menjelaskan bagaimana mentransformasi skema database kita dari satu kondisi ke kondisi lainnya.

Flownya seperti ini:

1
edit models.py -> python manage.py makemigrations -> python manage.py migrate

Apa yang dilakukan setiap langkah:

makemigrations: membandingkan model saat ini dengan history dari migration lalu membuat file migration baru.
migrate: mengeksekusi migration yang belum di-apply ke database.

File migration ada di folder migrations/ milik setiap app, biasanya bernama seperti:

0001_initial.py
0002_add_status_field.py
0003_rename_title_to_name.py

Memahami File Migration

Contoh migration hasil generate:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
# contoh yang disederhanakan
from django.db import migrations, models

class Migration(migrations.Migration):
    dependencies = [
        ('my_app', '0001_initial'),
    ]

    operations = [
        migrations.AddField(
            model_name='course',
            name='status',
            field=models.CharField(max_length=20, default='draft'),
        ),
    ]

Bagian pentingnya:

dependencies: memberi tahu Django apa yang harus dijalankan lebih dulu.
operations: aksi skema yang konkrit (buat tabel, tambah field, ubah field, rename field, dll).

Django membangun dependency graph agar urutan migration tetap benar.

Migrate, showmigrations, dan sqlmigrate

python manage.py migrate

Meng-apply semua migration yang masih pending sesuai urutan dependency.

python manage.py showmigrations

Menampilkan status migration:

[X] berarti sudah di-apply
[ ] berarti belum di-apply

python manage.py sqlmigrate <migration_number>

Menampilkan SQL yang dihasilkan oleh migration tertentu.

Contoh:

1
python manage.py sqlmigrate migration_lab 0002

Ini berguna untuk mengerti apa yang benar-benar dijalankan di level DB.

Migrasi Reversible (Rollback dengan Aman)

Migration di Django dirancang agar bisa reversible ketika operasinya memang reversible.

Rollback satu app ke migration sebelumnya

1
python manage.py migrate migration_lab 0001

Rollback satu app sepenuhnya

1
python manage.py migrate migration_lab zero

zero berarti unapply semua migration untuk app tersebut.

Perhatian penting

Tidak setiap perubahan aman untuk di-reverse dalam skenario data nyata.

Contoh reversal yang berisiko:

menghapus kolom yang sudah berisi data penting
mengubah tipe field dengan cara yang memotong value
custom SQL migration yang destruktif

Rule-nya: anggap rollback sebagai alat, bukan mesin waktu.

Best Practice Git untuk Migration

Migration adalah bagian dari source code. Selalu commit migration.

Selalu commit bersamaan:

perubahan pada model
file migration yang dihasilkan dari perubahan tersebut

Jangan lakukan ini:

mengedit file migration lama yang sudah dibagikan ke rekan tim
meng-generate ulang history dari nol di project bersama tanpa koordinasi
membiarkan file migration tidak di-commit

Alur kerja tim yang umum

Pull branch terbaru.
Buat perubahan model.
Jalankan makemigrations.
Review migration yang dihasilkan.
Jalankan migrate.
Commit model + migration bersamaan.

Catatan merge conflict

Saat dua branch membuat migration baru yang berbeda di app yang sama, Django bisa meminta merge migration:

1
python manage.py makemigrations --merge

Gunakan ini hanya jika diperlukan, dan review hasilnya dengan hati-hati.

Strategi Evolusi Skema yang Aman

Untuk perubahan yang aman di production, utamakan langkah kecil.

Contoh: menambahkan field wajib ke tabel yang sudah punya data.

Pendekatan yang tidak aman:

langsung tambah field non-null tanpa default

Pendekatan yang lebih aman:

Tambahkan field sebagai nullable (null=True) atau dengan default sementara.
Backfill baris yang sudah ada.
Jadikan field non-null di migration berikutnya.

Ini mencegah deploy gagal dan downtime.

Latihan Hands-On

Kita akan membuat app baru agar app yang sudah ada tetap tidak tersentuh.

Buat app dan daftarkan

1
python manage.py startapp migration_lab

Tambahkan 'migration_lab' ke INSTALLED_APPS di config/settings.py.

Buat model awal

Di migration_lab/models.py, masukkan kode persis ini:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
from django.db import models


class LabTask(models.Model):
    title = models.CharField(max_length=120)
    created_at = models.DateTimeField(auto_now_add=True)

    class Meta:
        ordering = ['-created_at']

    def __str__(self):
        return self.title

Jalankan:

1
2
3
python manage.py makemigrations migration_lab
python manage.py migrate
python manage.py showmigrations migration_lab

Tambahkan field baru (migration baru)

Update model:

1
2
3
4
class LabTask(models.Model):
    title = models.CharField(max_length=120)
    status = models.CharField(max_length=20, default='todo')
    created_at = models.DateTimeField(auto_now_add=True)