...
For seeding data, since each Independent Service manages its own data in its own logical data store, it is in charge of seeding data. (The physical data store information would be in the Reference Distribution configuration, most likely pointing to an external PostgreSQL database.) There will be some sort of script or task (in each Independent Service) that seeds data.
What about situations where services have dependencies on other services / data being in place? For example, an informed push module may expect that facilities have CCE installed. However without a CCE service being part of the distribution this dependency may not be met.
Each Independent Service will have two build tasks for migration–one for structural migrations and another for implementation-specific migrations. Seed migrations are part of the second type.
...
In this case, the implementer would get new versions of the images of each Independent Service that needs to be updated. The new images may have structural migrations that need to be run against their respective logical data stores. Implementation-specific (including seed) migrations will not be run on an update.
For which types of releases should the user not have to worry about a structural migration? Major, minor, patch?
Use Case 2: Project creates new Independent Service, deploys as part of Reference Distribution
...