Drupalhagen 2014 kiss omg ftw

39
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

description

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

Transcript of Drupalhagen 2014 kiss omg ftw

Page 1: Drupalhagen 2014   kiss omg ftw

KISS OMG FTWVi 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

Page 2: Drupalhagen 2014   kiss omg ftw

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)

Page 3: Drupalhagen 2014   kiss omg ftw

Partners in crimeArne Jørgensen

- Twitter: @arnejoergensen- Drupal.org: arnested

Thomas Fini Hansen- Twitter: @xendk- Drupal.org: Xen

Mads Høgstedt Danquah- Twitter: @danquah- Drupal.org: danquah

Page 4: Drupalhagen 2014   kiss omg ftw

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

Page 5: Drupalhagen 2014   kiss omg ftw

Until we realized that...

● Although it was an improvement... ● It Drush Make comes with its own bag of problem● We started thinking (OMG!)

Page 6: Drupalhagen 2014   kiss omg ftw

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

Page 7: Drupalhagen 2014   kiss omg ftw

Four approaches to repos structures

● Git submodules● Composer● Drush Make● Everything in one monolithic git repos

Page 8: Drupalhagen 2014   kiss omg ftw

Git submodule

● Proven technology● No way to build a Drupal Core with modules inside● No way to handle patches

Page 9: Drupalhagen 2014   kiss omg ftw

Git submodule Composer

● Proven technology● No way to build a Drupal Core with modules inside● No way to handle patches

Page 10: Drupalhagen 2014   kiss omg ftw

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

Page 11: Drupalhagen 2014   kiss omg ftw

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

Page 12: Drupalhagen 2014   kiss omg ftw

One monolithic git repos

Pros● Branching is easy● Build times are fast● No need for tools other than gitCons● Tracking of modules, versions, and patches● Upgrades?● Doesn’t feel right...

Page 13: Drupalhagen 2014   kiss omg ftw

But let’s remember…

Employees at Reload are:

Page 14: Drupalhagen 2014   kiss omg ftw

But let’s remember…

Employees at Reload are:

Skilled,

Page 15: Drupalhagen 2014   kiss omg ftw

But let’s remember…

Employees at Reload are:

Skilled, responsible

Page 16: Drupalhagen 2014   kiss omg ftw

But let’s remember…

Employees at Reload are:

Skilled, responsible grownups

Page 17: Drupalhagen 2014   kiss omg ftw

But let’s remember…

Employees at Reload are:

Skilled, responsible grownups

If you fit the description we are hiring...

Page 18: Drupalhagen 2014   kiss omg ftw

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%

Page 19: Drupalhagen 2014   kiss omg ftw

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

Page 20: Drupalhagen 2014   kiss omg ftw

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'

Page 21: Drupalhagen 2014   kiss omg ftw

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

Page 22: Drupalhagen 2014   kiss omg ftw

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

Page 23: Drupalhagen 2014   kiss omg ftw

Deployotron

Page 24: Drupalhagen 2014   kiss omg ftw

https://asciinema.org/a/12775

Page 25: Drupalhagen 2014   kiss omg ftw

Some features

● Verbose● Maintainance mode● Dumping database● Fast

Page 26: Drupalhagen 2014   kiss omg ftw

Cowboy coding

Page 27: Drupalhagen 2014   kiss omg ftw

More features● Restart Apache2/Varnish● VERSION.txt● New Relic/Flowdock● Install in sites/all/drush● OMG command

Page 29: Drupalhagen 2014   kiss omg ftw

Current limitations● One server deployments● No D8 support yet● No submodules

Page 31: Drupalhagen 2014   kiss omg ftw

Bandaid

Page 32: Drupalhagen 2014   kiss omg ftw

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

Page 33: Drupalhagen 2014   kiss omg ftw

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

Page 34: Drupalhagen 2014   kiss omg ftw

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.

Page 35: Drupalhagen 2014   kiss omg ftw

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?

Page 36: Drupalhagen 2014   kiss omg ftw

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!

Page 37: Drupalhagen 2014   kiss omg ftw

Live Demotime● bandaid-patch● bandaid-apply● bandaid-diff● bandaid-tearoff

….what can possible go wrong?

Page 38: Drupalhagen 2014   kiss omg ftw

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

Page 39: Drupalhagen 2014   kiss omg ftw

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