title: FlyWay migration strategy
body: <p>Currently on a project we use FlyWay, and we have a multiple environments, like: dev(local for developers), several instances of the application for QA guys, staging... And we have such workflow with tasks: <strong>in progress -> code review -> QA -> merge</strong>.</p>
  
  <p>We faced with an issue: assume a developer, during working on a branch <strong>A</strong>, provided a new migration version, lets say V331, meanwhile a QA guy is doing qa on another branch, lets say <strong>B</strong>, on QA environment. It may happen that the qa environment already has version v331, because several developers may create the same version number on different branches at different time... More over qa switches between branches very often, and that is why qa database becomes messy, especially table <strong>schema_version</strong>, and it leads us that we have manually remove broken schema version, resolve old migrated version issues and then again launch migration process on an environment. How do you deal with multiple environments and flyway? Is there a best practice?</p>