programowo sprawdzić, czy istnieją Django migracji na południe, które muszą być wdrożone

Question

Moja strategia wdrażania wygląda następująco (przy użyciu tkaniny):

1. utworzyć nowy virtualenv
2. wdrożyć nowy kod w nowym virtualenv
3. pokaż strona konserwacja
4. skopiować bieżący db do nowego db
5. migrować nowy dB
6. punkt nowy kod do nowego db
7. symlink prąd virtualenv do nowego venv
8. usługi restart
9. konserwacja usuń strona

Chcę szybko iteracji. Obecnie większość zmian w kodzie nie zawiera migracji. Ponadto baza danych rośnie, więc wiele kosztów generuje się, kopiując bazę danych za każdym razem, gdy wdrażam (głównie małą) zmianę. Aby uniknąć kopiowania bazy danych, chcę sprawdzić, czy istnieją migracje, które należy wdrożyć (przed krokiem 4). Jeśli nie ma migracji, mogę przejść od kroku 2 do kroku 7. Jeśli tak, to wykonam wszystkie kroki. W tym celu muszę programowo sprawdzić, czy istnieją migracje, które należy wdrożyć. Jak mogę to zrobić?

Answer 1

W kroku 2 podczas wdrażania nowego kodu można wdrożyć skrypt, który po uruchomieniu na serwerze wykryje, czy są nowe migracje.

Przykładowy kod wygląda następująco:

# copied mostly from south.management.commands.migrate 
from south import migration 
from south.models import MigrationHistory 

apps = list(migration.all_migrations()) 

applied_migrations = MigrationHistory.objects.filter(app_name__in=[app.app_label() for app in apps]) 
applied_migrations = ['%s.%s' % (mi.app_name,mi.migration) for mi in applied_migrations] 

num_new_migrations = 0 
for app in apps: 
    for migration in app: 
     if migration.app_label() + "." + migration.name() not in applied_migrations: 
      num_new_migrations = num_new_migrations + 1 

return num_new_migrations 

Jeśli owinąć powyższy kod w górę w skrypcie, skrypt wdrożenie tkaniny można użyć operacji run, aby uzyskać liczbę nowych migracji.

Jeśli to zwróci zero, możesz pominąć kroki związane z kopiowaniem bazy danych.    

Answer 2

Dlaczego przenosisz bazy danych? Cały punkt migracji polega na zastosowaniu zmian wprowadzonych w rozwoju do bazy danych produkcji.

swoje kroki powinny być naprawdę:

1. utworzyć nowy virtualenv
2. wdrożyć nowy kod w nowym virtualenv
3. wykazują stronie Konserwacja
4. migrować nowy DB
5. symlink aktualny virtualenv do nowych venv
6. restart usługi
7. usuń strona konserwacji

Krok migracji nie potrwa zbyt długo, jeśli nie ma żadnych nowych migracji do uruchomienia. Po prostu przejdzie przez każdą aplikację, mówiąc, że jest już aktualna.

Jeśli kopiujesz bazę danych w celu utworzenia kopii zapasowej, jest to coś, co powinno działać niezależnie od crona lub czegoś w tym rodzaju, a nie jako część wdrożenia.

Właściwie to jestem zdezorientowany przy tworzeniu nowego virtualenv za każdym razem. Znormalizowany (czytaj: najbardziej typowe) wdrożenie jest:

1. wdrożyć nowy kod
2. Migrate db
3. usługi restart

Jeśli chcesz dodać z powrotem do rzeczy widoku konserwacji, można , ale proces zajmuje tylko minutę lub dwie sumy.

Answer 3

./manage.py migrate --all --merge --list | grep "()" 

Will powiedzieć i pokazać, które migracje. Jeśli potrzebujesz kodu powrotu lub liczby, użyj wc.

Ma to zalety polegające na tym, że nie można kopiować i wklejać kodu, takiego jak zaakceptowana odpowiedź (naruszając DRY), a także, jeśli wewnętrzny południowy interfejs API zmieni twój kod, nadal będzie działał.

UPDATE:

Django 1.7 zmienił wyjście do korzystania wspornik zamiast nawiasu i Django 1.8 wprowadzono showmigration polecenie:

./manage.py showmigrations --list | grep '[ ]' 

Answer 4

odpowiedź dalore updated dla Django 1.7+

./manage.py migrate --list | grep "\[ ]" 

Jeśli chcesz tylko liczbę:

./manage.py migrate --list | grep "\[ ]" | wc -l