Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Viewers also liked (13)
Similar to Staging and Deployment Project
Similar to Staging and Deployment Project (20)
Recently uploaded
Recently uploaded (20)
Staging and Deployment Project
- 1. STAGING AND DEPLOYMENT PROJECT GREG DUNLAP (@HEYROCKER) DATE CLIENT 3/8/2011 DRUPALCON CHICAGO
- 3. •The Problem •A Rant •Some Ideas
- 4. The Problem
- 6. •Data smooshage •ID Conflicts •API issues
- 7. A Rant
- 8. WE DO NOT HAVE A CONFIGURATION MANAGEMENT PROBLEM
- 9. WE HAVE AN EVERYTHING MANAGEMENT PROBLEM
- 10. THERE IS NO DIVIDE BETWEEN CONFIGURATION AND CONTENT IN DRUPAL
- 11. STOP PRETENDING
- 12. TREAT THINGS AS THINGS AND WE CAN SOLVE THE PROBLEM FOR REAL
- 14. Some Ideas
- 15. •Reliably unique IDs •Everything exportable •API cleanup
- 17. Reliably Unique IDs • UUIDs or Machine Names
- 18. Reliably Unique IDs • UUIDs or Machine Names •Apply as appropriate
- 19. UUIDs
- 21. UUIDs •Add alongside keys •No query performance impact
- 22. UUIDs •Add alongside keys •No query performance impact •Easier upgrade path
- 23. UUIDs •Add alongside keys •No query performance impact •Easier upgrade path •Translate IDs on save
- 24. Exportability
- 26. Exportability • Everything •Doesn’t have to be complex
- 27. API CLEANUP
- 28. Things That Are Not APIs
- 29. Things That Are Not APIs • Form submit functions
- 30. Things That Are Not APIs • Form submit functions • Form validate functions
- 31. Things That Are Not APIs • Form submit functions • Form validate functions • $_GET
- 32. If we can’t save things we can’t import them
- 33. That’s It
- 34. You can throw things now
Editor's Notes
- 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