|
2value>Interwiki linking script |
| (18 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]] |
| | | | |
| | == De vijf meest voorkomende vragen == | | == De vijf meest voorkomende vragen == |
| − | ....zitten vast en zeker in de algemene sfeer: klik [[SLA]] en verder. | + | ....zitten vast en zeker in de algemene sfeer: klik [[public:SLA|SLA]] en verder. |
| | | | |
| − | === Drupal specifiek ===
| + | == Drupal specifiek == |
| | Een aantal vragen steken er boven uit in geval van Drupal | | Een aantal vragen steken er boven uit in geval van Drupal |
| | | | |
| − | =====Moeten we wel '''contrib''' modules gebruiken?===== | + | ===Kan 2Value alle projecten in service nemen?=== |
| − | De overwegingen [[#Contrib versus custom|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 [[#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: | | 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 | | #zijn te overzien, en |
| Line 17: |
Line 16: |
| | dan kan het 2Value SLA team een project in service nemen. | | dan kan het 2Value SLA team een project in service nemen. |
| | | | |
| − | == Uitgangspunten == | + | ===Drupal experts die alles kunnen zijns schaars. Hoe vind je die?=== |
| − | ====Nieuwe projecten====
| + | 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. |
| − | 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:
| |
| − | * [[#Modules | Acceptabele contrib modules]] gebruiken: in Drupal is maatwerk gemakkelijk
| |
| − | 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.
| |
| − | | |
| − | 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 Agreements==
| |
| − | === 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 {{code | yellow}}
| |
| − | * Documentatie volledigheid content {{code | orange}}
| |
| − | ** Functioneel: klant / developer
| |
| − | ** Technisch: automatische check (standaard Drupal deels) / developer / auditor
| |
| − | * Roles: welke rechten zijn hoe verfijnd uitgedeeld (complex -> meer vragen) {{code | yellow}}
| |
| − | * Backend: in hoeverre heeft er information hiding plaats gevonden (een beperktere GUI gemaakt zodat er minder vragen komen) {{code | green}}
| |
| − | * Hoeveel standaard modules draaien er, dat levert meer migratiewerk op bij upgrades {{code | green}}
| |
| − | * Best Prartices Drupal: in hoeverre voldoet de code daaraan {{code | orange}}
| |
| − | * Je kunt spaghetti programmeren terwijl je aan de regels houdt (erg veel hooks en/of obscure hooks en je bent "lost") {{code | yellow}}
| |
| − | * Scan Drupal database: taxonomie en
| |
| − | * Module lijst controle:
| |
| − | ** welke staat Aan/Uit {{code | green}}
| |
| − | ** welke zijn up to date?! {{code | yellow}}
| |
| − | * Modules scan {{code | yellow}}
| |
| − | ** 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
| |
| − | *** [http://acquia.com/products-services/acquia-drupal-modules 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 | yellow}}
| |
| − | * security scan {{code | orange}}
| |
| − | | |
| − | === 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 [[#modules | 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 [http://acquia.com/products-services/acquia-drupal-modules ''trusted list'' van Acquia].
| |
| − | | |
| − | ====Acceptabel====
| |
| − | {{code | yellow}}
| |
| − | *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 | yellow}}
| |
| − | *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.
| |
