So currently we have our service and DB schema migration in the same codebase, and we are running DB schema migration (using Liquibase) as part of our service deployment (before, in Kubernetes).
Now we are trying to separate the DB schema migration job and service deployments. Solutions:
- One way is to keep both the things still in the same repo, and run in separate stages.
- Create separate repo/submodules for DB schema migration and the service code. This is to inherently separate out both the parts.
As part of solution 2, one way is to create separate repo, and hence separate pipelines for both job and the service deployment. But this way the DB schema code is not tied with the service code inherently, and we need context among us to relate both the parts.
What we want to achieve is to have DB and api layer in separate submodules, in the same repo. In this case, would it be possible to have 2 separate pipelines for DB schema migration job and the service deployment, and can be presented in a cleaner way ?
