Best Approach for Database Migrations in Concrete CMS?

Developing with Concrete
1

I’m looking for the best practices for handling database migrations in Concrete CMS. Is there a recommended method for managing schema changes between development and production environments? Should I rely on core tools, or are there third-party packages that streamline this process? Any advice on avoiding downtime and ensuring data integrity during migrations?

1 Like
2

The core manages database migrations for its own tables. Are you referring to custom packages and such? Or content differences between a stage and production?

There are CLI tools available to assist with creating migrations:

$ ./vendor/bin/concrete help migrate
Description:
  Execute a migration to a specified version or the latest available version.

Usage:
  migrations:migrate [options] [--] [<version>]
  migrate

Arguments:
  version                                    The version number (YYYYMMDDHHMMSS) or alias (first, prev, next, latest) to migrate to. [default: "latest"]

Options:
      --write-sql[=WRITE-SQL]                The path to output the migration SQL file instead of executing it. Defaults to current working directory. [default: false]
      --dry-run                              Execute the migration as a dry run.
      --query-time                           Time all the queries individually.
      --allow-no-migration                   Do not throw an exception if no migration is available.
      --all-or-nothing[=ALL-OR-NOTHING]      Wrap the entire migration in a transaction. [default: false]
      --configuration[=CONFIGURATION]        The path to a migrations configuration file.
      --db-configuration[=DB-CONFIGURATION]  The path to a database connection configuration file.
  -h, --help                                 Display help for the given command. When no command is given display help for the list command
  -q, --quiet                                Do not output any message
  -V, --version                              Display this application version
      --ansi|--no-ansi                       Force (or disable --no-ansi) ANSI output
  -n, --no-interaction                       Do not ask any interactive question
  -v|vv|vvv, --verbose                       Increase the verbosity of messages: 1 for normal output, 2 for more verbose output and 3 for debug

Help:
  The migrations:migrate command executes a migration to a specified version or the latest available version:
  
      ./vendor/bin/concrete migrations:migrate
  
  You can optionally manually specify the version you wish to migrate to:
  
      ./vendor/bin/concrete migrations:migrate YYYYMMDDHHMMSS
  
  You can specify the version you wish to migrate to using an alias:
  
      ./vendor/bin/concrete migrations:migrate prev
      These alias are defined : first, latest, prev, current and next
  
  You can specify the version you wish to migrate to using an number against the current version:
  
      ./vendor/bin/concrete migrations:migrate current+3
  
  You can also execute the migration as a --dry-run:
  
      ./vendor/bin/concrete migrations:migrate YYYYMMDDHHMMSS --dry-run
  
  You can output the would be executed SQL statements to a file with --write-sql:
  
      ./vendor/bin/concrete migrations:migrate YYYYMMDDHHMMSS --write-sql
  
  Or you can also execute the migration without a warning message which you need to interact with:
  
      ./vendor/bin/concrete migrations:migrate --no-interaction
  
  You can also time all the different queries if you wanna know which one is taking so long:
  
      ./vendor/bin/concrete migrations:migrate --query-time
  
  Use the --all-or-nothing option to wrap the entire migration in a transaction.