On simple sites, it's easy enough to download the database, make the changes locally, test, and overwrite the database on the live site. In these complex project situations, it's not sustainable to change the module configurations and create content types in every environment.
When our clients request a change, it can involve changing different configurations on modules. Each developer has a local copy of the site, then there is usually a staging site for client sign-off, and finally the changes are moved to the production site. One of the biggest hurdles in team-based Web development is figuring out how to synchronize configuration changes to a Drupal site between multiple environments. If you already understand why, then you can skip this section and jump down to the nitty gritty explanation of what configurations can be exported to features. So, while the gurus develop a new data synchronization model for Drupal 8, just what can we do in the meantime? Why feature-driven development? In Drupal versions 6 and 7 it is possible to put many configurations into the code so they can be tracked separately from end-user generated content stored in the production database. The great news is we don't have to wait for Drupal 8 to adopt this agile strategy today. This will provide a standardized and straightforward way for site builders to group pre-defined content and configurations into functional website features. This initiative is rooted in the agile principle of Feature Driven Development, and aims to solve the problem of synchronizing custom data and configurations across environments through code. Comparing and replicating configuration changes between environments is one of the most important tasks to get right, and eyeballing these changes by hand is risky.Īt Chicago's DrupalCon 2011, Dries announced that Configuration Management had been selected as one of the primary initiatives for Drupal 8. When you get several developers working together across multiple environments, it's difficult to keep track of where to find the "right" configuration. However, for projects with an ongoing development life-cycle, keeping track of what switches need to be flipped in Drupal's administrative interface during a feature launch becomes a developer's worst nightmare. This is a great convenience for small sites, and really demonstrates the power of Drupal's administration. A surprising amount of the configuration glue that holds our Drupal websites together is stored right along side all the end user-generated data that continually pours into a website's database.
0 kommentar(er)
