Een Drupal Kwaliteitservaring op Ondernemingsniveau

Deze post zal de ervaring samenvatten van het introduceren van drupal in een onderneming. Hoe we een kwaliteitsniveau bereikt hebben in drupal ontwikkeling dat nodig was voor een bedrijfstoepassing.

Het zal ingaan op:

• Setup : De drupal 6 site en de intergratie met andere apps in de onderneming.
• Kwaliteitsniveau
• Testing : Hoe we tests hebben uitgevoerd met gebruik van simpletest en selenium.
• Staging : Hoe we features gebruikt hebben, hook_update (update_api) en het implementeren om onze applicaties neer te zetten in een dev/staging/prod release cycle en de problemen die we tegenkwamen.
• Automatisering : Hoe we ant, shell scripts en drush gebruikt hebben om:
  • Automatiseren van post-install voor staging.
  • Automatisch vrijgeven van versies en testen.
  • Automatisch initialiseren van het project.
• Development Management : Hoe we erin zijn geslaagt om in te schatten en geen zicht te verliezen op alles met betrekking tot het beheer van dit complexe project.
• Garding Performance : Hoe we de performance in de gaten hielden.
• Beveiliging en onderhoud/
• Training Developers : Hoe we het ontwikkelen en het trainen van ontwikkelaars tegelijkertijd combineerde. Met als resultaat dat drupal is opgenomen in de organisatie.
• Conclusie

Setup
Het extranet dat we maken is een venster naar alle interne services. Het doel is om al die gezamelijke gegevens voor deze externe diensten te verzamelen en gebruikers/clients ermee laten communiceren met het gebruik van drupal.
De elementen:

• We hebben de web/php machine wat de drupal installation herbergt.
• Een set aan webservices om een internal server te doorzoeken, wat allelij soorten informatie bevat over de organisatie, klanten, producten, ... Doel is dat klanten deze hosted producten kunnen beoordelen.
• We hebben een service die alle ticketing data houdt dat is gezocht door een webservice om tickets terug te vinden. Het doel is dat klanten tickets kunnen bekijken die op hun betrekking hebben.
• Er is een shell script dat tekst en afbeeldingen terugvindt van een interne wiki om de drupal front end weer te geven.
• Alle verificatie voor drupal en alle andere services is gedaan door een SSO (shibboleth) wat op zijn beurt in contact staat met een LDAP wat alle informatie over klanten bevat. Alles is https omdat pagina's veel gevoelige informatie bevatten over de klanten die de service hosten.
• Taken en machtigingen zijn toegewezen door custom code based op externe regels gevonden van de LDAP.
• Andere interne services die heel oud zijn (1999 old) de organisatie heeft dat gegenereerd html waar blootgesteld met behulp van iframes. Om een url te construeren moesten we elementen terugvinden met behulp van webservices.

Dit is de versie 1.0, intergratie met andere services zoals het intranet, business logic modules, ... zijn nog steeds voorgenomen.

Zoals u kunt zien zou drupal een centrale plek in de onderneming krijgen waarbij het nauw samenwerkt met alle bestaande apps. Sommige nieuwere apps waren ontworpen met een webserver model in het achterhoofd wat andere apps in staat stelt er makkelijk mee te verbinden, wat geweldig is. Aan de andere kant waren sommige legacy apps niet zo vriendelijk en vroegen om een minder aantrekkelijke oplossing.

Dit gaf direct een voordeel aan wat drupal kon hebben in de onderneming. Bedenk bijvoorbeeld dat drupal gebruikt werd om wiki te maken? De services module zou gebruikt kunnen worden om de main drupal te laten communiceren met de wiki. Een eenvoudige en vlekkeloze implementatie. Het zou betekenen dat uw teams alleen drupal hoeven te kennen en niet 10 miljoen andere apps. Een les was geleerd en het intranet van de klant dat voor beoordeling stond gepland zal nu worden overgezet naar een drupal commons.

Kwaliteitsniveau
Alle componenten in de reeks zijn opgezet van local development -> integration -> preproduction -> production.

We werkte in een scrum system met elke week een demo.

Voordat een verhaal verplaatst kon worden naar gedaan en ingezet worden moest het reageren op een "fini fini" wat betekent dat ik moet reageren op een lijst met controlepunten om er zeker van te zijn dat het 100% klaar is.

• Zijn de machtigingen geconfigureerd?
• Is alles vertaald naar Frans?
• Is al het werk gedocumenteerd, met name de patches? (Mensen veranderen voortdurend van positie in grote ondernemingen dus goede docs zijn essentieel)
• Is al het werk getest met behulp van simple test en selenium?
• Zijn alle automatiserings scripts up to date? (post-install, initialisation, test en release scripts)
  Zijn de site conventies voldaan? (bijvoorbeeld expose nieuwe admin links aan een custom admin menu)
• Zijn de prestaties acceptabel? (profile met xhprof)
• Is beveiliging acceptabel? (external team)
• Zijn alle configuraties en vertalingen automatisch exporteerbaar naar de andere omgevingen?
• Kunt u het verhaal over preproductie aan een klant demonstreren?

Vanzelfsprekend is dit kwaliteitsniveau voor de meeste organisaties onbetaalbaar, maar voor een ondernemings app is dit standaard kwaliteit.

Testing
Simple test
Simpletest is de standaard manier om functionaliteit op een drupal site te testen. Hier vindt u een heel goed artikel dat uitlegt wat simpletest doet [http://www.comm-press.de/en/blog/simple-test-drupal].

We gebruikte de shib_auth module om drupals verificatie system te wiren aan de sessie geleverd door shibboleth. Dit betekend dat bijna alle standaard simple testen voor drupal mislukken door deze verificatie. We besloten om de testen geleverd door de standaard drupal module te negeren en richtte ons op onze eigen testen.

We besloten om Simpletest te gebruiken om alle standaard unit testen te doen. Hier is een uitstekend boek dat de principes van unit testing uitlegt [http://www.amazon.com/Pragmatic-Unit-Testing-Java-JUnit/dp/0974514012]. Atomic tests testen onze apis en webservices. De klant heeft reeds een uitgebreide ervaring met unit testen. Het team werd gebruikt om echt test gericht te coderen.

We hadden onmiddelijk een probleem met simpletest. Omdat simpletest een drupal installeert voor elke test is het erg traag. Zelfs met de optimalisatie die hier wordt voorgesteld [http://drupal.org/node/466972] is het nog steeds traag. Te traag om voortdurend testen te doen. Ik vond een artikel op drupal.org [http://drupal.org/node/758662] en kennelijk is het in drupal 7 mogelijk om unit testen uit te voeren met simple test zonder de hele drupal site te sandboxen bij elke test. Het is mogelijk een instance aan te vallen en testen uit te voeren. Dit zou vanzelfsprekend een stuk sneller zijn maar u moet er wel rekening mee houden dat u teardown functies moet schrijven om uw database op te ruimen. Jammer genoeg is deze functie niet aanwezig op drupal 6 en we hadden geen tijd om het te backporten. Dus besloten we alleen testen te doen na het afronden van de functionaliteit. Maar hadden nog steeds onze code getest op het einde.

We schreven testen voor elke functionaliteit en probeerde de testen zo kort mogelijk te houden en we maakte een test file voor elke module die we creëerde. We werkte ook met ant, voornamelijk omdat de klant er veel ervaring mee had en ze wisten hoe ze de output van ant konden integreren met een Hudson server. Simpletest komt met een file runTests.sh wat gestart kan worden door ant. We implementeerde dat zodat we alle testen konden starten, een test per groep en een specifieke test klasse. Hier is het script file. Het script combineert detecting, excluding en cleaning. Natuurlijk gebruikten we waar mogelijk drush.
Nu hadden we alleen hudson om op te zetten. Op elke commit the code base op hudson is geupdate en testen zijn gestart.

Voortdurende intergratie met drupal is mogelijk. Merk op dat in drupal 7 de core het test framewerk bevat zodat u niet de core hoeft te plakken.

Selenium
We kozen selenium om onze functionele tests te doen. Senelium is een geweldige tool wat enige ervaring vereist om het goed te gebruiken. Gelukkig had de klant de ervaring om het doeltreffend te gebruiken. We gebruikte de PEAR phpUnit to code tests voor selenium. Hier is een voorbeeld van een test:

Het is redelijk gemakkelijk om te code testen, u kunt zelfs uw testen samen klikken door middel van de firefox selenium plugin en en exporteer ze voor php.

Met ant zouden we de selenium-server.jar kunnen starten die onze testen opstart.

Maar we hadden wat hindernissen te nemen.

• We moesten selenium laten werken met https. In firefox moet u certificaten exporteren, op ie kunt een variabele instellen.
• We moeten het laten werken op ie. Het installeren van de phpunit op windows gaf wat problemen maar we kregen het voor elkaar.
• We moesten iedere keer langs shibboleth.

Alle obstakels werden beheerd.
Merk op dat het testen met selenium erg duur is. Het is een redelijk traag proces om uit te voeren op meerdere platforms/browsers. Ie had soms een andere aanpak voor het testen nodig wat zelfs nog meer tijd koste. Maar u weet zo goed als zeker dat de app doet wat u wilt. Om een idee te geven nam het 20% van de dev tijd per verhaal om een volledige selenium test te schrijven.

Staging
We maakte alle configuraties draagbaar door gebruik van een methode die in principe bestaat uit features, deploy en hook update. bekijk staging problem:http://dominiquedecooman.com/blog/drupal-staging-problem

Nieuw is heir dat we ook een patch bijdroegen met onze functies om update_api module http://drupal.org/project/update_api dus we hadden een toolkit om in de hook update te gebruiken.
Hier is een stuk code van ons install file waar onze hook updates verblijven.

Hier raakte we tevens een pijnpunt dat drupal heeft, namelijk enkele slechte core apis. Ik denk dat iedereen op de hoogte is van dit probleem, Dries heeft het als zijn eerste prioriteit gezet voor drupal 8 [http://buytaert.net/8-steps-for-drupal-8 Stap1 : Creëer een betere scheiding tussen framework en product]. Dus ik denk dat het probleem bekend is. Daar we elke verandering die we maakte moesten coderen met UI kwamen we veel ontbrekende apis tegen.

Probeer bijvoorbeeld een thema te veranderen en zijn vars te configureren. Of gebruik de submit functie om een role te verwijderen, ... Ik zeg niet dat het niet mogelijk is maar het probleem is dat je echt in de core functies moet graven, alle acties en moet begrijpen en de benodigde moet vergaren om te doen wat nodig is. Als u veel ervaring heeft en u weet uw weg in de core code komt u er wel uit, maar dit betekend dat iedereen die een stageable site wilt hebben, en bijna elke ondernemingsklant heeft dit nodig, een hoop tijd moet investeren in het trainen van mensen tot ze dit expertiseniveau hebben.

Betere apis zouden drupal gemakkelijker te begrijpen maken en daardoor zal de investering in training afnemen en drupal zal beter aangepast zijn.
Betere core apis zullen drupal geschikter en beter integreerbaar maken vanuit een ontwikkelaars oogpunt.

Automatisering
Automatiseer post-install voor staging
De organisatie heeft een ontwikkelingstool wat in principe een tarball neemt en het op de server zet. Nadat het is ingezet wordt een post install script gedaan. Samen met drush kregen we het voor elkaar om het noodzakelijke op te zetten om drupal implementeren. (Merk op dat om drush zijn uitkomst compleet te renderen, we een aantal aanpassingen hebben gedaan).

Automatisch vrijgeven van versies en testen.
Voordat u kon maken en vrijgeven hebben we het verplicht gesteld dat alle testen geplakt werden. Nadat dit gebeurd was een svn versie werd getagged en een tarball gemaakt.

Automatisch initializeren van het project.
Daar we veel testen en intergraties hebben met andere apps zoals LDAP, internal config, wiki, ... Hebben we een init file gemaakt dat onze drupal zou vullen met externe apps met daa voor een (gebruiker, content,) test spel. Het resultaat is een initialisatie script dat deze taak automatisch uitvoert.

Alle scripten worden gedraaid vanaf de terminal middels "ant".

Het gebruik van bash scripts en drush maakte ons leven een stuk gemakkelijker. Het heeft een investering nodig om ze te maken maar ze zijn een enorme tijdsbespaarder op de lange termijn.

Als een nieuwe ontwikkelaar bijvoorbeeld een workstation moet opzetten bekijkt hij een functionerend kopie, hij draait het init script en is klaar om te starten. Hij codeert. Hij doet testen. Hij maakt zijn release, svn is getagged. For example when a new developer needs to set up his workstation he checks out a working copy, he runs the init script and he is ready to go. He codes. He runs his tests. He creates his release, svn is tagged. Implementeerd zijn tarball op de server en de post install script zal gevraagd worden de hook updates uit te voeren en config stored met feature module in te zetten. Bedenk hoeveel tijd dit zou kosten om het handmatig te doen?

Development management
Om de doorlooptijd van een complex project als dit in te schatten moet u voorbij de features die op het scherm zullen verschijnen kijken. Dit is niet altijd makkelijk uit te leggen. Als een klant en gebruiker ziet u de testen, de scripts, de staging, de docs, de performance tweaks, de beveiligingsupdates, de platform installatie, ... niet (hopelijk) ziet u alleen een app die altijd werkt. Dit is dankzij al het werk dat zich achter de schermen afspeelt.

Om elk verhaal in te schatten gebruiken we grofweg deze sleutel om een schatting te maken voor de verstreken tijd. Merk op dat al het werk is gedaan door pair programming. (uren gebaseerd op 40uur)

• 35% ontwikkeling van de feature. (14h)
• 30% schrijven en uitvoeren van tests + refactoring code accordingly (12h)
• 10% implementatie (exporteren van features, schrijven van hook updates, deploying) (4h)
• 5% scripts (2h)
• 5% doc (2h)
• 5% demo (2h)
• 10% vertaling, perf, security, permissions, conventions. (afhankelijk van de aard van de functie) (4h)

Om dit project te beheren moesten we met veel mensen in het bedrijf samenwerken. Dit is niet altijd tijd die aan het eind van de week tevoorschijn komt. Bijvoorbeeld voor het uitvoeren van een webservice moet je mensen in Parijs bellen om de juiste urls te krijgen. Dit kan snel enkele uren duren.

Hoe zijn we niks uit het oog verloren? We kozen om met scrum te werken. Het scrum proces beschermde ons van ondergesneeuwd raken in de verzoeken om dit en dat te introduceren en tegelijkertijd behendig te blijven. Het stelde ons in staat om juiste inschattingen te maken en te ontwikkelen op maximale productiviteit waarmee functionaliteit geleverd werd waar iedereen mee instemde.

Garding Performance
We zijn alleen verantwoordelijk voor de prestaties op het applicatie niveau. Alle andere prestatie tweaks op server niveau zijn uitgevoerd door de bedrijfs teams. Bijvoorbeeld het integreren van memcached in drupal is onze taak, het installeren van de deamon op de server niet.

Om de prestatie in de gaten te houden gebruikte we de profiller xhprof wat gebruikt kan worden met devel. Het installeren is gemakkelijk (http://techportal.ibuildings.com/2009/12/01/profiling-with-xhprof/)

Door deze tool te gebruiken kunnen we elke pagina monitoren om te zien of er zich enige prestatie problemen voordoen. We detecteerde bijvoorbeeld dat een verzoek aan webservice erg traag was. Met xhprof is dat onmiddelijk duidelijk, u kunt de werkelijke cpu time die nodig was vergelijken met de totale duur om te laden. Dit liet ons zien dat onze app in feite aan het wachten was op de andere server. We stelde het andere team ervan op de hoogte, zij vonden een probleem met een van de sql servers en repareerde dit.Xhprof is zeker een tijdsbespaarder.

Het werken met een profiller laat je zien hoe de app is gestructureerd, het het framework werkt, wat is uitgevoerd,... Het is iets waar je veel van kan leren. Xhprof samen met gezond verstand zal je voortdurend aan prestatie laten denken.

Beveiliging en onderhoud
Beveiliging was een belangrijk punt in dit project daar het gevoelige informatie bevat van klanten en de organisatie.
Een audit zal worden uitgevoerd door een externe entity.
We waren alleen verantwoordelijk op het drupal applicatie niveau voor beveiliging. Aan de server kant hadden we https, sso, authentication proxy, ... maar dit was niet onze taak.

We controleerde altijd als onderdeel van onze "fini fini" dat alle form, url, ... input opgeschoond was zodat zich geen sql of xss attacks konden voordoen.

We volgden altijd nieuwe security releases voor modules en core. Modules die gepatched waren werden verplaatst naar een aparte folder. Patches werden gedocumenteerd zodat bij core/module release men kon onderzoeken of er patches waren en of het nogsteeds nodig was om ze opnieuw toe te passen.

Ik ben geen beveiligings expert maar het dubbel checken van input en output en het volgen van updates is een goede basis strategie om slechte dingen te voorkomen. Audits door beveiligingsexperts zijn zeker nodig wanneer u met belangrijke data werkt.

Het trainen van developers
Dit was waarschijnlijk de grootste uitdaging. Hoe train je een team van reeds ervaren php developers om drupal te gebruiken en een app te leveren die aan de kwaliteitsstandaarden voldoet. Hoe breng je kennis zo effectief mogelijk over? Hoe maak laat je het team zelfstandig werken?

De methode die wij gebruikte was waarschijnlijk niet de snelste maar ik denk op de lange termijn de meest effectieve. In plaats dat ik dingen ontwikkelde hebben we meteen de teamleden laten ontwikkelen.

Daar we probeerde een product af te krijgen hebben we niet de volgende aanpak gevolgd: een node is blabla, een block is blabla, ... En ik ben blij dat we dat niet gedaan hebben want dat was voor iedereen heel saai geweest en na een maand hadden we dan nog geen module gecodeerd.

We legde de vraag voor wat willen we doen? Bijvoorbeeld we willen data x van source y terugkrijgen met een webservice en het weergeven aan gebruiker z met een role en machtigingen onder de voorwaarden a,b,c. Hoe doe je dit in drupal? Om deze vraag te beantwoorden raak je een hoop concepts, modules en apis.

Dus ik heb de oplossing ontworpen en vervolgens legde ik elk concept uit dat nodig was om de functionaliteit volbrengen. Van blocks tot modules, hooks, apis, ... Elke keer wanneer we een concept tegen komen zou ik het in detail uitleggen en hoe het als een puzzelstukje past.
Natuurlijk ligt de werkelijke kracht van leren in herhaling en oefening. Dus het theming system bijvoobeeld is waarschijnlijk drie keer uitgelegd. Met als beginpunt, we willen output renderen met gebruik van html, hoe doen we dat?

De eerste paar weken tasten ze nog steeds een beetje in het duister maar naar mate de tijd verstreek zagen ze hoe drupal gebruikt werd: Waarbij functionaliteit werd gemaakt door middel van bestaande code en het integreren met elkaar door configuratie en custom codes te gebruiken. Spoedig werd de geweldige kracht van drupal duidelijk voor hen, ze leerde om drupal.org te doorzoeken wanneer ze in de problemen kwamen, we plaatste vraagstukken, we hebben zelfs bijgedragen aan een kleine module (http://drupal.org/project/jquery_jstree).

Ze konden zien dat deze grote gemeenschap codes maakte en verbeterde. Bijna alles wat we wilden doen werd geleverd door een module en manieren om ermee te communiceren. Het was duidelijk dat met het begrijpen van zes concepten men bijna alles kan doen met drupal. Op deze zes punten konden we onszelf regelmatig meten, we stelde vast:

• Framework
• Core + APIs
• Contrib Modules + APIs
• Managing code, confifuration en content (features,deploy,hook_update,drush & use of scripts)
• Combineren van bestaande modules
• Best practices
• Data
• Interne data
• database: data types (node, taxonomy, ...)
• session
• Externe data : Webservices
• Interactie met gebruikerss
• Gebruikers
• Verificatie
• Access models
• Interactie met data
• Kwaliteit
• Prestatie
• Tests
• Beveiliging
• UI
• Informatiearchitectuur door het combineren van modules en het gebruik van hun apis om te integreren. (views, cck, panels, block, taxonomy, contexts...)
• Jquery
• Templating
• Oplossen van problemen
• Hoe bugs te traceren
• Tools (devel, logs, debugger, xhprof, ...)
• Gebruik Drupal.org, vraag hulp van community

De reden dat drupal zo'n sterke leercurve heeft is omdat je veel kleine dingen moet weten die individueel niet zo moeilijk zijn, maar het probleem is dat er veel van die dingen zijn. Met name wanneer u een app wilt maken op ondernemingsniveau.
Op dit niveau heb je een hoop kennis van veel concepten nodig om de boel operationeel te krijgen. Bijvoorbeeld: Hoe stage je config en content? Hoe creëer je een test? ...

Tijdens het oplossen van deze vragen creëer je je eigen functionaliteit. Je wordt geintroduceerd met honderden concepten, blocks, nodes, taxonomy, views, cck, fields, formatters, feature, rules, ...
Om een functionaliteit te creëeren moet je weten welke modules te gebruiken en hoe je deze configureert.
Wanneer je je eerste functionaliteit bereikt met gebruik van de bestaande concepten en modules wil je het ding uitbreiden met hooks, apis, in uw eigen modules.

Om drupal effectief te gebruken moet je dingen combineren. Om dat te kunnen doen moet je weten dat dingen bestaan. Daardoor is de leercurve sterk.

Echter wanneer je dit niveau bereikt kom je erachter dat alles mogelijk is met drupal.
In feite waren de ontwikkelaars zo enthousiast dat ze zich afvroegen waarom ze nogsteeds dingen vanuit niks bouwde? Drupal geeft ons de voorsprong die we nodig hebben. We doen steeds hetzelfde. Waarom onderhouden we tien verschillende apps? Nu kunnen we het framewerk vertrouwen en ons richten op het ontwikkelen van leuke dingen in plaats van het steeds opnieuw bouwen van het framework. Ze begonnen zelfs aan hun bazen voor te stellen om nieuwe projecten te starten in drupal.

Hoewel drupal geen magische oplossing is. Het is niet klik klik klik klaar. Je moet nog steeds werk verrichten. Maar het biedt niet alleen een framework maar een compleet universum.

BEWERK: Ik heb een tijd aan deze post gewerkt en toen ik Dries z'n keynote zag en hij had het erover dat het beste ecosystem zal winnen. Dat denk ik ook. Deze ervaring heeft me duidelijk gemaakt dat precies is wat de klant wil. Een ecosystem waar iedereen graag mee werkt.

Conclusie
Voor mij was het een goede ervaring, ik leede veel en ik kan alleen nog toevoegen dat drupal klaar is om bedrijfsniveau kwaliteit te bieden.

BEWERK : Na het zien van Dries z'n keynote vanmorgen. Ook al doet Drupal 6 al goed werk en Drupal 7 zal nog beter zijn. Als de gemeenschap de door Dries genoemde punten kan bereiken zoals staging config en content, serving data in multiple formats en het verbeteren van de apis dan zal Drupal 8 echt DE killer enterprise content app zijn.

BEWERK:Scripts zijn verwijderd