In the - INP-835Getting issue details... STATUS the functionality for automatic deployment of In-Portal based websites to staging and production servers were developed. Several improvements has been made to it since then as well.
One of the key components of deployment process is "project_upgrades.sql" file, that is placed in the "install" sub-folder of a module (e.g. "/modules/in-link/install/project_upgrades.sql"). The file typically looks like this:
In the above example following can be understood:
- file consists of several revisions
- each revision written in special format as MySQL comment
- each revision has number
- revision numbers must be unique
- each revision has SQLs and comments, associated with it
Each deployment server also track status of each revision - deployed or not.
There is also a duplicate revision check, but it only looks through not yet executed revisions. In practice this doesn't help at all, because only last revision is the one, that isn't executed.
In the "DeploymentHelper::collectDatabaseRevisions" method:
- collect all found revisions (regardless of their status) into local "$revision_numbers" array
- when new revision is found, then compare it against "$revision_numbers" variable instead of using "$this->revisionSqls" which represents only non-executed revisions