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

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