When the version of the code is older than the version stored in db, the application is blocked.
With #89, restoring an previous version of the db unblocks the situation.
However, if new data was generated between the last acceptable backup and the code rollback, this new data will be lost e.g.:
+-> Deploy new code in v2, which will detect that db
| is in v1 and upgrade it (#27)
|
| +-> Create a backup in v1, before upgrading to v2
| | (implemented in #78)
| |
| | +-> Upgrade database to v2
| | |
| | | +-> Generate some new data
| | | |
| | | | +-> Rollback code to v1 because of some bug,
| | | | | requiring to restore a backup in v1
| | | | |
| | | | | +-> Restore the backup from 2,
| | | | | | loosing data generated in 4
| | | | | |
-----1---2---3------4-----5--6---------->
In #27, we introduced a 2 digit db versioning system to automatically modify the db structure as needed when new code is deployed. A version is stored in db and a version is expected in the code. If the version stored in db is older than the version expected by the code, then it needs to be upgrade.
Based on the source version and the target version, a series of scripts are executed.
E.g. we go from 1.0 to 2.0 and the following update scripts are available:
to0.5.sql
to1.0.sql
to1.1.sql
to2.0.sql
So we'll execute the two scripts to1.0.sql and to2.0 sql.
Each of these scripts create new tables or new columns as required by the new code: a new code cannot run on an older db and that's why the db needs to be upgraded using these scripts.
So far, the db versions did not really follow any semantic. This issue will introduce semantic version numbering.
Basically, if the code is older than the db but it has the same major number then it's ok to run with it.
For example we're in 2.2 and we create a new table. We will bump the version to 2.3 and keep the same major because It's ok to rollback the code to 2.2 and keep this db structure: the old code just won't use that new table.
Now consider the case where we decide to store existing data in a new table and drop the old one. Then the version needs to be bumped to 3.0 because running old code won't work anymore: the old table does not exist any more and the code will break.
_This will imply semantic version numbering of the releases: a major change in db version implies a major change in release version, indicating that a rollback is not possible._
When the version of the code is older than the version stored in db, the application is blocked.
With #89, restoring an previous version of the db unblocks the situation.
However, if new data was generated between the last acceptable backup and the code rollback, this new data will be lost e.g.:
In #27, we introduced a 2 digit db versioning system to automatically modify the db structure as needed when new code is deployed. A version is stored in db and a version is expected in the code. If the version stored in db is older than the version expected by the code, then it needs to be upgrade. Based on the source version and the target version, a series of scripts are executed.
E.g. we go from 1.0 to 2.0 and the following update scripts are available:
So we'll execute the two scripts
to1.0.sqlandto2.0sql.Each of these scripts create new tables or new columns as required by the new code: a new code cannot run on an older db and that's why the db needs to be upgraded using these scripts.
So far, the db versions did not really follow any semantic. This issue will introduce semantic version numbering. Basically, if the code is older than the db but it has the same major number then it's ok to run with it.
For example we're in 2.2 and we create a new table. We will bump the version to 2.3 and keep the same major because It's ok to rollback the code to 2.2 and keep this db structure: the old code just won't use that new table.
Now consider the case where we decide to store existing data in a new table and drop the old one. Then the version needs to be bumped to 3.0 because running old code won't work anymore: the old table does not exist any more and the code will break.
_This will imply semantic version numbering of the releases: a major change in db version implies a major change in release version, indicating that a rollback is not possible._