FAQ/SLA/Drupal

Verbinding met andere wiki onderdelen:

• Het plannen en organiseren van 2Value:Events_management:small_session meetings voor het SLA team.
• Presentatie van Henk van Cann over Drupal SLA team tijdens de oprichting op 12 november 2009:
  

File:Drupal SLA.pdf

De vijf meest voorkomende vragen

....zitten vast en zeker in de algemene sfeer: klik SLA en verder.

Drupal specifiek

Een aantal vragen steken er boven uit in geval van Drupal

Moeten we wel contrib modules gebruiken?

De overwegingen voor of tegen contrib hangen samen met het soort dienstverlening en de specifiek het systeem waar het om draait. Heb je teamwerk in een Service Level agreement dan hel je meer over naar de custom zijde (uitwisseling kennis en uniform begrip van het systeem), anders geldt dat in nieuwbouw maatwerk (custom modules) in Drupal gemakkelijk is en te verkiezen boven contrib modules.

Willen we zomaar projecten in service nemen?

2Value accepteert pas een SLA indien een klant bereid is te investeren in respectievelijk de quick scan en daarna de scan. Als uit de scan blijkt dat de noodzakelijke aanpassingen voor betrouwbare en beheerbare service op het systeem:

1. zijn te overzien, en
2. door klant worden gefinancierd

dan kan het 2Value SLA team een project in service nemen.

Drupal experts die alles kunnen zijns schaars. Hoe vind je die?

Een SLA-team bestaat bij voorkeur (!) uit verschillende typen mensen. Ze vullen elkaar aan, doen wat ze het best kunnen om de volledige range van soorten servicevragen van eindgebruikers-organisaties te kunnen afdekken.

Uitgangspunten

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

Terms of Agreement

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

In quick scan en scan willen we weten hoeveel aanspraak er komt (welke vragen er op de SLA worden afgevuurd). Commercieel lijkt veel vragen leuk. Er zijn tegenargumenten:

1. veel moeten bellen wekt irritatie bij de klant
2. het werkplezier bij de SLA teamleden is hoger als er efficienter kan worden gewerkt in een geoliede machine

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 kan minder problemen opleveren 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 onderstaande 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
• ...

Banned

♥^code
Het is aan het SLA team om te besluiten of een door Acquia uitgebannen module (Zie trusted list van Acquia) in beheer en onderhoud kan worden genomen.

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.