Difference between revisions of "FAQ/SLA/Drupal"

From 2value wiki 2
Jump to navigation Jump to search
2value>Interwiki linking script
 
(28 intermediate revisions by 2 users not shown)
Line 1: Line 1:
Presentatie van Henk van Cann over Drupal SLA team tijdens de oprichting op 12 november 2009:<br/>
+
[[Category:SLA]]
 +
==Zie ook==
 +
*Presentatie van Henk van Cann over Drupal SLA team tijdens de oprichting op 12 november 2009:<br/>
 
[[File:Drupal_SLA.pdf]]
 
[[File:Drupal_SLA.pdf]]
  
=== Drupal specifiek ===
+
== De vijf meest voorkomende vragen ==
 +
....zitten vast en zeker in de algemene sfeer: klik [[public:SLA|SLA]] en verder.
  
2Value's uitgangspunt in projecten en SLA's zou inzake Drupal moeten zijn:
+
== Drupal specifiek ==
* zo weinig mogelijk standaard modules gebruiken: in Drupal is maatwerk gemakkelijk en the way to go
+
Een aantal vragen steken er boven uit in geval van Drupal
Een klant moet worden gescand voordat 2Value de site kan accepteren in de SLA<br/>
 
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.  
+
===Kan 2Value alle projecten in service nemen?===
 +
2Value accepteert pas een SLA indien een klant bereid is te investeren in respectievelijk de [[#Quickscan | quick scan]] en daarna de [[#Scan|scan]]. Als uit de scan blijkt dat de noodzakelijke aanpassingen voor betrouwbare en beheerbare service op het systeem:
 +
#zijn te overzien, en
 +
#door klant worden gefinancierd
 +
dan kan het 2Value SLA team een project in service nemen.
  
Standaard 2Value zaken die hout snijden bij een DRUPAL SLA:
+
===Drupal experts die alles kunnen zijns schaars. Hoe vind je die?===
* 1 enkel (technisch of functioneel) aanspreekpunt bij de klant
+
Een SLA-team bestaat bij voorkeur (!) uit verschillende typen [[#Mensen | mensen]]. Ze vullen elkaar aan, doen wat ze het best kunnen om de volledige range van soorten [[FAQ:SLA#voorbeeld_servicevragen_van_een_Drupal_klant|servicevragen]] van eindgebruikers-organisaties te kunnen afdekken.
* 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|red}}, oplossing: reversed engineering
 
*Drupal 5; {{code|orange}}, 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
 
* 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.
 

Latest revision as of 03:56, 10 April 2013

Zie ook

  • 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

Kan 2Value alle 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.