title: In microservices, does it make sense to have separate code repositories for database migration scripts and API code?
body: <p>In accordance with <a href="https://martinfowler.com/bliki/BoundedContext.html" rel="nofollow noreferrer">bounded context</a>, we have identified two microservices implementations, lets call them <code>Service A</code> and <code>Service B</code> respectively. Each of these microservices have different repositories (due to the benefits of Single Responsibility and better ownership). Now, each of these repositories use their own database schema (choice made for better separation of persistence and reduced maintenance of DB instances).</p>
  
  <p>Earlier, we extracted the database migrations scripts (for continuous delivery) into a separate single repository (contains scripts for both <code>Service A</code> and <code>Service B</code> 's schemas) and run them under a single job under CI. Now as we tackle more stories, we have started facing some challenges, some of which are listed below:</p>
  
  <ul>
  <li>A change to a single schema triggers the build for the whole database and hence the downstream triggering of all the microservices, hence increasing our feedback time</li>
  <li>We are in general failing to achieve <code>true</code> continuous delivery, because a schema change also requires a respective change in the <code>Service</code> code and hence cautious efforts are taken to deploy both the <a href="https://help.github.com/articles/about-pull-requests/" rel="nofollow noreferrer">PRs</a></li>
  <li>Moreover, there are some common tables like <code>Users</code> which needs to be used by both the schemas, which currently are being duplicated across both the schemas.</li>
  </ul>
  
  <p>So my question/doubt is :</p>
  
  <ul>
  <li>Should we even separate the DB migrations repository according to the schemas, just like the Services.</li>
  <li>Should we even have separate repository for DB migrations scripts ? Should we club them within their respective <code>Service</code> repository code ?</li>
  <li>Should we extract the common tables further <code>a level up</code> and raise <code>Domain Events</code> for <a href="https://en.wikipedia.org/wiki/Eventual_consistency" rel="nofollow noreferrer"><code>Eventual Consistency</code></a></li>
  </ul>
  
  <p>Any pointers/advice would greatly help.Thanks.</p>