My notes from the third day of presentations at Drupalcon Portland 2013

#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

ornj/drupalcon-thursday-notes.md