#Notes from Drupalcon Portland, Thursday May 23, 2013

##Drupal Lifecycle Management, or How to Keep Your Dev Swagger After Launch

• Fast solutions ignoring best practices often make problems worse
  • Series of small mistakes under pressure add up to a bigger problem.
  • Do not hack solutions together
• Git
  • Use a "bare" repo to coordinate and run hooks
  • Deploy scripts can be written in any language that can be executed from the shell (php, rb, py, bash, whatever)
  • Tag deployments and other important events
    • My note: http://git-scm.com/book/en/Git-Basics-Tagging
• Jenkins
  • Allows you to define "jobs" and allows you to run them, can be used for continuous integration
  • Java based
  • Built in REST api for integration with other tools
• BDD
  • Much better for high level testing of functionality
  • Behat
    • Some work has been done for proper Drupal/Behat integration/best practices
• Drush Aliases
  • You should be able to get drush access w/o ssh
• You don't need to own all this yourself, use 3rd party services

##Using The Drupal 8 Configuration Management System

• Everything from this talk is subject to change
• All configuration in common system
  • Views
  • image styles
  • permissions/roles
  • content types and fields
  • settings
  • etc
• Configuration in files
  • Elimintates ~ 50 tables from database
  • Some may remain for upgrade path purposes even if they aren't used
• Transferring configuration files
  • config_[hash] directory created containing configuration
    • randomized name to make it harder to locate for security
    • hash is different per installation
    • protected by .htaccess
    • Good to relocate outside of web root
  • active is live, staging is for imporing new configurations
  • can set which is live in settings.php
  • active in your dev environment should deploy to staging on your live site
  • Two directory system is to avoic conflicts when someone may be updating configuration through the GUI at the same time you are updating
  • Import changed/updated/removed configuration through GUI
    • Change diff can be viewed in GUI
    • You hae to import all staged changes or none of it. You can't cherry pick
  • Expectation is that contrib modules will expand on this functionality and ui
• Internationalization
  • Contextually change configuration
• Things to come
  • Patch in place to create snapshots between configuration changes so you can see what has been changed
    • See when a client has made a change without your knowledge
  • Patch submitted to add 1 click exporting/importing site configuration as a tar ball
    • An API would be provided for this so it can be done through Drush or other tools
• $conf array in settings.php still exists for env specific settings
  • If a setting exists in $conf then it is the setting that will be used over anything in CMI
  • Work will likely happen on a "Context" module to make it easier to work with env specific configuration settings
• There is a system that exists to hold env specific state settings and values that do not need to be deployed, ex: last time cron ran
• Currently you can't undo a configuration change
  • Rational is that in some cases it's impossible (fields and other things that trigger a change to the database)
• Of course this comes with a performance hit
  • Configuration is cached but boostrapping still involves multiple database hits
• Memory impact is lowered, configuration can be granularly loaded instead of all at once

##TAP Into Museums

• http://tapintomuseums.org/
• TAP is an open source set of tools for mobile tours of museums
• Authoring layer is Drupal
• Content layer is TourML
• Multiple tours can be grouped into Tour sets
• Application layer can be iOS, Android, whatever
  • User can type in stop code on keypad and get information about that stop on the tour
  • User can list all stops on tour
  • User can view all stops plotted on a map
• Authoring form uses OpenLayer map to plot stops
• https://github.com/IMAmuseum/tap-cms is the main repository