title: Release process for MongoDB changes
body: <p>When its RDBMS, I used Liquibase to deploy the changes in the target database. That has support for multi-tenancy &amp; roll back to different versions.</p>
  
  <p>In Mongo, I tried to find the equivalent library and found the below.</p>
  
  <ol>
  <li><a href="https://github.com/mongobee/mongobee" rel="noreferrer">https://github.com/mongobee/mongobee</a> - Requires java skillset. Last update was 2 Years ago.</li>
  <li><a href="https://github.com/coldze/mongol" rel="noreferrer">https://github.com/coldze/mongol</a> - Stick to just Json. Low reputation.</li>
  <li><a href="https://github.com/mongeez/mongeez" rel="noreferrer">https://github.com/mongeez/mongeez</a> - Kind of promising but very outdated. </li>
  <li><a href="https://github.com/tj/node-migrate" rel="noreferrer">https://github.com/tj/node-migrate</a> - Done in jS, has reputation better than others, but lot of learning required to be familiar with this framework IMO.</li>
  </ol>
  
  <p>For me the criteria are,</p>
  
  <ol>
  <li>Upgrade from one version to any new version must be possible.</li>
  <li>Downgrade from the current version to any old version must be possible ( should have the feasibility to do the complex migration. Ex, refer to the different collections and assign a computed value from the output.</li>
  <li>Must be able to extract the changes before execution. For verification purposes mostly. Otherwise, during new build deployment, the changes alone to be executed.</li>
  <li>Easy to adopt, so a lot of learning should be avoided.</li>
  </ol>
  
  <p>You have some other working concept, eager to know. Thanks,</p>
  
  <p>A.</p>