KISS OMG FTW

Drupalhagen 2014 talk about strategies for Git repository structures and tools to support good workflows.

Transcript

1. KISS OMG FTW Vi er hurtige til at hive nye værktøjer ind men nogle gange gør de vores liv mere kompliceret end godt er. OMG (One Massive Git repository) dropper Drush Make
2. WTF? • Some history about how we managed code in the past • Some reasoning about pros and cons • What we ended up doing • Some talk and examples (Fini on Deployotron) • Some more talk and more examples (Mads on Bandaid)
3. Partners in crime Arne Jørgensen - Twitter: @arnejoergensen - Drupal.org: arnested Thomas Fini Hansen - Twitter: @xendk - Drupal.org: Xen Mads Høgstedt Danquah - Twitter: @danquah - Drupal.org: danquah
4. Back in the old days... • We threw everything in one Git repos • Upgrading was troublesome • Because patches and hacks got lost • So we started using drush make... • And we were happy
5. Until we realized that... • Although it was an improvement... • It Drush Make comes with its own bag of problem • We started thinking (OMG!)
6. So what do we actually want • Use a branching workflow (i.e. git-flow) • Fast builds and deploys • Not too many points of failure • Avoid Not-Invented-Here
7. Four approaches to repos structures • Git submodules • Composer • Drush Make • Everything in one monolithic git repos
8. Git submodule • Proven technology • No way to build a Drupal Core with modules inside • No way to handle patches
9. Git submodule Composer • Proven technology • No way to build a Drupal Core with modules inside • No way to handle patches
10. Git submodule Composer • Proven technology • No way to build a Drupal Core with modules inside • No way to handle patches • Extend via Composer plugins • Used by Symfony2
11. Drush Make • Good tracking of: ◦ modules ◦ versions ◦ patches • Branching is troublesome • Multiple failure points • What did I change? Re-make? • Less than perfect error handling • Large make files and recursive make files • Problems don’t fit on one slide
12. One monolithic git repos Pros • Branching is easy • Build times are fast • No need for tools other than git Cons • Tracking of modules, versions, and patches • Upgrades? • Doesn’t feel right...
13. But let’s remember… Employees at Reload are:
14. But let’s remember… Employees at Reload are: Skilled,
15. But let’s remember… Employees at Reload are: Skilled, responsible
16. But let’s remember… Employees at Reload are: Skilled, responsible grownups
17. But let’s remember… Employees at Reload are: Skilled, responsible grownups If you fit the description we are hiring...
18. 80% • Unpatched, stable Drupal.org modules have all info in the .info file • Upgrades is just a “drush up” away • Let’s just document the remaining 20%
19. Kilroy patched this! Arne added the patch from http://drupal.org/files/secure_permissions- duplicate_role_exception-1744274-4.patch' so that we ignore exceptions related to attempts to create roles that are already present on the site. There is an upstream issue with more details at https://drupal.org/node/1744274
20. Kilroy patched this! Or a bit more structured: patch: 'http://drupal.org/files/secure_permissions-duplicate_role_exception -1744274-4.patch' home: 'https://drupal.org/node/1744274' reason: 'Ignores exception related to attempts to create roles that are already present on the site'
21. Kilroy patched this! Or a bit more structured: patch: 'http://drupal.org/files/secure_permissions-duplicate_role_exception -1744274-4.patch' home: 'https://drupal.org/node/1744274' reason: 'Ignores exception related to attempts to create roles that are already present on the site' OMG - That’s YAML! sites/all/modules/secure_permissions.yml
22. Basically that’s OMG • One Massivi Git repository • Document the stuff that differs in YAML • Act like a grown up • No need for any tools
23. Deployotron
24. https://asciinema.org/a/12775
25. Some features • Verbose • Maintainance mode • Dumping database • Fast
26. Cowboy coding
27. More features • Restart Apache2/Varnish • VERSION.txt • New Relic/Flowdock • Install in sites/all/drush • OMG command
28. reload.aliases.drushrc.php reload.aliases.drushrc.php
29. Current limitations • One server deployments • No D8 support yet • No submodules
30. Links http://reload.github.io/deployotron/ https://github.com/reload/deployotron
31. Bandaid
32. Why we <3 patches • They let us contribute the change we had to make anyways back to the community. • They gives us access to others fixes right away without having to wait on releases. • But - we have to keep the process of using patches quick and easy or we just won’t bother
33. Patching in OMG Make did all the work for us, now we have to • Keep track of our patches • Be able to reapply after a module-upgrade • Remember why we applied the patch in the first place Drush-make have make-files, we have YAML
34. all YAML all the way • We place a .yml file next to the module • It contains ◦ The patch URL ◦ A “home” url (issue link) ◦ A description of why we need it • Yaml - because then we can script the modification of the file.
35. Sample yml-file - patch: 'http://drupal.org/files/secure_permissions-duplicate_role_exception -1744274-4.patch' home: 'https://drupal.org/node/1744274' reason: 'Ignores exception related to attempts to create roles that are already present on the site' - patch: 'http://drupal.org/files/secure_permissions-permissions-not-set-bug -1406892-d7-7.patch' home: 'https://drupal.org/node/1406892' reason: 'Fixes an issue where empty roles blocks other roles from getting permissions. Committed to dev so can be skipped when 1.6 is released.' … Great, but really - who wants to maintain yaml-files by hand?
36. Bandaid to the rescue • Bandaid - a drush command that ◦ Applies patches ◦ Keeps the .yml updated ◦ Detects unauthorized changes ◦ Makes it as easy as possible to upgrade and re-patch modules ◦ And it does it all by using enough git internally to qualify as actual magic!
37. Live Demotime • bandaid-patch • bandaid-apply • bandaid-diff • bandaid-tearoff ….what can possible go wrong?
38. Wrapup - status • Current status ◦ Module patching is fully supported ◦ Core patching is a work-in-progress (patch+apply works) • We (reload) use bandaid. • A “large danish media-house” is currently converting from make to OMG and bandaid
39. Wrapup near-furture stuff • We’re considering a “scan all my modules and detect modifications” command • Full(er) core support • Support for custom content in the .yml files • We welcome issues and pull-requests against https://github.com/xendk/bandaid