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
2Value's uitgangspunt in projecten en SLA's zou inzake Drupal moeten zijn:
- zo weinig mogelijk standaard modules gebruiken: in Drupal is maatwerk gemakkelijk en the way to go
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:
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
- Documentatie volledigheid content
- Functioneel: klant / developer
- Technisch: automatische check (standaard Drupal deels) / developer / auditor
- Roles: welke rechten zijn hoe verfijnd uitgedeeld (complex -> meer vragen)
- Backend: in hoeverre heeft er information hiding plaats gevonden (een beperktere GUI gemaakt zodat er minder vragen komen)
- Hoeveel standaard modules draaien er, dat levert meer migratiewerk op bij upgrades
- Best Prartices Drupal: in hoeverre voldoet de code daaraan
- Je kunt spaghetti programmeren terwijl je aan de regels houdt (meer dan 30 hooks en je bent lost)
- Scan Drupal databass: taxonomie en
- Module lijst:
- Aan/Uit
- up to date?!
- Modules scan
- 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 n8i of zijn er verbeteringen door gevoerd? Hier kunnen veel vragen over komen.
- security scan
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.
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.
