Drupalhagen 2014 kiss omg ftw

Post on 30-Jun-2015

104 views 2 download

description

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

Transcript of 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

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)

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

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

Until we realized that...

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

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

Four approaches to repos structures

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

Git submodule

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

Git submodule Composer

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

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

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

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...

But let’s remember…

Employees at Reload are:

But let’s remember…

Employees at Reload are:

Skilled,

But let’s remember…

Employees at Reload are:

Skilled, responsible

But let’s remember…

Employees at Reload are:

Skilled, responsible grownups

But let’s remember…

Employees at Reload are:

Skilled, responsible grownups

If you fit the description we are hiring...

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%

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

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'

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

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

Deployotron

https://asciinema.org/a/12775

Some features

● Verbose● Maintainance mode● Dumping database● Fast

Cowboy coding

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

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

Bandaid

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

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

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.

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?

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!

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

….what can possible go wrong?

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

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