State-based deployments

For SQL Server, Oracle, PostgreSQL, and MySQL:

• Flyway Teams - manual state-based deployments from the Schema model
• Flyway Enterprise - manual state-based deployments or automated state-based deployments with additional security and reports 

Migrations-based deployments

All editions of Flyway allow you to deploy migration scripts.  Use the Migrations tab in Flyway Desktop or automate using the migrate cli or Flyway Docker container.  See our example CI/CD Pipelines for how to automate your changes using migration scripts.

Learn more about the different state-based and migrations-based deployment approaches.

Sample CI/CD process for all deployments

1. Check out scripts from version control.
   
   
2. CI - Build, analyze, and test database changes. 
   1. Build - The build validates your scripts and makes sure they can run successfully. 
      
      
   2. Analyze - Code analysis checks - Make sure you're not using deprecated syntax, changing security settings, or dropping data.  You can also enforce naming conventions are being followed.
      
      
   3. Test - Testing can be unit tests, integration tests, regression tests, performance tests, etc.  Having a few smoke tests that run on every build and give quick feedback to ensure the most critical parts of your system are not broken is a good idea.
      
      
3. Deploy to Test environment
   1. Execute your scripts on a test environment
      
      
4. Deploy to additional environments (if needed).
   1. You may have additional test environments or Quality Assurance (QA)/User Acceptance Testing (UAT) environments that need to be deployed to.  Using an automated process helps ensure the consistency of your environments.
      
      
5. Deploy to a Staging/Pre-Production environment (optional)
   
   1. A Staging/Pre-Production environment is as similar to your Production environment as possible.  It may even have a copy of Production data, so that the deployment can be tested on a realistic environment as possible before going to Production.
   2. Staging/Pre-Production environments can also be used to check how long a deployment will take to run.  This information can be used to schedule deployments for off hours or down time as needed.
      
      
6. Deploy to Production
   1. Manual intervention before going to Production
      1. Review the Change Report to quickly see how many objects will be changed.  Drill into a side-by-side difference of each object to understand the changes easily and determine if there's any impact. 
      2. Review the SQL script - This is the exact script that will be executed on the Production Environment.
      3. Check for Drift to make sure no objects have changed in Production since your last deployment.  This ensures that the Staging/Pre-Production deployment you did really reflects the deployment to Production and that no Production hot fixes will cause issues with the current deployment. * 
      4.  Deploy your changes.
      5. Log changes (in SQL Monitor) and/or in Flyway Pipelines. 

* These capabilities are only available for SQL Server, Oracle, PostgreSQL and MySQL.