You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@@ -39,7 +39,7 @@ Both commands have common arguments:
39
39
Log level for logging. INFO, DEBUG, etc.
40
40
41
41
```
42
-
`PATH` argument used to specify path to git repository directory (local). Default path is current dir : `'.'`.
42
+
`PATH` argument used to specify path to git repository directory (local). Default path is current dir : `'.'`. For django applications it is a project root where `manage.py` is located.
43
43
44
44
`LOGGER` and `LOG_LEVEL` arguments can be used to setup internal logging. For example, you can use one of django_logging loggers (to push it to slack, write console, file, etc.). There is no default value, so by default additional logging disabled.
Save migrations state for current commit. It also check if commit already
56
-
exists and print warning if it`s not the latest state that may be a symptom of
57
+
exists and print warning if it's not the latest state that may be a symptom of
57
58
inconsistent state for migrations.
58
59
59
60
optional arguments:
@@ -62,24 +63,29 @@ optional arguments:
62
63
Logger name for logging.
63
64
--log-level LOG_LEVEL
64
65
Log level for logging. INFO, DEBUG, etc.
66
+
--log-full-data Log full data for migrations state when created.
67
+
--log-diff Log current diff for current and previous state.
65
68
66
69
```
67
70
This command used to save apps migrations state of current commit to DB. It try to create new state, but if already exists it checks is this state the latest.
68
71
If state for current commit is not the latest - it may be a symptom of problems and rollback from current commit will not work for it.
Rollback migrations state of all django apps to chosen tag or commit if
@@ -100,6 +106,7 @@ optional arguments:
100
106
Git commit hash to which to rollback migrations.
101
107
--fake It allow to only print info about processed actions
102
108
without execution (no changes for DB).
109
+
103
110
```
104
111
105
112
You can use git commit hash (hex) directly. And you don`t need to specify full commit hash, you just can use first letters.
@@ -117,14 +124,19 @@ Or you can use git tag (it will be translated to related commit).
117
124
118
125
Successful output example below:
119
126
```bash
120
-
./manage.py rollback_migrations -c c257a23
121
-
>>> Executing command: migrate django_rollback zero
127
+
$ ./manage.py rollback_migrations -c 0df07b
128
+
Found migrations diff. In case of rollback need migrate to:
129
+
[MigrationRecord(id=24, app='temp', name='zero')]
130
+
Running rollback from commit "03ec91e5319ed65a94f8ea07f6093018a61f9e1b" ['0.2.1'] to commit "0df07b2f0ce8dbb9755cfd8a1b213f9c0735e833" ['0.2.0'].
131
+
Executing command: `migrate temp zero`
122
132
Operations to perform:
123
-
Unapply all migrations: django_rollback
133
+
Unapply all migrations: temp
124
134
Running migrations:
125
135
Rendering model states... DONE
126
-
Unapplying django_rollback.0001_initial... OK
136
+
Unapplying temp.0001_initial... OK
137
+
state for commit "0df07b2f0ce8dbb9755cfd8a1b213f9c0735e833" ['0.2.0'] now is the last state in DB
127
138
Rollback successfully finished.
139
+
128
140
```
129
141
130
142
As you can see above, apps can be rollbacked to `zero` state too, if in previous state this app not used.
@@ -137,3 +149,47 @@ So rollback will be successfully finished if two conditions are satisfied:
137
149
- state for current commit was saved (if not - use `./manage.py save_migrations_state` command)
138
150
- state for specified commit, commit which relates to specified tag was saved in the past
139
151
- if commit not specified, just the previous state should exists
152
+
153
+
## Usage example
154
+
For example, we have a django-application packed with Docker. We have a release cycle and deploy docker images based on some version of our source code. Building images includes copying all source code data (including `.git` directory), so `django_rollback` will have direct access to local git repository to identify or search commits, tags, etc.
155
+
156
+
Docker allows you to use some `entrypoint` that can be `.sh` file. So we have something like that:
157
+
```dockerfile
158
+
FROM python:3.6
159
+
ENTRYPOINT ["dumb-init", "--"]
160
+
CMD ["start.sh"]
161
+
WORKDIR /src
162
+
EXPOSE 8000
163
+
164
+
COPY . /src
165
+
COPY docker/bin /usr/local/bin
166
+
167
+
### and other configuration
168
+
```
169
+
And our `start.sh` entrypoint can be something like this:
170
+
```bash
171
+
#!/bin/bash
172
+
173
+
./_manage.py migrate
174
+
./_manage.py save_migrations_state -l "django.slack_logging" --log-level INFO --log-diff
So every time when your application is starting in docker - current migrations state will be saved or checked. And you will see all actions with specified logger (slack channel, for example). So, now you have an ability to monitoring current migrations state of your django-application in real time.
180
+
181
+
### When something goes wrong...
182
+
183
+
With our release cycle sometimes something goes wrong during deployment of new version of our application and we want to bring back previous state of application.
184
+
185
+
So we need to unapply all new migrations and deploy docker image based on previous version.
186
+
187
+
You just can use some `.sh` script to run rollback migrations or manually run manage.py command using `docker run` or `docker exec` commands.
188
+
189
+
Script `rollback.sh` can be like this:
190
+
```bash
191
+
#!/usr/bin/env bash
192
+
./_manage.py rollback_migrations "$@" -l "django.slack_logging" --log-level INFO
193
+
194
+
```
195
+
So in case of rollback you also able to monitoring what`s going on: which migrations are unapplying and which version of source code new DB state corresponds.
0 commit comments