FAQ/SLA/Drupal

Presentatie van Henk van Cann over Drupal SLA team tijdens de oprichting op 12 november 2009:
File:Drupal SLA.pdf

Drupal specifiek

Nieuwe projecten

2Value's uitgangspunt in nieuwe projecten en vervolg SLA's zou inzake Drupal moeten zijn:

• zo weinig mogelijk standaard modules gebruiken: in Drupal is maatwerk gemakkelijk en the way to go

Nieuwe SLA's

2Value's uitgangspunt in nieuwe SLA's zou inzake Drupal moeten zijn:

• Acceptabele contrib modules gebruiken: in Drupal is maatwerk gemakkelijk

Een klant moet worden gescand voordat 2Value de site kan accepteren in de SLA
Dat bestaat uit een quick scan en de scan zelf. Het onderscheid wordt gemaakt omdat de meeste klanten naar verwachting niet willen investeren in de scan. Beide zijn een vast aanbod in tijd (en kosten) en leveren best effort op.

Zoveel mogelijk wil 2Value automatisch scannen. Dat vergt investering in een aantal slimme scripts.

Standaard 2Value zaken die hout snijden bij een DRUPAL SLA:

• 1 enkel (technisch of functioneel) aanspreekpunt bij de klant
• Documentatie in het Engels
• OTAP cylcus met SVN

Quickscan

Uit de quick scan rolt een schatting van tijd voor de scan. Onderwerp van onderzoek:

• Hacks; ♥^code, oplossing: reversed engineering
• Drupal 5; ♥^code, oplossing: upgraden

De centrale gedachte is dat we in het onderstaande trachten te onderscheiden hoeveel aanspraak (vragen er op de SLA worden afgevuurd) er is. Commercieel lijkt veel vragen leuk, maar irritatie bij de klant zal hoger zijn en werkplezier bij de SLA teamleden is lager.

Scan

Er moet een draaiboek worden geschreven voor de technische check:

• met automatische hulpmiddelen: DIV tooltje, syntax checker
• beoordeling door expert
• levert op: lijst achterstallig onderhoud (hoeft nu niet opgelost, maar in de toekomst mogelijk wel onder bepaalde omstandigheden (bijvoorbeeld: 8x5 SLA wordt 7x24 SLA)

Scan onderwerpen

• formulieren, domain checks en in hoeverre dwingt de applicatie eenduidige invoer af.
• Documentatie in het Engels ♥^code
• Documentatie volledigheid content ♥^code
  • Functioneel: klant / developer
  • Technisch: automatische check (standaard Drupal deels) / developer / auditor
• Roles: welke rechten zijn hoe verfijnd uitgedeeld (complex -> meer vragen) ♥^code
• Backend: in hoeverre heeft er information hiding plaats gevonden (een beperktere GUI gemaakt zodat er minder vragen komen) ♥^code
• Hoeveel standaard modules draaien er, dat levert meer migratiewerk op bij upgrades ♥^code
• Best Prartices Drupal: in hoeverre voldoet de code daaraan ♥^code
• Je kunt spaghetti programmeren terwijl je aan de regels houdt (erg veel hooks en/of obscure hooks en je bent "lost") ♥^code
• Scan Drupal database: taxonomie en
• Module lijst controle:
  • welke staat Aan/Uit ♥^code
  • welke zijn up to date?! ♥^code
• Modules scan ♥^code
  • Hoe recent gemaintaind, hoeveel mensen werken eraan
  • Errorlog
  • Status rapporten: is de module out of date
  • wel of geen dev/beta modules
  • Standaard open source modules
    • Admin menu
    • Acquia lijst
• Hoe zit het met de inrichting van meertaligheid, standaard i18n of zijn er verbeteringen door gevoerd? Hier kunnen veel vragen over komen.♥^code
• security scan ♥^code

Contrib versus custom

De discussie maatwerk modules vs contrib modules zal per geval gevoerd kunnen worden. Overwegingen die meespelen:

• Maatwerk modules leveren vaak een mooiere oplossing.
• Gebruik van een set stabiele contrib modules minder problemen op zal leveren in overdracht van associate naar associate.
• Een lijstje met veel gebruikte en "acceptabele" modules in een ondersteuningssituatie en een lijstje met overbodige modules. Zie hier de huidige lijst waarin naar hartelust kan worden aangevuld en geschrapt.

Praktijk Hosting

• Hosting: moet melding maken van upgrades' aan het SLA team en draait er cron?!

Mensen

Twee verschillen typen mensen in het SLA team zijn aanvullend:

• de generalist Drupal expert
• de PHP Drupal expert

De grens tussen beide ligt: de generalist vindt zijn weg in het CMS en de technische expert herken je zodra je de code in gaat

Dat de generalist niet voldoende expert zou zijn is uitgesloten. Drupal zelf werpt al zo'n drempel op dat de generalist prima 2de lijns niveau werk kan verrichten en heel plausibel de moeilijke dingen door kan sturen naar de PHP Drupal expert.

Modules

2Value hanteert in haar scans, ontwikkeling en ondersteuning een lijst van acceptabele en overbodige modules. Deze lijst houden we zo goed mogelijk compatible met de trusted list van Acquia.

Acceptabel

♥^code

• views
• cck
• filefield
• imagefield
• date field + date api
• pathauto
• token
• google analytics
• imageapi / cache
• i18n
• metatags (nodewords)
• simplenews
• imce
• wysiwyg
• uebercart
• panels
• organic groups
• ...

Overbodig

♥^code

• poormanscron (want hosting is vastgelegd in sla)
• andere wysiwyg editors dan onze voorkeurskeuze
• ...

To do

• Check Acquia waarom men van geloof is afgevallen en meer modules accepteert dan alleen hun heilige lijst.
• Zijn er testmodules: modules die testen of nieuwe modules aan de richtlijnen voldoen.