...
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.
- This dependency issue would show up at the service level, i.e. the Informed Push Independent Service would make calls to the CCE Independent Service, but since it is not installed, those calls would fail. To prevent this, the Reference Distribution would have have dependency management during build/package time. So an Informed Push Independent Service, when it is being packaged, if it depends on the CCE Independent Service, would make sure that is packaged in the Reference Distribution as well.
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.
...
For which types of releases should the user not have to worry about a structural migration? Major, minor, patch?
- I am not sure what you mean by "user". Do you mean the implementer? If so, structural migrations are logically agnostic to releases–meaning they might need to be run on any type of release. There may be a patch that must run a structural migration in order to fix a significant bug in the software.
Use Case 2: Project creates new Independent Service, deploys as part of Reference Distribution
...