Your SlideShare is downloading. ×
0
STAGING AND DEPLOYMENTPROJECT          GREG DUNLAP (@HEYROCKER)DATE                   CLIENT          3/8/2011            ...
•The Problem•A Rant•Some Ideas
The Problem
•Data smooshage•ID Conflicts•API issues
A Rant
WE DO NOT HAVE A CONFIGURATION  MANAGEMENT    PROBLEM
WE HAVE AN EVERYTHINGMANAGEMENT  PROBLEM
THERE IS NO DIVIDE    BETWEENCONFIGURATION ANDCONTENT IN DRUPAL
STOP PRETENDING
TREAT THINGS AS THINGS AND WE CAN SOLVE THE  PROBLEM FOR REAL
Some Ideas
•Reliably unique IDs•Everything exportable•API cleanup
Reliably Unique IDs
Reliably Unique IDs• UUIDs or Machine Names
Reliably Unique IDs• UUIDs or Machine Names•Apply as appropriate
UUIDs
UUIDs•Add alongside keys
UUIDs•Add alongside keys•No query performance impact
UUIDs•Add alongside keys•No query performance impact•Easier upgrade path
UUIDs•Add alongside keys•No query performance impact•Easier upgrade path•Translate IDs on save
Exportability
Exportability• Everything
Exportability• Everything•Doesn’t have to be complex
API CLEANUP
Things That Are Not APIs
Things That Are Not APIs • Form submit functions
Things That Are Not APIs • Form submit functions • Form validate functions
Things That Are Not APIs • Form submit functions • Form validate functions • $_GET
If we can’t save things we can’t import them
That’s It
You can throw things now
Core conv
Core conv
Core conv
Upcoming SlideShare
Loading in...5
×

Core conv

5,769

Published on

Slides from my Core Conversation on Staging and Deployment at DrupalCon Chicago 2011.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,769
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
13
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Introduction, still talking about this four years later\n
  • Our show tonight is three acts...\nWith assistance from a very special guest\n
  • Mr. Jeff Eaton. \nI will not spend a lot of time on the problem as we’re all pretty familiar with it\n
  • Monolithical database with all information\nAutoincrementing IDs\nLack of APIs\n
  • \n
  • \n
  • Our existing tools are focused only on the needs of developers and the ability to deploy configuration. This is understandable but doesn’t fix things.\n
  • Drupal has never pretended otherwise\nTrend has been to blur this line, not clarify it\nNodequeue example\n\n
  • \n
  • We can draw arbitrary lines, but why? Let Drupal be Drupal \n
  • \n
  • There is no magic bullet solution. There are too many use cases and workflows for that. This is a list of things we can do to enable people to do what they need.\n
  • \n
  • UUIDs everywhere is not necessary or appropriate\nMachine names still have uses in situations where identifier needs to be human-readable (aka CSS class names)\n
  • UUIDs everywhere is not necessary or appropriate\nMachine names still have uses in situations where identifier needs to be human-readable (aka CSS class names)\n
  • Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
  • Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
  • Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
  • Prevent ugly paths with pathauto in core\nModules act on node_save() to handle the data they know (relations, etc)\n\n
  • How can be discussed, we dont have to reinvent most of it. load() vs export(), lets not have two ways to load and save thing for different situations when the functionality is largely the same. \n
  • How can be discussed, we dont have to reinvent most of it. load() vs export(), lets not have two ways to load and save thing for different situations when the functionality is largely the same. \n
  • This is not about improving or cleaning up APIs, that stuff is going to get done. It is more about making sure we have actual APIs to load and save things. \n
  • Lesson here: Form API is not the place to put CRUD functionality, core needs to implement these things consistently and lead the way for contrib. People don’t usually think of this as part of the staging and deployment problem but it is because...\n
  • Lesson here: Form API is not the place to put CRUD functionality, core needs to implement these things consistently and lead the way for contrib. People don’t usually think of this as part of the staging and deployment problem but it is because...\n
  • Lesson here: Form API is not the place to put CRUD functionality, core needs to implement these things consistently and lead the way for contrib. People don’t usually think of this as part of the staging and deployment problem but it is because...\n
  • Right now we have a hard time saving things because there is functionality that exists only in submit and validate functions. Your options are drupal_form_submit() (hack with inconsistent formats) or node_save() (wont catch everything.) So when I talk about API cleanup I mostly mean turning things that aren’t APIs into actual APIs so we can save and load things consistently, and creating APIs for things that don’t have them (cf roles, etc)\n
  • These three things allow things to actually be deployed. There are lots of workflows and use cases for this, and we don’t need to address them all, let contrib worry about it. But without these changes we can’t address any of them. This is also an approachable set of solutions, if you try to change the world in a core release...\n
  • \n
  • Transcript of "Core conv"

    1. 1. STAGING AND DEPLOYMENTPROJECT GREG DUNLAP (@HEYROCKER)DATE CLIENT 3/8/2011 DRUPALCON CHICAGO
    2. 2. •The Problem•A Rant•Some Ideas
    3. 3. The Problem
    4. 4. •Data smooshage•ID Conflicts•API issues
    5. 5. A Rant
    6. 6. WE DO NOT HAVE A CONFIGURATION MANAGEMENT PROBLEM
    7. 7. WE HAVE AN EVERYTHINGMANAGEMENT PROBLEM
    8. 8. THERE IS NO DIVIDE BETWEENCONFIGURATION ANDCONTENT IN DRUPAL
    9. 9. STOP PRETENDING
    10. 10. TREAT THINGS AS THINGS AND WE CAN SOLVE THE PROBLEM FOR REAL
    11. 11. Some Ideas
    12. 12. •Reliably unique IDs•Everything exportable•API cleanup
    13. 13. Reliably Unique IDs
    14. 14. Reliably Unique IDs• UUIDs or Machine Names
    15. 15. Reliably Unique IDs• UUIDs or Machine Names•Apply as appropriate
    16. 16. UUIDs
    17. 17. UUIDs•Add alongside keys
    18. 18. UUIDs•Add alongside keys•No query performance impact
    19. 19. UUIDs•Add alongside keys•No query performance impact•Easier upgrade path
    20. 20. UUIDs•Add alongside keys•No query performance impact•Easier upgrade path•Translate IDs on save
    21. 21. Exportability
    22. 22. Exportability• Everything
    23. 23. Exportability• Everything•Doesn’t have to be complex
    24. 24. API CLEANUP
    25. 25. Things That Are Not APIs
    26. 26. Things That Are Not APIs • Form submit functions
    27. 27. Things That Are Not APIs • Form submit functions • Form validate functions
    28. 28. Things That Are Not APIs • Form submit functions • Form validate functions • $_GET
    29. 29. If we can’t save things we can’t import them
    30. 30. That’s It
    31. 31. You can throw things now
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.

    ×