FINAL REPORT. Bachelor project IN3405. (vervangend ST coördinator bachelorproject TU Delft)

RT FINAL REPO Bachelor pr oj ec t

TECHNISCHE UNIVERSITEIT DELFT FACULTEIT EWI JOHN CIOCOIU

1358227

ELWIN DOKTER

1275909

12 juli 2010

Ing. D.J. van Roest Ir. H.J.A.M. Geers Ir. B.R. Sodoyer Ir. C. Pronk

(opdrachtgever Reprovinci Internetdiensten B.V.) (begeleider TU Delft) (ST coördinator bachelorproject TU Delft) (vervangend ST coördinator bachelorproject TU Delft)

IN3405

Voorwoord D

e laatste fase van de bacheloropleiding Technische Informatica aan de Technische Universiteit Delft behelst de uitvoering van het zogenaamde bachelorproject. Dit project is mogelijk in de vorm van een stage, intern of bij een externe opdrachtgever. Het doel is de student ervaring bij te brengen in het zelfstandig uitvoeren van een project en het doorlopen van het gehele software‐ontwikkeltraject. Het laatste kwartaal is volledig gereserveerd voor het bachelorproject; de totale 15 ECTS (420 uur) worden hieraan besteed. Dit rapport geeft een beschrijving van onze bevindingen tijdens het ontwerpen, implementeren en testen van het systeem dat geproduceerd is tijdens dit project. Wij hebben ervoor gekozen om stage te lopen bij Reprovinci Internetdiensten B.V. in Schoonhoven. Onze opdrachtgever en begeleider binnen Reprovinci Internetdiensten is de heer Dirk-Jan van Roest. Wij danken hem en Geri Lekkerkerker, directeuren van Reprovinci Internetdiensten, hartelijk voor hun hulp en begeleiding tijdens het project en voor de realisatie van de stagemogelijkheid. Onze interne begeleider aan de TU Delft is de heer Hans Geers. Ook hem zijn wij veel dank verschuldigd voor zijn begeleiding; met name tijdens de oriëntatiefase van het project, waarin hij nuttige feedback gaf op de door ons geproduceerde (ontwerp)documenten. Als laatste willen wij de ST-coördinatoren van het bachelorproject, de heer Bernard Sodoyer en zijn vervanger, de heer C. Pronk, bedanken. Schoonhoven, 12 juli 2010, John Ciocoiu Elwin Dokter

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

Samenvatting R

eprovinci Internetdiensten B.V. beschikt op dit moment over vier webservers waarop ongeveer 70 websites worden gehost. Het maakt gebruik van een zelf ontworpen Content Management System (CMS)1 dat in principe aan elke website wordt gekoppeld. De ene website is de ander niet, en zo is het ook met het CMS waaraan het gekoppeld wordt. Bij een eenvoudige website kunnen bepaalde functies van het CMS uitgeschakeld of verwijderd worden, omdat deze simpelweg niet gebruikt worden. Er bevinden zich dus verschillende versies van het CMS achter de websites. Desalniettemin werd er voorheen nergens een versienummer geregistreerd. Ook krijgt het CMS zo nu en dan een update, waarbij er fouten uit worden gehaald of functionaliteit wordt toegevoegd. De bestanden van de website en de bestanden van het CMS waaraan zij gekoppeld is bevinden zich bij elkaar in een map op een server. Er zijn dus evenveel websites als instanties van het CMS. Een probleem doet zich nu voor wanneer een bepaalde release van het CMS een fout bevat. Deze fout moet dan bij iedere website, die aan dit CMS gekoppeld is, hersteld worden. Dit vermindert niet alleen de stabiliteit van de websites maar tast ook de betrouwbaarheid van het CMS en het vertrouwen van Reprovinci naar haar klanten aan.

1 2

Onze stageopdracht2 behelst het ontwikkelen van een product die de stabiliteit en betrouwbaarheid van het CMS vergroot. Hierdoor krijgt het bedrijf meer grip op de CMS versies die achter de websites zijn geïmplementeerd. Het product is door ons, in een periode van 10 weken, gerealiseerd in de vorm van een webapplicatie en centralisatie van het CMS. Centralisatie van het CMS betekent dat elke website een verwijzing krijgt naar een bepaalde release van het CMS op de server waar de website zich bevindt, in plaats van dat elke website over een eigen versie beschikt. Op deze manier kunnen fouten in een release op één centrale plaats hersteld worden. In het ontworpen systeem kunnen releases gemakkelijk worden toegevoegd en websites kunnen in een handomdraai naar een andere versie van het CMS worden gebracht. Verder geeft dit systeem goed inzicht in welke versies van het CMS aanwezig zijn en aan welke versie iedere website gekoppeld is.

zie ook Appendix D: Begrippen en Appendix H: RAD zie ook Appendix E: Opdrachtomschrijving Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

Inhoudsopgave 1 Inleiding SCHETS VAN HET BEDRIJF PROBLEEMSTELLING EN AANLEIDING OPDRACHT

9

B Grafische User Interface

31

9 9

C Log

35

2 Ontwerp

11

D Begrippen

37

3 Implementatie

13

E Opdrachtomschrijving

39

OPBOUW SYSTEEM Database Klassendiagram Testen UITBRENGEN EERSTE VERSIE

13 17 18 20 21

OPDRACHT CONTACTPERSOON

39 39

F ORIËNTATIEVERSLAG

41

G Plan van aanpak

57

4 Conclusies

23

AANBEVELINGEN

23

H RAD

63

5 Bibliografie

25

I ADD

89

6 Appendices

27

J TDD

97

29

K Implementatieplan

A Gebruiksaanwijzing Release zip archief indeling FRAMEWORK ZIP Archief INDELING WEBSITE TOEVOEGEN CENTRALE MAPPEN

Final report

|

John Ciocoiu

115

29 29 29 29

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

1 Inleiding T

rrrinng trrrring.. daar gaat de telefoon aan de Achterwetering 31 in Schoonhoven. Een klant heeft een vraag over zijn website, die zojuist gelanceerd is: “Wanneer ik een product op de voorpagina van de website neerzet, valt de website eruit!”. Na een kort gesprek met een van de medewerkers wordt de verbinding verbroken. Deze gebeurtenis herhaalt zich diezelfde week nog een aantal keren, met verschillende klanten, maar mét hetzelfde probleem. Nadat de medewerker heeft ontdekt wat deze fout veroorzaakt worden in een aantal uur alle websites, die dit probleem kennen, hersteld.

Reprovinci bestaat uit Reprovinci B.V. en Reprovinci Internetdiensten B.V. Reprovinci B.V. is in 2000 opgericht en houdt zich bezig met grafisch ontwerpen en printen. In het jaar 2005 is het internetbedrijf Revasa Design overgegaan in Reprovinci Internetdiensten B.V. en zo toegevoegd als nieuwe tak aan het bedrijf. Reprovinci is gevestigd in Schoonhoven, Zuid-Holland. De meeste klanten komen uit deze regio en behoren tot het MKB. Tegenwoordig voegen steeds meer non-profit organisaties zich toe als klant van Reprovinci, voor hun reclame materiaal en websites. Reprovinci Internetdiensten B.V. is een bedrijf dat zich bezig houdt met het ontwikkelen van websites. Daarnaast gebruikt het een Content Management Systeem (CMS) dat het zelf heeft ontwikkeld. Beide onderdelen zijn opgebouwd met behulp van een framework, het Zend Framework. In het CMS kan de gehele inhoud van de website in een grafische interface, via een browser, door de klant beheerd worden.

PROBLEEMSTELLING EN AANLEIDING OPDRACHT Het CMS wordt aan elke website gekoppeld en er wordt van tijd tot tijd een nieuwe versie van uitgebracht. Het vervangen van de bestanden en het bijwerken van de database achter een website tijdens het uitbrengen van een nieuwe CMS release gebeurt nu handmatig. Er wordt direct uit de ontwikkelomgeving een versie van het CMS geëxporteerd en aan de website gekoppeld. Deze versie kan fouten bevatten. In dat geval dienen de fouten gelijk opgelost te worden, of er moet een andere versie van het CMS gekoppeld worden aan de website. Dit verlaagt niet alleen de stabiliteit en betrouwbaarheid van het geheel, maar vooral de verhouding met de klant wordt aangetast wanneer het product niet naar verwachting functioneert.

1

Uit dit probleem is de opdracht ontstaan: het maken van een webapplicatie die het mogelijk maakt om alle websites en releases te beheren en het eenvoudiger maakt om de CMS versie achter een website sneller te veranderen. In dit systeem worden releases toegevoegd die vooraf grondig getest zijn, waardoor de betrouwbaarheid richting de klant toeneemt. Zo nu en dan wordt er in dit rapport gerefereerd naar de webapplicatie met ‘versiebeheersysteem’. In 2009 is er ook een stagiair productief geweest bij Reprovinci, die zijn scriptie daar geschreven heeft met als onderwerp ‘beheersbaar software ontwikkelen’ [Wouden, R. v., 2009]. Zijn advies was het centraliseren van de software zodat het updaten makkelijker zal verlopen. Dit advies hebben wij meegenomen bij het ontwerpen van ons versiebeheersysteem. Centralisatie speelt een grote rol; elke website beschikt niet meer over een eigen versie van het CMS, maar er zijn meerdere websites die gebruik gaan maken van hetzelfde CMS. De informatie die gebruikt is bij het ontwerpen van dit systeem is vooral de visie van de medewerkers binnen het bedrijf. Hun ideeën zijn omgezet in ontwerpen, die uitgewerkt zijn in een aantal documenten tijdens de oriëntatiefase1. Voor het Technische Design Document (TDD) is er gebruik gemaakt van informatie die verkregen is via het internet. Een aantal technieken die gebruikt worden in ons systeem, en voor ons nieuw waren, zijn ook tijdens de eerste fase getest op hun werking. De opbouw van de rest van dit rapport is als volgt. In hoofdstuk 2 komt het ontwerp van het versiebeheersysteem aan de orde, wat voor het grootste gedeelte tijdens de oriëntatiefase in de eerste drie weken is uiteengezet. Hoofdstuk 3 laat vervolgens zien hoe de implementatie in zijn werk is gegaan, welke problemen wij tegengekomen zijn en op welke manier er getest is. Hoofdstuk 4 bevat de conclusies en aanbevelingen.

VERSIE BEHEER SYSTEEM

SCHETS VAN HET BEDRIJF

Deze documenten bevinden zich in de appendices E, F, G, H, I, J en K van dit rapport Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

9

2 Ontwerp D

e eerste bijeenkomst bij het stagebedrijf bestond uit een brainstormsessie tussen de stagiaires en de stagebegeleider. Hierin werd de opdracht nog eens duidelijk besproken en afgebakend, waardoor wij over voldoende informatie beschikten om een Plan van Aanpak te schrijven. Verder creëerde deze sessie ook ideeën voor het ontwerp van het door ons te ontwerpen systeem. Duidelijk werd ook dat een aantal, voor ons nieuwe technieken, gebruikt zouden gaan worden, waarin wij voldoende uitdaging konden vinden om tijdens de oriëntatiefase uit te zoeken hoe deze technieken precies toegepast dienen te worden. Voorbeelden daarvan zijn de werking van SOAP [SOAP tutorial, 2008] en het Zend Framework [Zend Framework Manual, 2010]. De bevindingen hiervan zijn opgenomen in het oriëntatieverslag, dat als bijlage in Appendix F: Orientatieverslag is te vinden. De volgende stap was het construeren van het RAD document. Hoewel dit het grootste document is dat tijdens de oriëntatiefase is opgesteld, was het niet enorm gecompliceerd om het op te stellen. Dit omdat de wensen van het systeem goed waren gespecificeerd in de opdrachtomschrijving en we over een goed concept document beschikten voor een RAD.

Voor de basis van het versiebeheersysteem wordt er gebruik gemaakt van het Zend Framework. Globaal gezegd helpt het Zend Framework met het presenteren van de data op het scherm en het afhandelen van requests die opgegeven worden via dat scherm. Ook helpt het bij het initialiseren van een website en het connectie maken met de database. Het versiebeheersysteem is volgens het bekende ontwerp patroon (design pattern) Model, View, Controller (MVC) opgebouwd. Dit is niet alleen omdat het MVC principe een goed patroon is om de code schoon en leesbaar te houden, maar ook omdat het Zend Framework zo gemaakt is dat het MVC patroon makkelijk te gebruiken is. Verder wordt natuurlijk de gehele applicatie objectgeoriënteerd in elkaar gezet, dit omdat het MVC principe het mogelijk maakt. Het belangrijkste aspect van het versiebeheersysteem is het vergroten van het vertrouwen naar de klant toe. De releases die uitgegeven worden, zijn beter getest en zullen dus minder snel fouten bevatten. Daarbij moet het mogelijk gemaakt worden dat de applicatie een goed overzicht geeft van de releases die uitgegeven zijn en welke website van welke release gebruik maakt. Ook moet er in een handomdraai een nieuwe versie van een release en een daarbij behorend framework kunnen worden toegevoegd en moet een nieuwe website gebruik kunnen maken van deze release.


De documenten die volgden, het ADD, TDD en IP waren tijdrovender en zijn meerdere keren herschreven. Tijdens het TDD ontdekten we bijvoorbeeld dat het handig zou zijn wanneer de configurators1, die websites en releases ontvangen en verwerken, statussen terug kunnen sturen naar het versiebeheersysteem waardoor je een goed inzicht hebt over welke processen in behandeling, geslaagd of mislukt zijn. Dit had tot gevolg dat er status tabellen in de database toegevoegd moesten worden, die zich weer in het ADD bevinden.

Continue terugkoppeling naar voorgaande documenten en herschrijven van documenten vond plaats tijdens deze fase.

1 Zie ook hoofdstuk 3: Implementatie Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

11

3 Implementatie H

et implementeren van de meeste onderdelen verliep erg goed en soepel1. De vooraf gedefinieerde ontwerpen konden snel en effectief omgezet worden in programmacode. Al in een vroeg stadium werkte de Grafische User Interface (GUI) en de basis lees- en schrijfacties tussen de controllers en de database. Het eerste grote probleem kwamen we tegen tijdens het implementeren van statusmeldingen die terug werden gestuurd vanaf de configurators naar het versiebeheersysteem en de manier waarop deze in de database opgeslagen werden. Dit komt in de volgende paragraaf aan de orde, waarin de opbouw van het systeem wordt besproken. Het opzetten van een PHPUnit testomgeving kostte ook de nodige tijd en vereiste nogal wat aanpassingen in de serverconfiguratie. Dit wordt besproken aan het einde van dit hoofdstuk in de paragraaf ‘testen’.

Net zoals bij alle webapplicaties wordt als eerste de index pagina aangeroepen, dat is hier het index.php bestand. In dit bestand wordt als eerst de Zend Autoloader geïnitialiseerd2. De mappen waar de klassenbestanden, het ‘application path’, gevonden kunnen worden, zijn hier aangegeven zodat ze automatisch ingeladen kunnen worden. Daarnaast wordt de registry-variabele aangemaakt, dit is eigenlijk de plaats waar de globale variabelen, zoals de verwijzing naar het configuratiebestand en de database, in worden opgeslagen. De connectie met de database verloopt via de registry-variabele ‘db’, waarin de naam van de database met de gebruikersnaam en wachtwoord staan. Daarnaast wordt de view in de registryvariabele geladen zodat deze door de controllers aangepast kan worden en op het scherm kan worden weergegeven. Daarna wordt er door middel van de authentificatie bepaald welke gebruiker er gebruik maakt van het systeem. Wanneer er op een juiste manier ingelogd is, wordt er door een cookie bepaald welke gebruiker er ingelogd is. Als er geen cookie gevonden wordt is de gebruiker anoniem en krijgt deze geen toegang tot alle onderdelen van het systeem. Als laatste wordt in de index.php aangegeven welke controller van het versiebeheersysteem aangesproken moet worden bij de urls. Er zijn twee verschillende soorten versies van het versiebeheersysteem. Op één server, de masterserver, bevindt zich het gehele versiebeheersysteem. De overige webservers beschikken alleen over functionaliteit om de verwijzingen van websites naar centrale bestanden aan te maken en releases en frameworks te ontvangen in de vorm van zip-bestanden. Deze bestanden worden gecontroleerd op inhoud en vervolgens uitgepakt in de juiste mappen op de webserver. De webservers bevatten dus niet de views waarin de gebruiker de versies van de websites kan veranderen. De centrale database, waarin alle websites, releases etc. worden bijgehouden, bevindt zich ook alleen op de masterserver.

voegen aan het index.php bestand naar de map waarin de helper klassen zich bevinden. Een voorbeeldfunctie die zich in een helper klasse bevindt is de functie isZip(). Deze functie controleert of een inkomend bestand een geldig zip-archief is. Deze functie wordt zowel door de Release- als de FrameworkController gebruikt en bevindt zich om deze reden in een helper klasse.

Controllers De Website-, Release- en FrameworkController bevatten allemaal een functie die ervoor zorgt dat er een overzicht gemaakt kan worden in de view. De rest van de functies worden verderop in meer detail besproken. Dit gebeurt door middel van het ophalen van alle records van de betreffende soort uit de database, die dan in een collectie worden gezet. Deze collectie wordt doorgezonden naar de view en wordt daar op een overzichtelijke manier, met de gewenste informatie, op het scherm weergegeven.

IndexController De IndexController bevat een indexAction() functie die in het begin wordt aangeroepen en er onder andere voor zorgt dat de juiste view wordt geladen voor de index pagina. Statussen Zoals eerder vermeld, is het implementeren van de statussen niet in een keer succesvol verlopen. We geven hieronder in volgorde de ideeën weer die zijn langsgekomen. •

Om inzicht te geven in de opbouw van het systeem, wordt hieronder per onderdeel aangegeven hoe het opgebouwd is. Ten eerste worden de controllers uitgelicht, waarna de models en de views aan de beurt zijn. Let op dat per onderdeel de functies worden beschreven die daar uitgevoerd zijn. Zo is bijvoorbeeld het gehele verloop van het verwijderen van een website onderverdeeld onder de verschillende kopjes waarvan het verwijderen gebruik maakt. •

Helpers Tijdens het implementeren bleek op een gegeven moment dat fragmenten code in meerdere controllers zat. Dit is niet wenselijk, omdat wijzigingen dan herhaald moeten worden doorgevoerd op de verschille locaties. De oplossing voor dit probleem werd gevonden in de vorm van helpers. In helper klassen komen functies die door meerdere controllers aangeroepen kunnen worden. Dit kan door simpelweg een extra verwijzing aan het ‘application path’ toe te

1 2

Twee status kolommen toegevoegd bij de server tabel in de database voor zowel release als website. De status was een eenvoudige integer tussen de 0 en 7. Via SOAP kwamen berichten terug die deze status veranderde. Het probleem hierbij is dat SOAP de berichten asynchroon doorstuurt. Het kan dus zo zijn dat het bericht ‘verander website status naar 4’ voor het bericht ‘verander website status naar 3’ komt, terwijl je de acties in omgekeerde volgorde uitvoert. De status is in dit geval dus niet representatief met de werkelijke en daardoor niet bruikbaar. Elke server in de server tabel krijgt in plaats van een int een langere ‘bitstring’ waarbij elke actie zijn eigen positie op een bepaalde waarde instelt. Zo stelt de string ‘11212’ bijvoorbeeld voor dat er 3 acties bezig zijn (waarde 1) en 2 acties voltooid (waarde 2). Dit lijkt beter te werken, aangezien het hier niet uitmaakt in welke volgorde je de SOAP berichten ontvangt; op de juiste positie wordt de waarde veranderd en uiteindelijk krijg je een goed beeld van de status van de actie. Echter wordt tijdens het wijzigen van deze waarde de complete string in het begin uitgelezen. Op het moment dat er op één positie in de string een waarde wordt aanVERSIE BEHEER SYSTEEM

OPBOUW SYSTEEM

Meer overzicht van de bezigheden is te vinden in het log, onder Appendix C: Log Autoloader wordt behandeld in het Oriëntatieverslag, Appendix F: Orientatieverslag, hoofdstuk 1. Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

13

•

•

gepast en dit wordt opgeslagen in de database kan het zo zijn dat ondertussen al een ander bericht ervoor gezorgd heeft dat op een andere positie in de string ook al een waardeverandering heeft plaatsgevonden. Deze verandering wordt nu overschreven met een oude waarde, wat dit dus ook geen bruikbare oplossing maakt. Een aparte serverStatus tabel met losse velden per combinatie van server en status. De mogelijke waardes voor deze velden zijn 0 (idle), 1 (bezig), 2 (voltooid) en 3 (mislukt). Bij deze methode heb je niet te maken met de problemen die in de bovenstaande alternatieven zijn besproken. Het asynchroon doorsturen van de SOAP berichten is geen probleem, aangezien alle acties apart worden opgeslagen. Ook staan alle waardes nu in aparte velden, waardoor ook het moment van uitlezen en opslaan niet voor de problemen zorgt die je bij de ‘bitstring’ hebt. Na lange tijd het voorgaande gebruikt te hebben, bleek er toch weer een probleem te bestaan. Namelijk wanneer meerdere websites tegelijk naar een bepaalde release worden gebracht, worden er door elkaar via SOAP berichten terug gestuurd naar het versiebeheersysteem. Aangezien de statussen maar enkelvoudig per server worden bijgehouden is niet meer te achterhalen welke status door welke website is ingesteld. Van eventuele fouten die ontstaan is dus niet met zekerheid te zeggen op welke website zij betrekking hebben. De oplossing voor dit probleem is het opslaan van alle statussen in de tabel (voorheen was de tabel statisch in aantal records), met een koppeling naar het soort (release, framework of website) en het id erbij. Waardoor een status dus direct gekoppeld is aan een bepaald framework, release of website, in plaats van aan een server. Op de home-pagina worden de statussen van het laatste kwartier getoond en ook wanneer er nu meerdere websites tegelijk worden geüpdatet, wordt dit weergegeven.

Wanneer aan deze voorwaarden wordt voldaan wordt er een nieuw website object gecreëerd die gekoppeld wordt aan de door de gebruiker geselecteerde release. Deze release wordt dan ook gelocked (zie ReleaseController), als hij dat nog niet is, wat inhoudt dat deze niet verwijderd kan worden zolang deze of andere websites gebruik maken van de release. Vervolgens wordt bepaald, afhankelijk van de release versie die is geselecteerd, aan welke database- en cache updates deze website onderheven moet worden. Vervolgens wordt via SOAP naar de opgegeven server een bericht verstuurd die ervoor zorgt dat de website de juiste verwijzing naar het geselecteerde CMS release krijgt en eventuele database- en cacheupdates worden uitgevoerd. Bij het verwijderen van een website wordt de betreffende website uit de database verwijderd. Verder wordt er een functie aangeroepen die gaat controleren of de release waaraan de verwijderde website was gekoppeld nog door andere websites gebruikt wordt. Wanneer dit niet het geval is, kan de release ‘geünlocked’ worden, waardoor hij eventueel verwijderd kan worden. Tenslotte heeft de WebsiteController nog de functionaliteit om een website te locken. Dit gebeurt wanneer de gebruiker van het versiebeheersysteem instelt dat een website geblokkeerd moet worden voor bezoekers van buitenaf. Bezoekers van de site krijgen dan een melding dat de website tijdelijk niet bereikbaar is (HTTP 503 melding). Deze functie is bijvoorbeeld handig voor onderhoudswerkzaamheden.

ReleaseController De ReleaseController regelt de acties voor het toevoegen, wijzigen en verwijderen van een release. Tijdens het toevoegen van een release volgen er eerst een aantal checks:

WebsiteController

•

De WebsiteController regelt de acties voor het toevoegen, wijzigen en verwijderen van een website. Ook zorgt de controller voor het sorteren en het filteren van het overzicht op bepaalde kolommen. Deze functie wordt als eerste uitgelegd, waarna we verder gaan met de belangrijkste acties van deze controller. Wanneer er in de list van de websites (overzicht) op een pijltje bij een kolom wordt gedrukt, wordt het overzicht gesorteerd op deze kolom met de juiste volgorde, oplopend of aflopend1. Door middel van de link worden deze opties doorgestuurd naar de controller en opgeslagen in de User-tabel, zodat wanneer de gebruiker de volgende keer bij het overzicht komt, deze zelfde volgorde kan worden geladen. Ook kan er gefilterd worden op server en op release versie, dit gaat door de cursor over de desbetreffende kolomkop te gaan en de gewenste opties te selecteren. Ook deze filteropties worden opgeslagen in de database om dezelfde reden als dat de sortering wordt opgeslagen. In het overzichtscherm van de websites kunnen ook de websites geüpdatet worden. Dit gaat door het selecteren van de te updaten websites, selecteren van de CMSversie en het klikken op de ‘opslaan’-knop. De geselecteerde websites worden daarop, mits deze nog niet de geselecteerde versie hebben, van versie veranderd. Tijdens het toevoegen van een website volgen er eerst een aantal checks: •


•

De websitenaam die ingevuld is mag niet leeg zijn en moet uniek zijn (mag niet al bestaan) De websitenaam mag geen ongeldige tekens bevatten (alleen letters, cijfers, ‘.’ en ‘-’ zijn toegestaan)

14

• •

De release versie die ingevuld is mag niet leeg zijn en moet uniek zijn (mag niet al bestaan) De release versie die ingevuld is moet een geldig versienummer zijn (alleen cijfers en puntjes zijn toegestaan, bv. 1.0.1) De releasefile die geüpload wordt moet een zip archief zijn en een aantal verplichte mappen bevatten. Dit gebeurt via de isZip() functie uit de helper klasse en de checkZipFolderStructure() functie in de ReleaseController zelf. Ook bepaalt deze laatste functie of de release sqlen/of cachemodificaties bevat, zodat er in de database aangegeven kan worden of er sqlen/of cachemutaties uitgevoerd moeten worden wanneer er een website naar deze versie gaat.

Vervolgens wordt er een nieuw release object aangemaakt dat tevens in de database wordt opgeslagen. In het object wordt ook de informatie over de sqlen cachemodificatie opgeslagen. Vervolgens wordt er via SOAP een bericht verstuurd vanaf de masterserver naar alle servers met de link waar de zip van de release zich bevindt. De servers sturen via SOAP statusveranderingen terug naar het versiebeheersysteem, waarin aangegeven wordt hoe ver de servers zijn met hun acties, en of deze acties allemaal geslaagd zijn. Bij het verwijderen van een release wordt de betreffende release uit de database verwijderd. Verder wordt via SOAP een bericht naar de ReleaseConfigurator op elke server gestuurd die ervoor zorgt dat de bestanden verwijderd worden die bij deze release versie horen. Ook wordt er nog gecontroleerd of het framework waaraan deze release was gekoppeld nog door andere releases wordt gebruikt. Wanneer dit niet het geval is kan dit framework ‘geünlocked’ worden, waardoor deze eventueel verwijderd kan worden.

1 Zie voor duidelijkheid van deze pijltjes Appendix B: Grafische user interface, websiteoverzicht screenshot. 12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

FrameworkController De werking van de FrameworkController is, behalve het controleren van de zip en het wijzigen van een framework, vrijwel identiek aan de ReleaseController (zie de paragraaf hiervoor). De structuur van de zip is namelijk hierbij niet te bepalen aangezien de structuur van het Zend Framework niet door Reprovinci bepaald kan worden. Het wijzigen van een framework is niet nodig, derhalve is deze functie ook niet geïmplementeerd.

MaintenanceController Deze controller is heel wat anders dan de andere controllers in het systeem. Deze controller maakt het mogelijk om centrale berichten, storingen of nieuws, toe te voegen aan het systeem. Deze berichten worden dan in het hoofdscherm van elke versie van het CMS voor klanten weergegeven doormiddel van een Rss-feed. Zo kan het bijvoorbeeld zijn dat er een storing wordt aangekondigd via dit scherm. Zo weten de klanten dat het systeem er tijdelijk uit kan liggen. Naast het toevoegen van dit soort berichten kunnen deze ook verwijderd worden. Na elke toevoeging en verwijdering wordt er een functie in de MaintenanceCollection aangeroepen die de Rss-feeds bijwerkt, zodat deze altijd up-to-date blijven.

SoapController Zoals eerder al naar voren kwam wordt er gebruik gemaakt van SOAP voor het versturen van statusberichten vanaf de diverse configurators naar het versiebeheersysteem.1 In de SoapController worden de berichten die teruggestuurd worden van de servers afgehandeld. Verderop wordt, onder de kopjes WebsiteConfigurator en ReleaseConfigurator en onder het kopje Home bij de Views, verder uitgelegd welke statussen er teruggestuurd worden en welke fouten er op kunnen treden. Deze statussen worden niet alleen weergegeven op de home-pagina, maar deze worden ook in log-bestanden weggeschreven. In deze logbestanden bevindt zich informatie over de websites; welke versie van het CMS en framework zij draaien en of de acties tijdens het aanmaken/ updaten van de website voltooid zijn zonder fouten.

dates doorgevoerd. Tijdens deze updateprocessen worden er statusmeldingen naar de SoapController van het versiebeheersysteem gestuurd. Ook wordt de website tijdelijk uit de lucht gehaald voor externe bezoekers. ReleaseConfigurator De ReleaseConfigurator haalt het releasebestand (zip archief) op dat hij via een SOAP bericht doorgestuurd krijgt vanuit de ReleaseController. Vervolgens gaat hij deze controleren op verplichte mappen (deze controle is duaal, want deze gebeurd ook al in de ReleaseController). Wanneer de mappenstructuur correct is wordt de zip uitgepakt op de juiste locatie. De release is hiermee geïnstalleerd. Tijdens het updateproces worden er, net zoals bij de WebsiteConfigurator, statusmeldingen naar de SoapController van het versiebeheersysteem gestuurd. Tijdens het verwijderen van een release wordt er bepaald of de release sqlbestanden bevat. Als dit het geval is, worden deze sql-bestanden in eerste instantie niet verwijderd. Deze bestanden kunnen namelijk nodig zijn bij het veranderen van CMS-versie bij een website. Als de release nogmaals verwijderd wordt, worden ook de sql-bestanden verwijderd en de release volledig uit de database verwijderd. FrameworkConfigurator De FrameworkConfigurator haalt het frameworkbestand (zip archief) op dat hij via een SOAP bericht doorgestuurd krijgt vanuit de FrameworkController. Het framework wordt vervolgens uitgepakt op de centrale locatie en hiermee is het framework geïnstalleerd. Het framework kan nu geselecteerd worden bij het toevoegen en wijzigen van een release. Tijdens het verwijderen van een framework worden de bestanden van het framework verwijderd.

VIEWS Hieronder is te lezen hoe de GUI opgebouwd is. In Appendix G zijn de screenshots te vinden.

Home Het homescherm geeft de volgende info:

Masterserver Bij het uploaden van een release of framework stuurt de masterserver een SOAP bericht naar alle webservers met daarin de locatie waar het zip archief bestand zich bevindt. Bij het toevoegen en wijzigen van een website stuurt de masterserver de nodige informatie naar de webserver waar deze website zich op bevindt.

•

Up/Down (online/offline) status per server door middel van een groene of rode pijl, deze zijn te zien in figuur 1. Een legenda die uitleg geeft over het gekleurde bolletje bij de statusmeldingen, zie ook hiervoor figuur 1. Statussen per actie, per server: zie figuur 2. Deze statussen worden, met behulp van AJAX, automatisch ververst. Per server worden de acties van de afgelopen 15 minuten weergegeven. Daarbij wordt er per status aangegeven of deze goed is verlopen of niet. Overzicht van de belangrijkste functies van het versiebeheersysteem in vorm van een introverhaaltje.

• •

Alle servers Op alle servers staan de volgende Configurators. Deze zorgen voor het afhandelen van de aanvragen die via SOAP worden gedaan. WebsiteConfigurator De WebsiteConfigurator zorgt ervoor dat een website ook daadwerkelijk naar een andere versie van het CMS wordt gebracht. Hij krijgt vanuit de WebsiteController een bericht dat website x, naar versie y moet worden gebracht. Dit gebeurt door het ‘app.php’ bestand van de betreffende website te benaderen en van inhoud te veranderen. Eventueel worden er ook database en cacheup-

•

Legenda Niet bekend Bezig

Server is onbereikbaar

Voltooid

Server is bereikbaar

Mislukt

1


Figuur 1: Legenda statussoorten

De werking van SOAP wordt uitgelegd in het oriëntatieverslag, Appendix B: Oriëntatieverslag Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

15

Geen bezigheden

UPLOADEN RELEASE

UPLOADEN FRAMEWORK

TOEVOEGEN / UPDATEN WEBISTE

Geen recente bezigheden1

Uploaden van pc naar server

Uploaden van pc naar server

Onderhoudsbericht instellen

Connectie maken met hoofdserver

Connectie maken met hoofdserver

Database aanpassingen

Downloaden van hoofdserver

Downloaden van hoofdserver

Database query uitvoeren2

Controleren archief

Uitpakken archief

Verbinden met database2

Uitpakken archief

Config xml niet volledig2

Config xml bestaat niet2

Cache opschonen

Onderhoudsbericht weghalen Figuur 2: Beschikbare statussen per server

Websites

›› ›› ›› ››

Overzicht: •

•

•

Sorteren op kolom en filteren op bepaalde servers en CMS versies mogelijk. Deze opties worden onthouden door middel van de viewstate kolom in de User-tabel in de database. Per website: ›› Naam ›› CMS Release Versie ›› Zend Framework Versie ›› Server ›› Aanmaakdatum ›› De mogelijkheid tot: »» (de)activeren van website (zie WebsiteController) »» Downloaden log website »» Verwijderen website De mogelijkheid tot het aanpassen van de CMS versie van één of meerdere websites.

Release toevoegen / wijzigen: • • • •

Overzicht: •

Websitenaam CMS Release versie

Wanneer een website wordt toegevoegd aan het systeem, waarvan niet alle aanpassingen (verwijzingen, database etc.) uitgevoerd kunnen worden, verschijnen niet in het overzicht.

Na het drukken op de ‘opslaan’ knop bij het toevoegen van een release of een framework verschijnt er een uploadscherm die de voortgang van de upload weergeeft. Om dit te bewerkstelligen moet er een plugin op de server geïnstalleerd worden die ervoor zorgt dat de progressie van de download opgevraagd kan worden. Het geeft de gebruikers van het versiebeheersysteem goed inzicht tot de voortgang van de upload en biedt tevens de mogelijkheid de upload te annuleren, middels een ‘annuleren’ knop. Dit uploadscherm is een feature die ook gemakkelijk in het CMS ingebouwd kan worden.

Per framework: ›› Zend Framework Versie ›› Aanmaakdatum ›› De mogelijkheid tot: »» Verwijderen framework (alleen mogelijk wanneer framework niet gebruikt wordt)

Framework toevoegen: • •

Releases

CMS Release versie3 MS Release bestanden3 C Zend Framework Versie Notitie

Framework

Website toevoegen: • •

ache C Datum van toevoeging Notitie De mogelijkheid tot: »» Wijzigen release »» Verwijderen release (alleen mogelijk bij niet gebruikte release)

Zend Framework Versie Zend Framework Bestanden

Storingen en Nieuws Overzicht: •

Per storting of bericht: ›› Titel ›› Bericht ›› Type (Nieuws of storing) ›› De mogelijkheid tot verwijderen bericht

Overzicht: Bericht/storing toevoegen: P er release : ›› CMS Release Versie ›› Zend Framework Versie ›› SQL


•

16

1 2 3

• • •

T itel bericht Type bericht Inhoud bericht

Is geen echte status, maar wordt weergegeven wanneer er in 15 minuten geen acties zijn voorgekomen. Deze statussen kunnen alleen voorkomen wanneer het fout gaat bij het updaten van een website. Alleen mogelijk bij het toevoegen van een release.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

MODELS

Server

Models zijn niet interessant om afzonderlijk te beschrijven, aangezien ze allemaal hetzelfde zijn opgebouwd. Ze bevatten de benodigde get en set functies; een load functie; een constructor; een delete functie en een save functie. Elk Model heeft een bijbehorende ModelCollection. We beschrijven gegeneraliseerd hoe een Model en een ModelCollection werken. Sommige modellen hebben wat meer functionaliteit, dit zijn het Server model en de MaintenanceCollection. Van deze Modellen zullen we beschrijven wat er bijzonder aan is.

Het server model heeft naast de boven genoemde functies ook nog de functies: • •

Model Elke model heeft een aantal standaard variabelen en functies erin zitten. Hieronder zijn deze beschreven: • •

• • • •

Attributen ›› De elementen van een model Constructor ›› Maakt nieuw object tijdens het toevoegen ›› Laadt object tijdens wijzigen Get functies ›› Halen de attributen op Set functies ›› Stellen de attributen in op de waarde die wordt meegegeven als paramater Load functie ›› Laadt via de bijbehorende ModelCollection zijn inhoud Save functie ›› Registreert het object in de database

•

Ook wordt er in de server bijgehouden welk release-, website- of frameworkid als laatst is gewijzigd. Hierdoor weet het systeem op welk van deze onderdelen de statussen van toepassing zijn.

MaintenanceController Het MaintenanceCollection model heeft naast de boven genoemde functies ook nog de volgende functie: •

buildXml() ›› Deze functie maakt, van de gegevens uit de database, de XML bestanden aan die de Rss-feeds moeten voorstellen. Deze bestanden kunnen worden bereikt via een link en worden zo automatisch in het CMS-hoofdscherm ingeladen.

Database

ModelCollection •

isOnline() ›› retouneert true als de server bereikt kan worden (online is) addStatus(statusid, value, uploadid) ›› voegt in de database een status toe, waarbij statusid verwijst naar een bepaalde status en de waarde vier verschillende vormen aan kan nemen (zie ook figuur 1 en 2). Verder heeft iedere release of framework die toegevoegd wordt en iedere website die toegevoegd of gewijzigd wordt een uniek uploadid.

Add item ›› Voegt een item toe aan de verzameling Load (condities) ›› Laadt een (deel)collectie die voldoet aan bepaalde condities die als parameter worden meegegeven

In figuur 3 is te vinden hoe de database is opgebouwd.

Final report


Figuur 3: Database indeling

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

17


Klassendiagram

18

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report


Figuur 4: Volledig klassendiagram

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

19

Testen Bij Reprovinci is het begrip ‘softwaretesten’ niet erg bekend. De huidige software wordt handmatig getest, waardoor er nog wel eens bugs in de software kunnen sluipen. Op de lokale server binnen het bedrijf, waar de websites en software op geproduceerd en getest worden voordat het naar de klant gaat, waren geen testprogramma’s geïnstalleerd waardoor het voor ons lastig was om een testomgeving op te zetten. Uiteindelijk hebben we de server zo in weten te richten waardoor testen mogelijk werd gemaakt. De begeleider binnen Reprovinci vond het een goed idee om de server klaar te zetten voor het testen, zodat de software die door Reprovinci wordt geproduceerd straks ook gemakkelijk getest kan worden. Het wordt echter wel een grote klus om deze unittests achteraf nog in elkaar te zetten, want de software die door Reprovinci ontwikkeld is, bijvoorbeeld het CMS, is vrij complex.

de installatie van dit onderdeel bracht een aantal problemen met zich mee, het conflicteert namelijk met een PHP extensie van het Zend Framework, de Zend Extension Optimizer. Na het uitschakelen van deze extensie waren de problemen opgelost en werkt het testen inclusief het genereren van de codecoverage. Het inrichten van de server om deze geschikt maken voor het testen heeft in totaal een week gekost, maar de tijd en moeite betaalt zich wel terug in betrouwbaarheid. Zo zijn er een aantal fouten uit het programma gehaald door de Unittests, welke hieronder kort beschreven worden: • •

PhpUnit Tests Voor de werking van unittests wordt de extensie PHPUnit geïnstalleerd op de testserver. Omdat dit achteraf (na het implementeren van het versiebeheersysteem zelf) geïnstalleerd werd, was het lastig om de configuratie van PHPUnit zo te configureren dat het werkt volgens de indeling van het versiebeheersysteem. Ook omdat wij gebruik maken van het Zend Framework wordt het lastiger om de requests (aanvragen die de gebruiker doet in de browser) te testen. Het Zend Framework heeft zelf een kleine uitbreiding op PHPUnit wat het testen van deze requests mogelijk maakt. Het heeft enige tijd gekost voordat het bovenstaande alles uitgezocht was en voordat PHPUnit efficiënt gebruikt kon worden. Een ander probleem dat wij tegengekomen zijn is dat er in PHP geen output mag zijn voordat er headers verstuurd worden. Dat wil zeggen, er mag geen tekst geprint worden op het scherm voordat er bijvoorbeeld een sessie wordt gestart, cookies worden aangemaakt of een verwijzing naar een andere pagina wordt gedaan. Omdat PHPUnit steeds uitprint hoever hij is met testen, kregen wij te maken met dit probleem wanneer er een cookie werd aangemaakt voor het inloggen in het systeem. De oplossing die wij hiervoor gevonden hebben is ervoor zorgen dat er een zogenaamde ´output buffer´ gestart wordt, welke alle output onthoudt totdat alle code is uitgevoerd en dan pas de output op het scherm weergeeft. Een nadeel aan deze oplossing is dat er pas op het einde, nadat alle tests zijn uitgevoerd, wordt geprint en je dus tijdens de uitvoering geen voortgang ziet. Naast unittests en integrationtest, kan er naar de codecoverage gekeken worden. Om de codecoverage te kunnen inzien moet er nog een extensie op de PHP installatie toegevoegd worden. Dit is de Xdebug extensie, die ervoor zorgt dat er per PHP-bestand (van het versiebeheersysteem) een overzicht gegenereerd wordt van het aantal keren dat de code binnen deze bestanden gebruikt is. Ook

•

De isOnline() functie binnen de klasse Server retourneerde af en toe ‘true’, terwijl deze in werkelijkheid offline was. Fout in het inladen van de ReleaseCollection. Er was een functie die het mogelijk maakte om het eerste element uit de database terug te geven. Dit gaf echter niet het gewenste resultaat, waarna wij besloten deze functie te elimineren uit ons systeem. changeStatus veranderde wel de database naar de nieuwe versie, maar het object bleef gebruik maken van de oude versie, waardoor de functie niet werkte voor objecten die niet opnieuw ingeladen werden.1

Een functie van het versiebeheersysteem die we helaas niet hebben kunnen testen door middel van PHPUnit is het uploaden van bestanden. Als er een bestand wordt geüpload door de gebruiker wordt deze in het geheugen van de browser geladen. Deze actie kan niet gesimuleerd worden door PHPUnit in samenwerking met het Zend Framework. De tests worden uitgevoerd in de commandline (Linux) van de testserver. Het programma PHPUnit wordt uitgevoerd met een configuratiebestand waarin de verwijzingen en instellingen staan die bij het versiebeheersysteem horen. Hieronder is een voorbeeld van een aanroep te zien met configuratiebestand: ./phpunit --configuration /home/john/svn/manager/ test/phpunit_coverage.xml Met een zogenaamde ‘bootstrap’, waarnaar ook verwezen wordt in het configuratiebestand van PHPUnit, wordt de applicatie klaargezet waar de tests over uitgevoerd worden. De bootstrap lijkt heel erg op het index.php bestand van de website zelf. Het is ook mogelijk om aan te geven wanneer er wel codecoverage gegenereerd moet worden en wanneer niet, dit is handig omdat het genereren van deze coverage enige tijd in beslag neemt en je de coverage lang niet altijd in wilt zien. Daarom zijn er twee configuratiebestanden aangemaakt voor PHPUnit, één voor het uitvoeren met de coverage, en één voor het uitvoeren zonder de coverage. Ook is het mogelijk om aan te geven welke bestanden er niet opgenomen moeten worden in de coverage. Dit zijn de library-bestanden, bijvoorbeeld de bestanden van Zend Framework, want

PHPUnit 3.4.9 by Sebastian Bergmann. ............................................................ 60 / 162 ............................................................ 120 / 162 .......................................... Time: 01:26, Memory: 26.00Mb OK (162 tests, 738 assertions)


Generating code coverage report, this may take a moment.

20

1

Figuur 5: PHPUnit rapport

Deze functie is later vervangen door de addStatus functie

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

Figuur 6: Code coverage van PHPUnit gegenereerd door Xdebug deze worden niet altijd helemaal gebruikt (wat een lagere coverage geeft) en deze zijn al getest door het team van Zend zelf. Na het uitvoeren van PHPUnit geeft deze een klein rapport terug met daarin een aantal gegevens (tijd, geheugen, aantal tests), zie figuur 5. De puntjes in het figuur stellen de tests voor. Wanneer er een test fout gaat veranderd zo’n puntje in een F (Failure) of E (Error). De codecoverage wordt gegenereerd in HTML. In figuur 6 in een kleine impressie te zien van het gegenereerde overzicht. Zoals is te zien is er volledige coverage over de Models.

UITBRENGEN EERSTE VERSIE De eerste vier weken van de implementatiefase werd alles getest op een lokale server1. Nadat lokaal alle functies met de hoogste prioriteiten (in ieder geval alle must en should haves) geïmplementeerd en getest waren, werd het systeem op de eigenlijke webservers geplaatst. Hierbij moet gecontroleerd worden of de connecties (die voorheen tussen dezelfde testserver geschiedden) gemaakt kunnen worden tussen de verschillende servers. Ook moet gekeken worden of het versturen van bestanden en de plaatsing van de verwijzingen bij de websites nog goed gaat, nadat deze aangepast zijn naar de verwijzingen van de externe servers.

We verwachtten eigenlijk weinig problemen tijdens het opzetten van deze eerste externe server. Toch waren er nog een aantal problemen met de rechten op bepaalde bestanden en mappen die niet in een keer goed waren ingesteld en ook een paar verwijzingen in de code hadden we over het hoofd gezien. De problemen met de rechten kwamen vooral voor bij het wegschrijven van de app.php. We hebben besloten dat dit bestand altijd aangemaakt moet worden en de rechten daarbij goedgezet moeten worden. In een later stadium kunnen wij dit misschien automatisch laten doen, maar dit heeft niet de prioriteit, mede omdat dit niet in een handomdraai geïmplementeerd is. De volgende stap was het toevoegen van een tweede externe server, Mars. Voor het eerst kregen we nu te maken met elementen van SOAP waar we voorheen nog nooit mee te maken hadden gehad. Zo werd er tijdens het uploaden van een framework twee keer een SOAP verbinding van Deimos naar Deimos gemaakt, in plaats dat deze een keer naar zichzelf ging en een keer naar Mars. Dit had te maken met de cache van SOAP. De connectie en de details van een SOAP client worden namelijk opgeslagen. Door het opschonen en uitzetten van de cache, wat je via een extra paramater tijdens het opstellen van de SOAP client kan forceren, was dit probleem verholpen. Het was bij ons niet bekend dat de server SOAP instellingen in de cache opsloeg. Echter, bij het aanpassen van een website mag deze ‘clear cache’ echter niet uitgevoerd worden, omdat dan de parameters niet op de juiste manier doorgestuurd worden naar de SOAP server. Het oplossen van dit probleem nam de nodige tijd in beslag, omdat het even duurde voordat we erachter waren wat het probleem was. Vervolgens hebben we de SOAP berichten een aantal keren aangepast. Daarbij kwam er vaak een extra parameter bij die we meezonden en deze werd steeds niet ontvangen door de ontvanger. Dit bleek te komen door tijdelijke WSDL bestanden die de servers aanmaken voor SOAP-berichten. Deze dienen eerst verwijderd te worden alvorens de nieuwe indeling van de berichten (met meer parameters) goed verwerkt kunnen worden. VERSIE BEHEER SYSTEEM

De eerste stap die we uitvoerden was het plaatsen van de gehele applicatie op de primaire server, Deimos. Dit is naast de server van het versiebeheersysteem ook een webserver met verschillende websites. Deze server is, in tegenstelling tot de overige webservers, ongeveer hetzelfde ingedeeld als de lokale testserver. Naast de applicatie moeten ook nog de mappen aan worden gemaakt waarin de centrale bestanden, zoals de releases en de frameworks terecht komen. De rechten van deze mappen moeten zo ingesteld worden, zodat het versiebeheersysteem aanpassingen kan doen binnen deze mappen. Een testwebsite moet worden toegevoegd die gebruik zal gaan maken van de centrale bestanden. De website van de testwebsite moet ook aangemaakt worden en de instellingen hiervan moeten in het configuratiebestand van de

website komen, zodat er sql-updates op uitgevoerd kunnen worden. Verder moeten er subdomeinen aangemaakt worden die gaan verwijzen naar de betreffende servers. Zo is het versiebeheersysteem op de verschillde servers te bereiken via ‘servernaam‘.manager.reprovinci.nl.

1 Zie ook Appendix C: Log Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

21

4 Conclusies H

et belangrijkste doel van deze opdracht voor de opdrachtgever was om meer stabiliteit te kunnen bieden aan de klanten van websites. Dit is gerealiseerd door centralisatie van het Content Management Systeem (CMS). In het traject van 10 weken waarin wij de opdracht uitvoerden, volgden wij het waterval principe. Continu worden de documenten van voorgaande fases herschreven wanneer nieuwe inzichten worden verkregen tijdens het ontwerpen, maar ook tijdens het implementeren. We zijn begonnen met het goed vaststellen van de requirements in de vorm van een RAD. Daarna hebben we het systeem ontworpen middels een architectuurontwerp die onder andere de database indeling bevat en een technisch ontwerp met onder andere de klasse-indeling en de manier waarop we de diverse technieken zullen gaan implementeren (SOAP, VHOST, centraliseren van bestanden). In een periode van 7 weken hebben we vervolgens het gehele systeem opgezet, waarbij we zelfs wat uitbreidingslagen hebben gemaakt, die aanvankelijk op de MoSCoW als wensen stonden aangeschreven. Zeker de eerste stappen tijdens de implementatiefase voorliepen erg soepel. Enige problemen zijn we tegengekomen tijdens het opzetten van de testomgeving op de lokale testserver voor PHPUnit en het ontwerpen van de statusmeldingen. Bij dit laatste hadden we te maken met het niet synchroon doorsturen van berichten die via SOAP verstuurd worden. Dit zorgt er namelijk voor dat de berichten niet in de volgorde worden ontvangen waarin je ze verstuurt. Dit hadden wij tijdens de oriëntatiefase helaas onvoldoende onderzocht en we waren ons hier niet van bewust. Gelukkig hebben we een goede oplossing kunnen bedenken voor dit probleem.

AANBEVELINGEN Het systeem is een goed afgerond geheel, maar er is ook zeker genoeg ruimte om het systeem verder uit te breiden. Bij het opstellen van het MoSCoW document zijn al een aantal uitbreidingen naar voren gekomen. Zo kan er in de toekomst bijvoorbeeld een server bijkomen. Het toevoegen van een server wordt op dit moment niet (via de interface) ondersteund en zou handmatig via een extra databaserecord moeten gebeuren. Het systeem is zo opgebouwd dat het zich automatisch aanpast wanneer er een extra server is toegevoegd. De collectie van de servers wordt uitgebreid met één en verder werkt het uploaden van een release, het wijzigen van een website, etc. nog steeds met de bestaande code. Deze uitbreiding is dus prima te realiseren. Een ander voorbeeld van een uitbreiding op het systeem is het verplaatsen van een site naar een andere server. Tijdens het toevoegen van een website worden de mappen van de site zelf via ftp op locatie gebracht. Dit gebeurt dus nog handmatig en zou later ook door het systeem geregeld kunnen worden.


Uiteindelijk hebben wij een product neergezet wat voor de opdrachtgever een stabiele basis geeft voor het uitbrengen van nieuwe versies van het CMS. Het wijzigen van het CMS bij een website (of meerdere websites) neemt nu minder tijd in beslag en ook is er nu overzicht in aan welke versies de verschillende websites zijn gekoppeld. De betrouwbaarheid van het bedrijf richting de klant wordt hierdoor verbeterd.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

23

5 Bibliografie About Zend. (2010). (Zend) Retrieved Mei 7, 2010, from Zend Framework: http://framework.zend.com/about/overview SOAP. (2010). (Wikipedia) Retrieved Mei 7, 2010, from Wikipedia: http://nl.wikipedia.org/wiki/SOAP SOAP tutorial. (2008). Opgeroepen op 5 3, 2010, van w3schools: http://www.w3schools.com/soap/default.asp Wouden, R. v. (2009). Taming the beast. Schoonhoven.


Zend Framework Manual. (2010). Retrieved 5 6, 2010, from Zend Framework: http://zendframework.com/manual/en/introduction.overview.html

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

25


6 Appendices

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

27

A Gebruiksaanwijzing Release zip archief indeling

•

De releases die worden geupload moeten in ieder geval de volgende mappen/bestanden bevatten (aangegeven in juiste niveau vanaf de root van het zip-archief).

Alias /app /path/naar/centralemap/cmsreleases •

/root /application /controllers /models /views /html /admin /libraries /(sql) /(upgrade.sql) /(downgrade.sql) /(cache) /(cache.txt)

Deimos (zonder plesk) ›› In het centrale httpd.conf bestand bij de Virtual Host van de betreffende website de volgende zin toevoegen:

Overige servers (met plesk) ›› In deze omgeving zit het httpd configuratie bestand van elke website in de ‘conf’-map binnen de map van het domein. In die map moet het volgende gebeuren: »» Open httpd.include en voeg voor de laatste regel () de volgende zin toe:

Include /var/www/vhosts/domeinnaam/conf/vhost. conf »»

De sql en cache mappen zijn niet verplicht. Wanneer een sql en/of cache map aanwezig is/zijn, moeten deze respectievelijk de bestanden ‘upgrade.sql’ en ‘downgrade.sql’ of het bestand ‘cache.txt’ bevatten.

Maak het bestand vhost.conf aan in de map en de bovenste regel in dat bestand moet de volgende zin zijn:

Alias /app /path/naar/centralemap/cmsreleases Verder moeten alle instellingen gedaan worden die altijd al gedaan moesten worden, die dus niet direct van toepassing zijn op het versiebeheersysteem.

FRAMEWORK ZIP Archief INDELING

CENTRALE MAPPEN

De indeling van de framework zip moet gewoon hetzelfde zijn als de indeling van het Zend Framework. Er wordt niet gecontroleerd op bepaalde mappen, aangezien dit verschilt per versie. De verantwoordelijkheid van het uploaden van een correct framework in een zip bestand ligt dus bij de gebruiker.

De centrale mappen die zich op elke server bevinden hebben de volgende structuur:

WEBSITE TOEVOEGEN Bij het toevoegen van een website op een server moeten er van te voren een aantal handelingen worden verricht. Zo moet de website, exclusief het app. php bestand, geüpload worden en de app.php moet de rechten krijgen van de root. Dat kan door in de html map van de betreffende website de volgende commando’s uit te voeren:

/manager /cmsreleases /defaultdatabase /defaultdatabase.sql /frameworks /logs * /logs.zip * /temp * alleen nodig op de hoofdserver

• touch app.php (aanmaken bestand) • chmod 777 app.php (rechten aanpassen)

Deze mappen moeten ook allemaal de rechten hebben van de root, dit wordt met de volgende commando’s gerealiseerd:

Nu kan de website toegevoegd worden aan het versiebeheersysteem. Wel moet er in het virtualhost bestand van de server nog wat aangepast worden. De aanpassing verschilt per server, want deze is afhankelijk van de beheeromgeving (plesk gebruik).

• mkdir mapnaam (aanmaken map) • chmod 777 mapnaam (rechten aanpassen)


Ook de logs.zip file moet als ‘owner’ de root hebben, en de ‘chmod’ moet op 777 staan.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

29

B Grafische User Interface

Figuur 7: Inlogscherm

Figuur 8: Homescherm wanneer er geen recente bezigheden zijn uitgevoerd


Figuur 9: Homescherm wanneer er acties zijn uitgevoerd

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

31

Figuur 10: Overzicht met alle websites in het systeem

Figuur 11: Het toevoegen van een website

Figuur 12: Overzicht van alle releases in het systeem


Figuur 13: Scherm voor het toevoegen van een release

32

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

Figuur 14: Het bewerken van een release

Figuur 15: Overzicht van alle frameworks in het systeem


Figuur 16: Scherm voor het toevoegen van een framework

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

33

Figuur 17: Uploadscherm dat te voorschijn komt bij het uploaden van een release of framework (snelheid is hoog omdat deze screenshot lokaal is gemaakt)

Figuur 18: Overzicht van alle storings- en nieuwsberichten die in het systeem staan


Figuur 19: Het toevoegen van een storing- of nieuwsbericht

34

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

C Log Periode Week 1

Taken

Periode

Gesprek met dhr. van Roest en een brainstorm sessie over de gehele opdracht. Bespreken van de eisen.

Taken Implementeren status: servers geven hun status terug aan het versiebeheersysteem.

Week 6

Plan van Aanpak gemaakt.

Framework los van release.

Begin gemaakt aan de volgende documenten: • RAD • ADD

Gedeelde functies naar helpers classen verhuizen. Onderhoudsberichten RSS in het CMS inbouwen, te beheren in versiebeheersysteem.

Voorgangsgesprek met dhr. Geers in Delft. Week 2

Unit testen: lang bezig geweest met configuratie server voor unit testing. Begin gemaakt met het implementeren van tests.

De volgende documenten afgemaakt: • RAD (met feedback na afspraak) • ADD

Bezoek dhr. Geers aan Reprovinci. Voorgangsgesprek met dhr. Geers in Delft. Unit testen: bezig geweest met de installatie van code coverage. Daarnaast zijn alle tests geïmplementeerd.

Week 7 Week 3

De volgende documenten zijn afgerond: • TDD • OV

Schrijven eindverslag, implementeren log functie.

Voorgangsgesprek met dhr. Geers in Delft. Week 4

Klaarzetten van het versiebeheersysteem om het begin volgende week extern, over internet, te testen (voorheen verliep de ontwikkeling alleen via een lokale testserver).

Begonnen aan implementatie • User Interface • Controllers • Models • Inloggen werkend gemaakt • Release beheer in database • Website beheer in database

Gesprek met dhr. van Roest over de planning van de laatste weken. De applicatie op de externe servers neerzetten. Kijken naar SOAP tussen externe servers.

Week 8

Werken eindverslag

Aanroepen van versiebeheer naar configurators.

Statussen specifieker maken voor wanneer het fout gaat.

Documenten aangepast op feedback.

Met uploadprogress bar begonnen, werkt nog niet.

Websites en CMS scheiden zodat het CMS centraal neergezet kan worden, verwijzingen aanmaken die beheerd worden door het beheersysteem (app.php).

Week 9

Uplaodprogress bar werkend gemaakt.

Eindverslag van Word overgezet in inDesign. Eindverslag verder gemaakt.

Releaseconfigurator en websiteconfigurator. Statussen uitbreiding gemaakt. Zip uploaden / downloaden en controle van structuur. Afronding verslag.

Week 10 Soap terug voor het ontvangen en verwerken van statusveranderingen van de configurators. Views uitbreiden met Ajax refresh van home.

Versiebeheersysteem op servers neergezet Week 11

Presentatie

Voorgangsgesprek met dhr. Geers in Delft. VERSIE BEHEER SYSTEEM

Week 5

SOAP controllers voor het beheren van websites en releases op de servers.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

35

D Begrippen Begrip

Omschrijving

Begrip

Omschrijving

ADD

Architectural Design Document

TDD

Technical Design Document

AJAX

AJAX (Asynchronous Javascript And XML) is een term voor het ontwerp van interactieve webpagina’s waarin asynchroon gevraagde gegevens worden opgehaald van de webserver. Daardoor hoeven dergelijke pagina’s niet in hun geheel ververst te worden.

SOAP

Cookie

Cookies, zijn kleine beetjes informatie die een server naar de browser stuurt met de bedoeling dat deze informatie bij een volgend bezoek weer naar de server teruggestuurd wordt.

SOAP (aanvankelijk een afkorting voor Simple Object Access Protocol) is een computerprotocol dat wordt gebruikt voor communicatie tussen verschillende componenten. SOAP is een protocol dat Extensible Markup Language (XML)-berichten stuurt, meestal over HTTP, maar ook over SMTP, HTTPS of FTP. [SOAP, 2010]

URL

Een Uniform Resource Locator is een label dat verwijst naar een informatiebron, bijvoorbeeld een webpagina of een ander bestand.

CMS

Content Management Systeem of een content-beheersysteem is een softwaretoepassing, meestal een web-applicatie, die het mogelijk maakt dat mensen eenvoudig, zonder veel technische kennis, documenten en gegevens op internet kunnen publiceren (contentmanagement). Een bepaalde uitgebrachte versie van het CMS.

CMS-versie

Zie CMS-release

GUI

Grafische User Interface

HTTP 503

Dienst niet beschikbaar

IP

Implementatieplan

MKB

Midden- klein bedrijf

MVC

Model View Vontroller is een ontwerppatroon (“design pattern”) dat het ontwerp van complexe toepassingen opdeelt in drie eenheden met verschillende verantwoordelijkheden: datamodel (model), datapresentatie (view) en applicatielogica (controller).

PHP

PHP staat voor PHP: Hypertext Preprocessor. Programmeer taal dat de mogelijkheid geeft voor objectgeoriënteerd programmeren.

RAD

Requirement Analysis Document

RSS-feed

Really Simple Syndication (eenvoudige gelijktijdige publicatie), is een familie van webfeedformaten. RSS wordt vooral gebruikt bij weblogs, fora of nieuwssites om telkens op de hoogte te kunnen zijn van het laatste artikel/nieuws.

Zend Framework

Het Zend Framework is een open-source framework, ontwikkeld in objectgeoriënteerde PHP5 code door Zend Technologies. [About Zend, 2010]


CMS-release

VHOST (virtual host) Een virtuele host is een verwijzing voor een domein naar een plaats op de harde schijf van de server.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

37

E Opdrachtomschrijving R

eprovinci Internetdiensten B.V. is een bedrijf dat zich bezig houdt met het maken van websites. Daarnaast heeft het een eigen Content Management Systeem (CMS). In dit softwarepakket kan de gehele website in een grafische interface door de klant beheert worden. In dit CMS is het mogelijk om elke tekst, knop en product op de website moeiteloos de wijzigen. Het CMS wordt achter elke website geïmplementeerd. Natuurlijk komt er zo nu een dan een update uit van het CMS. Om deze update uit te voeren moeten bij elke klant handmatig de oude bestanden vervangen worden door de nieuwe. Het vervangen van deze bestanden kost heel veel tijd, zeker nu er steeds meer klanten bij komen. Wanneer er bij een update meer functies beschikbaar worden moet ook de database bijgewerkt worden. Dit proces kost ook veel tijd omdat er handmatig een database synchronisatie uitgevoerd moet worden.

OPDRACHT De opdracht houdt in dat er software geschreven moet worden dat het updaten gemakkelijker maakt. Er zijn op dit moment 4 centrale servers waarop de websites met het CMS draaien. Op elke server moeten alle versies van het CMS en de daarbij behorende versies van het Zend Framework komen te staan. Door een simpele druk op de knop moet bij de geselecteerde klanten het CMS automatisch geüpdate worden naar de versie die aangeklikt wordt. Ook moet het downgraden van de software een optie zijn in de nieuwe software. Dit deel van de software is voornamelijk een ‘cliënt-programma’ waarin elke website in een lijst te zien is met het huidige versienummer van het CMSpakket en het Framework.

Eén van deze 4 servers gaat de ‘beheer server’ worden. Elke andere server staat dus in contact met deze beheer server zo worden deze automatisch geüpdate met nieuwe software en/of nieuws berichten: in het CMS zit een centraal scherm waar de onderhouds- en nieuwsmeldingen voor de klant op weergegeven worden. Deze nieuwtjes moeten dus vanaf de beheer server afgehaald worden.

De communicatie tussen de servers en de verschillende componenten moet worden gedaan via het SOAP principe. Dit geheel moet web based geïmplementeerd worden. Het CMS is in PHP geprogrammeerd dus het is het beste voor het bedrijf dat die taal gebruikt wordt. De kennis ligt van het bedrijf ligt daarom ook vooral in de PHP taal. Als er na deze opdracht nog elementen onderhouden of bijgevoegd moeten worden, is het voor het bedrijf bijna onmogelijk om dat in een andere taal te doen.

Ook kan het zijn dat er een versie van het CMS op een andere server gezet gaat worden dan deze vier. Daarbij moet het CMS met de bijbehorende versie van het Zend Framework per website geïnstalleerd worden. Dit moet ook mogelijk worden via het nieuwe programma.

Er moet gewerkt gaan worden met aliassen in de Virtual Host. Dit moet gebruikt worden voor de verwijzingen naar bepaalde mappen op de server waarin het CMS geïnstalleerd staat.

Fases van ontwikkeling: • • • •

Onderzoek naar SOAP, Linux en PHP. Ook naar het live updaten van websites. Ontwerpfase Implementeren Testen

Een aantal eisen op een rij: • • • • • •

Web based cliënt applicatie die overal vandaan gedraaid kan worden voor het updaten van websites Alles volgens het Model View Controller principe Servers zo inrichten dat het updaten mogelijk is, centrale server met alle versies die in gebruik zijn Lijst met alle klanten met daarbij het huidige CMS-versienummer Versiebeheer van CMS en van het Framework per website Connectie tussen verschillende componenten via SOAP

CONTACTPERSOON


Ing D.J. (Dirk-Jan) van Roest Telefoon: 0182-384233 E-mail: [email protected] Internet: www.reprovinci.nl

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

39

F ORIËNTATIEVERSLAG VOORWOORD In het zesde semester van de Bsc-opleiding Technische Informatica aan de TU Delft dient een Bachelorproject uitgevoerd te worden. Dit project bestaat uit een stage bij een bedrijf of instelling. Wij hebben ervoor gekozen om bij het bedrijf ReproVinci Internetdiensten B.V. te Schoonhoven deze stage uit te voeren. Het Bachelorproject is opgedeeld in de volgende fases: -

Oriëntatiefase Ontwerpfase Implementatiefase Afrondingsfase


In de oriëntatiefase verdiept men zich in het probleem en de methoden om het probleem op te lossen. De technieken die voor het te maken systeem gebruikt worden, worden onderzocht. Ook worden de requirements in overleg met de opdrachtgever verzameld en deze worden opgenomen in het ‘Requirements Analysis Document (RAD)’. In de ontwerpfase worden er diverse ontwerpdocumenten gemaakt, waarin de onderwerpen die beschreven worden steeds meer in (technisch) detail treden. In de implementatiefase wordt de oplossingsmethode geïmplementeerd en getest. Tenslotte staat in de afrondingsfase het goedkeuren van het stageverslag en het houden van een voordracht centraal.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

41

INTRODUCTIE De opdracht die centraal staat tijdens dit project is het maken van een versiebeheersysteem in de vorm van een webapplicatie. ReproVinci heeft zo’n 70 websites online staan, verspreid over vier webservers. Elke website is gekoppeld aan een CMS. De website en het CMS draaien op het Zend Framework. Dit Framework is een bibliotheek voor de belangrijkste acties van een website. Omdat er aan elke website een eigen CMS gekoppeld zit, is er weinig of zelfs geen centralisatie. Ook is er op dit moment geen inzicht in welke website aan welke versie van het CMS is gekoppeld. Wanneer er een nieuwe versie van het CMS uitkomt moet deze aan verschillende websites gekoppeld worden, wat op dit moment veel tijd kost. Door het te maken versiebeheersysteem moet er inzicht gecreëerd worden in de versies van het CMS en het Framework die gekoppeld zijn aan de websites en het veranderen van deze versies moet sneller gaan. Om een klein overzicht te krijgen van de functionaliteiten van het systeem, noemen we hieronder de belangrijkste onderdelen. Voor meer detail over deze functionaliteiten verwijzen wij naar het RAD (Requirements Analysis Document). We gaan hier in op drie functies: uploaden van een nieuwe versie van het CMS, toevoegen website en wijzigen CMS-versie van website. Uploaden nieuwe versie CMS: 1.

2. 3. 4.

De beheerder voegt een release toe door middel van het uploaden van een ziparchief die de release bestanden bevat (en eventueel een ander archiefbestand die een nieuw framework bevat). Dit archief wordt op de server van het versiebeheersysteem klaargezet en de locatie van dit bestand wordt doorgegeven aan de overige webservers. De overige webservers downloaden dit zip-bestand en pakken deze uit op de locatie die meegegeven wordt. De release bevindt zich nu op alle servers en kan gekoppeld worden aan de websites.

Website toevoegen: 1. 2.

3.

Website moet geupload worden naar één van de vier webservers. Dit gaat gewoon via een FTPclient. De database moet aangemaakt worden. De website moet toegevoegd worden aan het versiebeheersysteem. Dit kan door in het systeem op het knopje ‘toevoegen website’ te klikken in het websitescherm. Hier moet de naam ingevuld worden van de website, die moet overeenkomen met de naam van de map waarin de website staat. Daarnaast kan geselecteerd worden welke versie van het CMS er gebruikt moet gaan worden voor die website. De gebruiker drukt op opslaan en dan gaat het systeem aan de slag om alles goed te zetten (zie verder dit verslag).

CMS-versie wijzigen bij website: 1. 2.


3.

De gebruiker geeft aan naar welke versie van het CMS de website wordt gebracht. Het systeem gaat nu de verwijzingen aanpassen naar deze nieuwe versie. De database wordt, zo nodig, hierbij ook aangepast, zodat hij om kan gaan met de nieuwe versie. De website maakt gebruik van de nieuwe versie en daar is geen of nauwelijks dataoverdracht bij nodig geweest!

42

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

INLEIDING Het versiebeheersysteem maakt ook gebruik van het Zend Framework en bevindt zich op één centrale server, één van de vier webservers. De bestanden van de verschillende CMS-releases worden op een centrale locatie op elke server neergezet. Voor elke website die wordt toegevoegd aan het systeem moet het bestand app.php aangemaakt worden waarin de verwijzingen staan naar zo’n centrale versie van het CMS. Op elke webservers komt een Configurator die de verbinding aan gaat met het versiebeheersysteem zodat er bestandsoverdracht kan plaatsvinden. De communicatie tussen het versiebeheersysteem en de Configurator verloopt via SOAP. Deze webservers moeten een zip-archief die de bestanden van een CMS-release bevat kunnen downloaden en uitpakken. Bij een nieuwe CMS-release kan het voorkomen dat de database is veranderd. Deze databasemutaties moeten worden doorgevoerd wanneer een website naar deze nieuwe versie wordt gebracht. In de volgende hoofdstukken worden de vetgedrukte elementen van het bovenstaande verhaal behandeld in onderstaande volgorde: Zend Framework SOAP Verwijzingen Zip-archief downloaden en uitpakken Databasemutaties


-

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

43

1. ZEND FRAMEWORK Het Zend Framework is een open source framework voor webapplicaties en services met PHP. Zend is een bedrijf dat zich met PHP bezighoudt en het Framework is door hen ontwikkeld (1). Het framework is geheel object-georiënteerd en zorgt er voor dat de webapplicatie, die met behulp van het Zend Framework gemaakt wordt, ook op een objectgeoriënteerde manier in elkaar wordt gezet (2). Het framework zorgt standaard voor een Model-View-Controller omgeving. Zend Framework is gericht op het bouwen van veilige, betrouwbare en moderne Web 2.0-applicaties en web services. Elk component is losjes gekoppeld aan andere componenten, wat ontwikkelaars in staat stelt om gebruik te maken van de afzonderlijke componenten. Daarentegen vormen de Zend Framework componenten binnen de standaard bibliotheek een krachtig geheel wanneer deze gecombineerd worden gebruikt. Om een idee te geven van een aantal functies binnen het Zend Framework, laten we twee voorbeelden zien. Er is voor deze voorbeelden gekozen omdat er in het versiebeheersysteem ook gebruik wordt gemaakt van deze functionaliteiten uit het Zend Framework. De volgende voorbeelden worden beschreven: automatisch inladen van php-klasse bestanden en het koppelen van de goede controller en functie daarin aan de url die ingegeven is. In PHP moet er naar elk bestand verwezen worden voordat het gebruikt kan worden. Omdat een webapplicatie uit meerdere, bij ReproVinci over de 700, klassenbestanden bestaat, wordt het een hele lange lijst met zogenaamde ‘includes’. In het Zend Framework is daar een oplossing voor gemaakt: de Autoloader. Deze Autoloader laadt zelf de bestanden in die nodig zijn. Bij het laden van de webapplicatie worden de locaties aangegeven waar de klassenbestanden te vinden zijn. Wanneer er een nieuwe instantie wordt gemaakt van een klasse, wordt automatisch het klassenbestand, met dezelfde naam als de klasse zelf, erbij geopend. Het volgende voorbeeld dat behandeld wordt, is de manier waarop het Zend Framework omgaat met de ingevoerde url’s. Wanneer er achter de domeinnaam geen variabelen meegegeven worden, wordt de IndexController aangesproken met daarin de indexAction methode. Als er in de url achter de domeinnaam bijvoorbeeld ‘/admin’ wordt ingetypt, gaat Zend op zoek naar de indexAction methode binnen de AdminController. Door de url langer te maken, bijvoorbeeld met ‘/admin/content’, kunnen meerdere methodes binnen de aangegeven controller aangeroepen worden. Een voordeel van het gebruik maken van het Zend Framework is dat het een stuk makkelijker en professioneler wordt om een webapplicatie op te zetten. Makkelijker omdat er gebruik wordt gemaakt van standaard componenten en professioneler omdat de code er netter door wordt en er worden standaard programmeer modellen gebruikt (zoals MVC). Je beschikt met Zend over een goed fundament, dat al grondig getest is. Dit neemt een aantal verantwoordelijkheden weg bij de programmeurs en het scheelt in implementatietijd. (3)


We zijn nog geen nadelen tegengekomen die betrekking hebben op het Zend Framework.

44

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

Het versiebeheersysteem zal, zoals hierboven al is verteld, ook gebruik gaan maken van het Zend Framework. Van de standaardbibliotheek gebruiken we het MVC raamwerk als basis voor onze applicatie. Wat ook mee woog in de keuze voor Zend, is dat het bestaande CMS hier ook op draait en de kennis dus aanwezig is binnen het bedrijf. Van de twee hierboven genoemde voorbeelden wordt ook gebruik gemaakt binnen het versiebeheersysteem. Zo zijn er nog meer functies die gebruikt worden door ons systeem, een paar belangrijke functies volgen: • •

De component Zend_Auth wordt gebruikt voor gebruikersauthentificatie. Van dit component zullen wij gebruik maken voor gebruikersauthentificatie. De component Zend_Soap wordt gebruikt voor het opzetten van de soap-server en soap-client.


Het component Zend_Db wordt gebruikt voor het opzetten van de connectie naar de database, ook zijn er subcomponenten die ervoor zorgen dat er gegevens uit de database ingeladen kunnen worden en mutaties aangebracht kunnen worden in de database. Door één syntax te gebruiken is het mogelijk om van verschillende typen databases gebruik te maken.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

45

2. SOAP SOAP (Simple Object Access Protocol) is een ‘open standaard’ protocol dat gebruikt wordt voor communicatie tussen verschillende soorten componenten. Deze componenten kunnen zijn geschreven in verschillende programmeertalen. SOAP is een standaard die ondersteund wordt door verschillende grote software bedrijven, waaronder IBM, Microsoft en Apache Software Foundation. De berichten die SOAP gebruikt zijn opgebouwd in eXtensible Markup Language (XML) die meestal worden verzonden over het HTTP, maar het kan ook over SMTP, HTTPS en FTP. (4) Naast SOAP is er nog een service die ongeveer dezelfde resultaten biedt, namelijk XINS (XML Interface for Network Services). XINS is een relatief nieuwe aanpak voor webservices. Net zoals bij SOAP zijn alle specificaties XML-gebaseerd. Vanuit de specificaties kan XINS code worden gegenereerd voor server en client en HTML-gebaseerde testformulieren en documentatie. De keuze tussen deze twee services is gevallen op SOAP. Dit omdat SOAP een standaard component is in het Zend Framework en er veel informatie over is te vinden op internet. Ook zijn er al SOAP functies geïmplementeerd in PHP, waarvan op een gemakkelijke manier gebruik van gemaakt kan worden. De rest van dit hoofdstuk gaat over de werking van SOAP en de toepassing ervan in het versiebeheersysteem. Een SOAP-bericht is grofweg onder te verdelen in drie onderdelen: de envelop, header en body. Als we het gaan vergelijken met een brief die je op de post doet, is het eigenlijk gewoon de envelop (SOAP envelop) met daarop een adres (SOAP header) en de brief erin (SOAP body). In de header bevinden zich encodeerregels voor de datatypen die gebruikt worden. De body bestaat uit een representatie van 'remote procedure calls' (uitvoeren van code op een ander platform) en antwoorden, wat het mogelijk maakt om met componenten die gebruik maken van verschillende programmeertalen te communiceren, de eigenlijke kracht is van SOAP. (5) Voorbeeld SOAP code: <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>Example


Om de communicatie tussen webservices te beschrijven, wat nodig is voor het versiebeheersysteem, wordt er gebruik gemaakt van WSDL. WSDL is een soort XML. De input en de output van de methodes die gebruikt worden via SOAP, zijn gedefinieerd in een WSDL document. Dit document wordt opgebouwd door het Zend Framework.

46

SOAP is ervoor gemaakt om via het HTTP protocol te werken. Het voordeel hiervan is dat je niet met proxy en firewall problemen te maken krijgt die de connectie kunnen blokkeren. SOAP werkt met aanvragen (request) en antwoorden (responses) (6). De kant die de request uitvoert is de client, de server stuurt vervolgens een response.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

In het versiebeheersysteem is communicatie nodig is tussen verschillende webservers om bepaalde functies op afstand uit te voeren. Via SOAP is dit te realiseren. Nu bekend is wat SOAP is en hoe het werkt, kunnen we het toe gaan passen op het versiebeheersysteem. Er moet gedefinieerd worden wat de server en wat de client moet gaan worden. Omdat er requests van beide kanten uitgevoerd gaan worden, zijn de webserver met het versiebeheersysteem en de overige webservers beide afwisselend SOAP-client of SOAP-server. Bij twee verschillende componenten van het systeem wordt SOAP gebruikt. Een voor bij het aanmaken en wijzigen van een CMS-versie van een website en één voor het neerzetten van een nieuwe CMS-versie op servers. Hieronder volgen twee tabellen met de requests en responses die nodig zijn bij de acties: Aanmaken / updaten van een website versiebeheersysteem (1) SOAP request “update website x naar versie y op server z” 

webserver Verwijzingen aanmaken, database updaten, cache opruimen (2)

(4) Aangeven aan de gebruiker wat de status is van de server bij het updaten van de website

 SOAP request “status a website x” (3)

Het versiebeheersysteem stuurt een request naar de server met een website om deze van CMS-versie te veranderen. Met die aanroep worden een aantal parameters meegestuurd die wel bekend zijn bij het versiebeheersysteem maar niet bekend zijn op de server: -

Websitepath: plaats waar de websites te vinden zijn op de server. Websitenaam: naam van de website, één map dieper dan de websitepath. Releasepath: pad waar de release te vinden is, samen met versienummer. Frameworkpath: zelfde als releasepath, maar dan voor het framework. Database versions: de CMS-versies die gebruikt moeten worden om de databasestructuur aan te passen.

De webserver voert een aantal functies uit, nodig om de website te updaten. Telkens wordt de status van de server teruggestuurd naar de webapplicatie, deze kan dan weer aangeven of de update gelukt is. Als de server klaar is kan de website in het versiebeheersysteem weer vrijgegeven worden voor bewerking. Uploaden van een release versiebeheersysteem (1) SOAP request “location zip” 

webserver Downloaden/uitpakken zip (2)

 SOAP request “status x server y” (3)

(4) Status servers weergeven

Het versiebeheersysteem stuurt een request naar elke server om aan te geven dat er een versie klaarstaat. Ook hier worden verschillende parameters meegegeven met gegevens die onbekend zijn op de server: Link naar releasezip locatie: de link naar de locatie van de zip. Releases path: plaats waar de releases op de server te vinden zijn. Releasepath: naam van de map waarin de release neergezet moet worden, een niveau dieper dan de vorige parameter. VERSIE BEHEER SYSTEEM

-

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

47

Wanneer er een nieuw framework wordt geüpload, worden dezelfde parameters meegegeven, maar dan in plaats van de releasedetails de frameworkdetails. Als de upload opgehaald is door de webserver en uitgepakt, en indien het de juiste mappen bevat (de upload is een zip-archief, zie een aantal kopjes hieronder), stuurt de webserver naar het versiebeheersysteem dat de upload geslaagd is. Tijdens het uploaden van een release geeft de View van de webapplicatie de status van de upload, het controleren en uitpakken van de diverse servers aan. Het versiebeheersysteem kan eventueel het zip-bestand verwijderen op het moment dat alle servers deze opgehaald en uitgepakt hebben. VAN WEBAPPLICATIE NAAR WEBSERVER

Vanuit de webapplicatie naar de webserver zijn er twee momenten waarbij we SOAP gebruiken. De methodes die de opdrachten uitvoeren op de webserver zijn geïmplementeerd in twee configurators die via SOAP aangesproken worden. Hieronder zijn deze twee Configurators gegeven met daarbij hun functies: -

WebsiteConfigurator: o Make Appfile o Database Update o Cache Update

-

ReleaseConfigurator: o Zip ophalen o Zip uitpakken

De WebsiteConfigurator wordt gebruikt tijdens het toevoegen of wijzigen van een website in het versiebeheersysteem. Zie verder Verwijzingen, Database Updaten en Cache Update. De ReleaseConfigurator wordt gebruikt tijdens het toevoegen van een nieuwe release. Zie het bovenstaande voorbeeld en Downloaden uitpakken .zip. VAN WEBSERVER NAAR WEBAPPLICATIE

Andersom wordt de connectie maar op één manier gebruikt: het aangeven hoever de server is met het uitvoeren van de ‘requests’. -

StatusConfigurator: o Change status

De StatusConfigurator wordt gebruikt voor het veranderen van een status. Zie voor de oplossing: veranderen status. PROBLEMEN


Het kan zijn dat er meerdere SOAP aanroepen achter elkaar gedaan worden. Dit komt vooral voor bij het aanpassen van de status. Omdat een SOAP aanroep wat vertraging kan hebben, is het mogelijk dat ze niet op chronologische volgorde doorkomen, en uitgevoerd worden. Hier moet rekening mee gehouden worden, want normaal gesproken werkt de code op de volgorde dat het uitgevoerd wordt. Hier wordt verder op ingegaan onder het kopje ‘veranderen status’.

48

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3. VERWIJZINGEN 3.1 APP.PHP Omdat de bestanden van het CMS waar de website aan gekoppeld is niet meer in dezelfde map zullen staan als de website zelf maar op een centrale plek, is het duidelijk dat er een uitbreiding moet komen aan het huidige CMS. Ook moet er bij de website zelf verwezen worden naar de centrale locatie. Op de centrale plek staan verschillende versies van het CMS die worden gebruikt door verschillende websites. Voor de verwijzingen van de website naar de bijbehorende versie van het CMS wordt het bestand ‘app.php’ gecreëerd. Dit bestand wordt elke keer aangemaakt (en dus vervangen als hij al bestaat) wanneer de website van CMS-versie verandert, of een website wordt toegevoegd aan het systeem. De inhoud van app.php kan er als volgt uitzien:

In dit voorbeeld zijn 0_9_7 als CMS-versie en 1_9_7 als framework-versie gebruikt. ‘/domains/_manager/’ is het pad naar de centrale bestanden. Dit pad is afhankelijk van de server waarop de website zich bevindt. App.php wordt in de hoofdmap van de website geplaatst, naast het indexbestand van de website. In dit indexbestand worden de variabelen die ingesteld zijn in app.php opgehaald en gebruikt. Er is nu alleen een probleem. Het versiebeheersysteem heeft geen rechten op andere mappen dan zichzelf, waardoor het toevoegen van het app.php bestand niet direct mogelijk is. De volgende twee oplossingen zijn mogelijk: -

In de serverconfiguratie rechten geven aan het versiebeheersysteem voor bewerkingen in alle mappen. Het plug-in aan het CMS toevoegen die mogelijk maakt om app.php aan te maken, want het CMS heeft deze rechten wel.


De keuze is vooralsnog gevallen op de eerste optie. Deze brengt de minste mutaties met zich mee. Ook de beveiliging van het systeem gaat er niet onder lijden.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

49

3.2 BESTANDSLOCATIE De bestanden die nu gecentraliseerd zijn moeten te vinden zijn door de websites en het CMS. Deze bestanden staan op een andere locatie dan eerst. Met de bestanden bedoelen we onder andere plaatjes en Javascript bestanden. Er moet een oplossing worden gevonden voor hoe deze centrale bestanden gevonden kunnen worden door de website. Deze verwijzingen hebben te maken met het ‘documentpath’ van de website. Er moeten wellicht aliassen aangemaakt worden in de virtual host van een bepaalde website om te verwijzen naar deze centrale bestanden. We hebben nu een aantal oplossingen gevonden, met de volgende voor- en nadelen. -

-

In de virtualhost van de betreffende website aliassen aanmaken voor de nieuwe gecentraliseerde mappen. Hierbij wordt het versienummer telkens aangepast wanneer de CMS-versie van de desbetreffende website verandert. o Voordeel: in de bron van de website is niet te achterhalen welk versienummer er draait. o Nadeel: het virtualhost-bestand moet steeds aangepast worden, dit is niet wat je wil, want elke keer moet dan de server opnieuw opgestart worden. Ook zijn dit bewerkingen op serverconfiguratie niveau, wat niet wenselijk is. In de virtualhost alleen verwijzen naar de map waar alle versies instaan. Dan kan er in de code van de website verwezen worden naar het versienummer in die map met releases. Dit kan natuurlijk met een variabele voor elke mapverwijzing. o Voordeel: virtualhost wordt uitgebreid met maar één wijziging. Dit hoeft alleen maar te gebeuren wanneer de website wordt toegevoegd, wat nu ook al het geval is. o Nadeel: in de html-code van een pagina zijn de versienummers van het CMS te vinden, als deze veranderd worden kunnen ook andere versies bezocht worden.

Deze twee opties zijn eigenlijk beide niet wenselijk, omdat de nadelen te zwaar wegen. Er moet een combinatie gezocht worden die wel de voordelen van beide heeft, maar niet de nadelen. Hiervoor zijn we tot de onderstaande oplossing gekomen. Om deze duidelijk te maken, illustreren we de werking aan de hand van een voorbeeld: Stel, de volgende link wordt aangeroepen: www.domein.nl/central/javascript/script.js. 1. 2. 3.

.htaccess ziet de aanroep /central, en verwijst dit door naar central.php met variabele ‘javascript/script.js’. central.php veranderd de verwijzing in ‘/app/%versienummercms%/html/javascript/script.js’ de ‘/app’ verwijzing verwijst naar de centrale map. Door wat erachter staat weet de browser waar het bepaalde bestand te vinden is.

Voordelen hiervan zijn: -

De bezoeker van de website ziet geen verwijzing naar een versienummer, want deze verwijzing gebeurd onderwater. Er hoeft bij geen enkele update een verandering gedaan te worden op server niveau, wat een eis is van deze webapplicatie.

Om later nog te weten hoe het geheel werkt, en om de technische uitwerking duidelijk te maken hebben we de oplossing verder uitgewerkt in technische details (stapgewijs opgezet):


-

50

In het .htaccess bestand van de website de verwijzing ‘central’ aanmaken naar een bepaald bestand. (Het .htaccess bestand zorgt voor url verwijzingen naar bepaalde bestanden, wat het mogelijk maakt om naar andere mappen te verwijzen. Dit is een optie die nodig is om de verwijzing naar het centrale CMS te maken.)

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

-

-

In de virtualhost (VHOST) van elke website een verwijzing (alias) aanmaken naar de centrale mappen, dus niet naar een map met een versie, maar naar de hoofdmap. Dan hoeft alleen het VHOST bestand aangepast te worden wanneer een website wordt aangemaakt, wat nu ook al het geval is. Deze verwijzing houdt in dat als er /app achter de url getypt wordt, hij verwijst naar die centrale hoofdmap. Door in het bestandje central.php (die aangeroepen wordt door .htaccess) aan te geven welke versie er gebruikt wordt, kan door middel van de /app verwijzing in de VHOST naar de goede map worden verwezen. In central.php wordt gebruik gemaakt van app.php (zie onderdeel 3.1) zodat bekend is in welke mappen er gezocht moet worden.

We hebben deze oplossing besproken met de begeleider binnen het bedrijf en hij keurde deze goed.


Wel treedt er nog een probleem op wanneer deze oplossing ingevoerd wordt. De websites hebben namelijk standaard geen rechten op de centrale CMS-mappen. Dit is weer op te lossen door de rechten van de website uit te breiden naar de hoofdmap van de centraliseerde CMS-versies. Dat wordt gedaan door in de virtualhost van elke website de open_basedir uit te breiden met het pad naar de plaats waar de centrale CMS-versies staan.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

51

4. ZIP-ARCHIEF DOWNLOADEN EN UITPAKKEN Om de bestanden van een CMS-release op een server te krijgen moeten deze in een zip-bestand gearchiveerd staan zodat ze als één bestand geupload kunnen worden via het versiebeheersysteem. Tijdens het uploaden van een nieuwe release selecteert de beheerder het bestand dat de CMS bestanden bevat. Dit bestand wordt vervolgend geupload naar de server waar de webapplicatie op draait en klaargezet voor de overige webservers waar de upload naar toe moet. Twee opties zijn overwogen voor de overdracht van het zip-bestand: -

De server krijgt een link van waar het zip-bestand is geupload op de hoofdserver, zodat hij via deze link het zip-bestand kan downloaden. De server krijgt via SOAP het zip-bestand door en gaat daarmee aan het werk.

De tweede optie is een hele klus, aangezien je niet zomaar een heel zip-bestand kan versturen via SOAP. Deze moet dan helemaal gecodeerd worden naar een XML-gerelateerde vorm en aan de kant van de webservers weer gedecodeerd worden op het originele zip-bestand terug te krijgen. De eerste oplossing is daarom veel praktischer. Doordat enkel de link wordt verstuurd wordt er veel minder data via SOAP verstuurd. Het versiebeheersysteem verstuurt de link van de upload naar deze overige servers, zodat deze het CMS archiefbestand kunnen downloaden. De Configurators van de webservers controleren eerst nogmaals de structuur van de inhoud van de ZIP en pakken vervolgens het archiefbestand uit waarna ze de release in een map met het bijbehorende versienummer als mapnaam plaatsen. De nieuwe release is nu geïnstalleerd. De functies die voor het downloaden en uitpakken worden gebruikt, zijn geïmplementeerd in PHP zelf. Daarom is het slechts een kwestie van op de goede manier deze functies gebruiken en de goede mappen aangeven. STRUCTUUR VAN DE VERPLICHTE INHOUD VAN HET ZIP-ARCHIEF

/application /model /view /controller /html /admin /libraries /site /? /? /sql* /upgrade.sql /downgrade.sql


* niet verplicht

52

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

5. DATABASEMUTATIES Bij het toevoegen van een nieuwe versie van het CMS kan het voorkomen dat de database is veranderd. Het kan zijn dat er extra kolommen bijkomen in bestaande tabellen, of er zijn nieuwe tabellen toegevoegd. Er wordt gebruik gemaakt van een MySQL database. Bij het aanmaken van een website wordt er een standaard database ingeladen. Bij elke nieuwe toevoeging van een CMS-release moeten de veranderingen ten opzichte van deze standaard database aanwezig zijn. Bij elke upload wordt binnen de zip in een sql-map, die ook in elke releasemap wordt uitgepakt, geupload. In die sqlmap zitten .sql bestanden met daarin alle mutaties ten opzichte van de vorige versie van het CMS. Hierbij wordt aangenomen dat iedere versie die aan het systeem wordt toegevoegd een opvolger is van de versie ervoor. Het zip-bestand dat geüpload wordt bevat de map /sql. In deze map komen twee bestanden: upgrade.sql en downgrade.sql. Wanneer een website naar een nieuwere versie van het CMS wordt gebracht, moet elk upgrade.sql bestand aangeroepen worden vanaf de eerstvolgende CMS-versie ten opzichte van de huidige tot en met de CMS-versie die geselecteerd is. Wanneer een website gekoppeld wordt aan een oudere CMS-versie, dan wordt downgrade.sql aangeroepen. Ook dan moet downgrade.sql vanaf de eerst vorige versie tot aan de CMS-versie waarnaar hij gedowngraded wordt aangeroepen worden. Wanneer er een CMS-release uit het systeem wordt verwijderd, moeten deze bestanden blijven bestaan. Dit is nodig, omdat het up- of downgrade stappenproces anders updates mist van die bewuste release. Een ander idee dat bestond was om bij elke versie van het CMS alle mutaties ten opzichte van de standaard database toe te voegen. Het probleem daarbij is dat het systeem niet weet wat de wijzigingen zijn ten opzichte van de vorige versie wanneer een website naar een andere versie wordt geup- of downgraded. Wanneer deze wijzigingen niet bekend zijn, moet er telkens eerst naar de standaard versie van de database gegaan worden en daarna de updates uitvoeren van de geselecteerde CMS-versie. Dit kost veel meer performance dan de uitwerking die eerder genoemd is.

6. VERANDEREN STATUS Om als gebruiker een goed overzicht te hebben van wat de servers aan het doen zijn, is het nodig dat de servers dat aangeven. Na elke actie die een server uitvoert wordt er een statuswijziging naar de webapplicatie teruggestuurd (via een SOAP bericht), die op zijn beurt deze statuswijzigingen kenbaar maakt aan de gebruiker. Na overleg met de begeleider van het bedrijf hebben we besloten dat dit onderwerp ook belangrijk is in het versiebeheersysteem. Voor elke server moet er te zien zijn wat zijn status is: Bij het toevoegen van een release: • • • • •

uploaden van pc naar hoofdserver (alleen op hoofdserver) connectie maken met hoofdserver downloaden van hoofdserver controleren uitpakken

Bij het toevoegen van een website / veranderen van CMS-versie van website: app.php aanmaken database aanpassingen cache opbouwen

Final report

|

John Ciocoiu


• • •

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

53

Deze statussen kunnen verschillende waardes hebben: 1. 2. 3. 4.

Niet bekend Bezig Voltooid Mislukt

Een server geeft aan of de acties die uitgevoerd moeten worden goed zijn verlopen of niet. Hieronder worden twee mogelijke oplossingen uitgelegd en vergeleken: 1.

Uitbreiden van de Server-tabel in de database met een status veld. In dit veld is een string te vinden met getallen. Elke status heeft zijn eigen getal binnen de string, de waarde ervan staat voor de waarde e e van de status. Beschouw bijvoorbeeld de string “01231”. Hierbij heeft de 1 status de waarde 0, de 2 e status de waarde 1, de 3 status de waarde 2, enz. Om de verschillende statussen aan te geven is ook een tabel aangemaakt die voor elk getal een statusbericht definieert. Voordeel: weinig mutaties in de software, het is een kwestie van uitlezen van de string in de database en deze linken aan de goede statussen. Nadeel: hierbij komt het probleem naar voren dat SOAP zijn berichten niet chronologisch stuurt. Als er een character in de string veranderd moet worden moet deze eerst uitgelezen worden. Dit kan langer duren waardoor de volgende statuswijziging ook nog de oude string gebruikt. Hierdoor wordt één van de twee wijzigingen niet doorgevoerd.

2.

Database uitbreiden met een extra tabel, die linkt elke status van een server aan elke server, en de daar bijbehorende statuswaarde. Om de verschillende statussen aan te geven is ook hierbij een tabel aangemaakt die voor elk getal een statusbericht definieert. De tabel krijgt als inhoud het aantal servers maal het aantal statussen. Door deze verwijzingen uit te lezen kan er aan de gebruiker getoond worden wat er in de database gebeurd en wat de status is van een server. De voordelen en nadelen hiervan zijn eigenlijk precies het tegenovergestelde van optie één: Voordeel: de niet-chronologische manier van doorsturen maakt hierbij niet uit. Elke keer wordt er één entry in de database veranderd en het maakt niet uit in welke volgorde dit gebeurd. Nadeel: er moet relatief veel aangepast worden aan de software, er moeten links gelegd worden tussen de nieuwe tabellen en de servers moeten op een andere manier uitgelezen worden.


De keuze hierbij is gevallen op de tweede optie. Hierbij is het voordeel groter dan het nadeel. De mutaties in de software hebben verder geen invloed op het juist functioneren ervan. De eerste optie heeft dit wel, omdat statussen door de niet-chronologische manier van doorsturen van soap berichten ervoor kan zorgen dat statussen onjuist worden opgeslagen en weergegeven.

54

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

BIBLIOGRAFIE 1. About. Zend Framework. [Online] Zend, 2010. [Citaat van: 7 Mei 2010.] http://framework.zend.com/about/overview. 2. Zend Framework Manual. Zend Framework. [Online] 2010. [Citaat van: 6 5 2010.] http://zendframework.com/manual/en/introduction.overview.html. 3. SOAP. Wikipedia. [Online] Wikipedia, 2010. [Citaat van: 7 Mei 2010.] http://nl.wikipedia.org/wiki/SOAP. 4. W3 SOAP. SOAP Version 1.2. [Online] W3, 2010. [Citaat van: 7 Mei 2010.] http://www.w3.org/TR/2007/RECsoap12-part1-20070427/.


5. SOAP tutorial. w3schools. [Online] [Citaat van: 3 5 2010.] http://www.w3schools.com/soap/default.asp.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

55

G Plan van aanpak VOORWOORD In het zesde semester van de Bsc-opleiding Technische Informatica aan de TU Delft dient een Bachelorproject uitgevoerd te worden. Het Bachelorproject heeft meestal de vorm van een stage in een bedrijf, waar de studenten in groepsverband (2, 3 of 4) onder begeleiding van een opdrachtgever (mentor) en onder supervisie van een informaticadocent (begeleidend docent) een bijdrage leveren aan een automatiseringsproject.

SAMENVATTING Dit document beschrijft het probleem en het Plan van Aanpak van een automatiseringsproject bij het bedrijf `ReproVinci Internetdiensten B.V.´ te Schoonhoven. Het bevat alle overeenkomsten tussen de opdrachtgever en de projectleden. Bovendien wordt beschreven hoe het project gefaseerd zal worden en worden overige afspraken vastgelegd. Tijdens de uitvoering van de opdracht is de mentor verantwoordelijk voor de keuze van de te implementeren oplossing. De begeleidend docent kan hierbij wel adviseren.

1. INTRODUCTIE ReproVinci Internetdiensen B.V. is een bedrijf dat zich bezig houdt met het maken van websites. Het beschikt over een eigen Content Management System (CMS), die een klant van een website bij ReproVinci in staat stelt, middels een grafische interface, de website naar eigen smaak in te richten. Zo kan deze klant bijvoorbeeld elke tekst en knop wijzigen en makkelijk extra pagina’s aanmaken die binnen het afgespraken kader liggen. Dat kader kan bijvoorbeeld bestaan uit enkel pagina’s waar nieuwsberichten op geplaatst kunnen worden of uit webwinkelpagina’s. ReproVinci beheert op dit moment ongeveer 70 websites met daaraan gekoppeld het CMS.

1.1 AANLEIDING Naar aanleiding van een gesprek tussen projectleden Elwin en John en werkgever `Reprovinci Internetdiensten B.V.´ te Schoonhoven, waren er een tweetal opdrachten die geschikt leken als stageopdracht voor een Bachelorproject: centralisatie van het huidige Content Management System (CMS), waardoor het eenvoudiger wordt het CMS en Framework versiebeheer van websites te controleren; videostreaming voor websites, waarbij video’s naar websites geüpload kunnen worden en vervolgens geconverteerd kunnen worden om ze geschikt te maken voor live streaming. De keuze is uiteindelijk gevallen op de eerste, omdat deze het meest uitdagend werd bevonden en het bedrijf goed kan ondersteunen in de toekomst bij het beheren van zijn websites.

1.2 ACCORDERING EN BIJSTELLING

   Final  report


Het plan van aanpak wordt door zowel `ReproVinci Internetdiensten B.V.’ als door de TU Delft goedgekeurd. Eventuele wijzigingen in het Plan van Aanpak worden besproken en doorgevoerd in het document. Het versienummer op de titelpagina wordt in dit geval met één verhoogd.

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

57

 1.3 TOELICHTING OP DE BOUW VAN HET PLAN Hoofdstuk 2 van dit document bevat de opdracht van het project. In hoofdstuk 3 komt de aanpak en tijdsplanning aan bod. Hoofdstuk 4 bevat de projectinrichting. En het laatste hoofdstuk 5 bevat de kwaliteitsborging.

2. PROJECTOPDRACHT 2.1 PROBLEEMSTELLING Het CMS wordt op dit moment handmatig gekoppeld aan een website. Ook het Zend Framework, wat gekoppeld is aan een CMS, dient van tijd tot tijd vervangen te worden. Dit Framework bevat basisfunctionaliteit en bibliotheken voor het CMS. Telkens wanneer er een update van het CMS wordt uitgebracht, waarbij bepaalde bestanden van het CMS vervangen dienen te worden, moet dit handmatig gebeuren. Bij iedere website waarbij deze update noodzakelijk is dienen de oude bestanden vervangen te worden door de nieuwe. Dit handmatig controleren en vervangen van bestanden kost veel tijd, zeker omdat het aantal klanten toeneemt. Wanneer bij een update van het CMS ook meer functionaliteit ter beschikking komt, dient vaak ook de database-indeling verandert te worden. Op dat moment dient er handmatig een database synchronisatie te worden uitgevoerd.

2.2 DOELSTELLING PROJECT Een versiebeheersysteem voor het CMS van alle websites zorgt ervoor dat het up- en downgraden van een website veel sneller zal gaan, omdat het handmatig vervangen van database-elementen en bestanden geautomatiseerd wordt. Verder heeft de websitebeheerder een goed inzicht over welke versie iedere website draait. De opdrachtgever heeft het resultaat nodig om meer grip te krijgen op het CMS en de downtime van websites (tijdens het updaten) te verminderen. Die downtime is nu hoog door het handmatig updaten. Tevens heeft de opdrachtgever een beter inzicht in hoeveel installaties er zijn en kan deze de CMS/Framework versies van alle websites eenvoudig wijzigen.

2.3 OPDRACHTFORMULERING Het versiebeheersysteem wordt ontwikkeld in de vorm van een webapplicatie, die de volgende mogelijkheden moet kennen: -


-

een goed beveiligd inlogsysteem, overeenkomstig met het huidige inlogsysteem van het CMS de webapplicatie dient overal waar een internetverbinding ter beschikking is gebruikt te kunnen worden een overzicht tonen van alle websites waarbij: o de versie van het CMS zichtbaar is o de versie van het Zend Framework zichtbaar is het CMS van de websites vanuit het overzicht op gemakkelijke wijze naar een hogere versie upgraden of naar een lagere versie downgraden

58

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

-

nieuwe releases van het CMS uploaden, met daarbij eventueel een nieuwe versie van het Framework, naar servers van ReproVinci nieuwe websites toevoegen aan het systeem bestaande websites verwijderen uit het systeem Meer opdrachtformuleringen zijn te vinden in het `Requirement Analysis Document (RAD)’. De opdrachtgever verwacht een werkend product, dat voldoet aan bovenstaande eisen. De opdrachtgever verwacht overleg over de werkzaamheden. Omdat het een niet extreem groot bedrijf betreft, wordt er normaal gesproken minder tijd gestoken in de documentatie / het ontwerp dan dat er tijdens TU projecten gebruikelijk is. Bij dit project wordt er aan de norm van de TU gehouden.

2.4 OP TE LEVEREN PRODUCTEN EN DIENSTEN Het resultaat van het project is een goedwerkend en getest product dat voldoet aan de eisen van punt 2.3. Het op te leveren product is een product waarin op snelle en flexibele wijze CMS installaties geupdate en gedowngrade kunnen worden.

2.5 EISEN EN BEPERKINGEN Er zitten eisen aan de procestijd van de functies binnen een systeem. Het veranderen van de versie van het CMS van een bepaalde site zou in enkele minuten gebeurd moeten zijn, de klant van de website heeft hier minimaal last van. Het uploaden van een nieuwe versie van het CMS of Framework naar de servers zal meer tijd in beslag nemen, maar de websites hebben hier weinig last van. Het aantal handelingen die de gebruiker van het systeem moet uit voeren om zijn doel te bereiken, dienen minimaal te zijn. De interface moet eenvoudig zijn.

2.6 VOORWAARDEN De tijd die beschikbaar is in de implementatiefase voor het uitwerken van het probleem is 7-9 weken. Belangrijk is dat tijdens de oriëntatiefase goed wordt nagedacht over het ontwerp, zodat de implementatiefase soepel kan verlopen.

3. AANPAK EN TIJDSPLANNING Het project is opgedeeld in 3 fases: -

Oriëntatie/Ontwerp fase van 3 weken, waarin onderzoek wordt gedaan naar de te gebruiken technieken en diverse ontwerpdocumenten worden gemaakt waarin duidelijk wordt welk probleem er is en op welke manier dit opgelost zal gaan worden.

-

Implementatiefase van 7 – 9 weken, waarin de gevonden oplossingsmethode geïmplementeerd en getest worden.

-

Een afrondingsfase, waarin centraal staat het goedkeuren van het stageverslag en het houden van een voordracht

Een uitgebreide planning is te vinden in bijlage A.


Belangrijk is dat tijdens het gehele proces wordt gelet op de eisen van punt 2.5.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

59

4. PROJECTINRICHTING Het doel van projectinrichting is het zichtbaar maken van de wijze waarop de projectmanager van plan is het project in te richten om de opdracht uit te voeren volgens de voorgestelde aanpak.

4.1 ORGANISATIE Beide projectleden zijn verantwoordelijk voor het naar behoren functioneren van het gehele versiecontrolesysteem.

4.2 PERSONEEL Er wordt fulltime gewerkt, maandag t/m vrijdag van half 9 tot 17 uur. Geprobeerd wordt zoveel mogelijk de gemaakte planning(en) na te streven.

4.3 ADMINISTRATIEVE PROCEDURES Er zal tijdens de oriëntatiefase één keer per week een voortgangsgesprek plaatsvinden met de TUbegeleider. Tijdens de implementatiefase zal dit waarschijnlijk wat minder gebeuren.

4.4 FINANCIERING NVT. In principe zijn alle benodigde resources aanwezig op het bedrijf. Zie ook punt 4.6.

4.5 RAPPORTERING De opdrachtgever is op dezelfde locatie aanwezig als de projectleden. De TU-begeleider wordt regelmatig opgezocht in Delft en zal een keer naar Schoonhoven komen. De rapportering vindt mondeling en schriftelijk plaats.

4.6 RESOURCES Er wordt gebruik gemaakt van twee werkplekken, voorzien van een pc met internetaansluiting en de benodigde software. Verder is er vanaf de werkplekken toegang tot een aantal servers, die gebruikt worden voor het hosten van de websites. Ook is er een lokale server, die de testomgeving bevat.

5. KWALITEITSBORGING


Er wordt door de opdrachtgever actief meegedacht tijdens het ontwerpen en implementeren van het te maken systeem. Hij is altijd op de hoogte van de status van het project. Er moet door de projectleden worden gedocumenteerd, zodat zodra de stageperiode er op zit, er genoeg informatie over het systeem gedocumenteerd is voor eventuele uitbreidingen.

60

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

BIJLAGEN A. PLANNING

ORIENTATIEFASE week

week 1 week 2

week 3

activiteit

Deliverables

Plan van Aanpak opstellen Requirements verzamelen Gebruike technieken onderzoeken Ontwerpdocumenten/Orientatieverslag schrijven Ontwerpdocumenten/Orientatieverslag schrijven

PvA, RAD, ADD, (T&IP, MoSCoW) ADD, TDD, T&IP, MoSCoW vrijdag 7 mei: oriëntatiefase verslag (5-10 bladzijden) diverse ontwerpdocumenten (RAD, ADD, TDD, T&IP, MoSCoW)

IMPLEMENTATIEFASE week

activiteit

week 4 week 5

GUI Online servers klaarzetten Connectie maken, uploaden / updowngraden

week 6 week 7 week 8 week 9 week 10 (week 11) (week 12)

Deliverables

Extra functionaliteiten toevoegen Zend versie los te updaten Zoekfunctie inbouwen

eindverslag

NB. Activiteiten in de implementatiefase zijn de namen van de milestones uit het Test & Implementation Plan document (T&IP). Zie ook dat document voor een uitgebreide beschrijving van deze activiteiten.

AFRONDINGSFASE activiteit

Deliverables

Week ? Week ?

Voordracht voor commissie Goedkeuring stageverslag


week

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

61

H RAD INHOUDSOPGAVE


1. Introductie......................................................................................................................................................... 64 2. Huidige Systeem ................................................................................................................................................ 64 2.1 Opbouw van een website met CMS............................................................................................................ 64 2.2 Functies en elementen binnen het CMS ..................................................................................................... 65 2.2.1 Structuur.............................................................................................................................................. 65 2.2.2 Content ................................................................................................................................................ 65 2.2.3 Formulieren ......................................................................................................................................... 66 2.2.4 E-commerce......................................................................................................................................... 66 2.2.5 Nieuwsbrief ......................................................................................................................................... 66 2.2.6 Mediabibliotheek ................................................................................................................................ 67 2.2.7 Gebruikersbeheer ................................................................................................................................ 67 2.3 Huidige manier van updaten ...................................................................................................................... 67 3. Voorgesteld systeem ......................................................................................................................................... 68 3.1 Overzicht ..................................................................................................................................................... 68 3.2 Functionele eisen ........................................................................................................................................ 68 3.3 Niet-functionele eisen ................................................................................................................................ 69 3.3.1 Gebruikersinterface en menselijke factoren ....................................................................................... 69 3.3.2 Documentatie ...................................................................................................................................... 69 3.3.3 Hardware overwegingen ..................................................................................................................... 69 3.3.4 Prestatie karakteristieken ................................................................................................................... 69 3.3.5 Foutafhandeling en extreme condities................................................................................................ 69 3.3.6 Systeem interface ................................................................................................................................ 69 3.3.7 Kwaliteitseisen..................................................................................................................................... 69 3.3.8 Systeem aanpassingen ........................................................................................................................ 70 3.3.9 Fysieke omgeving ................................................................................................................................ 70 3.3.10 Veiligheidseisen ................................................................................................................................. 70 3.3.11 Resources en beheerzaken ................................................................................................................ 70 3.4 Constraints (“Pseudo eisen”) ...................................................................................................................... 70 3.5 Systeem Modellen ...................................................................................................................................... 71 3.5.1 Use case model.................................................................................................................................... 71 3.5.2 Object Model ....................................................................................................................................... 78 3.5.3 Dynamic Models .................................................................................................................................. 79 3.5.4 Gebruikersomgeving ........................................................................................................................... 83

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

63

1. INTRODUCTIE Reprovinci Internetdiensten B.V. is een bedrijf dat zich bezig houdt met het maken van websites. Daarnaast gebruikt het een eigen Content Management Systeem (CMS). Beide onderdelen zijn opgebouwd met behulp van een framework, het Zend Framework. In het CMS kan de gehele website in een grafische interface door de klant beheerd worden. Het CMS maakt het mogelijk om elke tekst en knop op de website moeiteloos te wijzigen. Het CMS wordt aan elke website gekoppeld. Natuurlijk komt er zo nu een dan een update uit van het CMS. Om deze update uit te voeren moeten bij elke klant handmatig de oude bestanden van het CMS vervangen worden door de nieuwe. Het vervangen van deze bestanden kost veel tijd, zeker nu er steeds meer klanten bij komen. Wanneer er bij een update meer functies beschikbaar worden, moet ook de database bijgewerkt worden en wellicht daarbij de cache-bestanden. Dit proces kost ook veel tijd omdat er handmatig een database synchronisatie uitgevoerd moet worden. In het nieuwe systeem is het belangrijk dat het CMS en het Framework achter de websites moeiteloos geüpgraded en gedowngraded kunnen worden naar alle versies die ooit uitgebracht zijn, waarbij de tijd die dit in beslag neemt aanzienlijk wordt verminderd in vergelijking met het huidige systeem.

2. HUIDIGE SYSTEEM ReproVinci Internetdiensten B.V. maakt websites met daarachter een Content Management System (CMS). Vanuit het CMS kan de koper (beheerder) van de website zijn website beheren. Elke website heeft nu een versie van het CMS achter de website staan. Er is dus niets gecentraliseerd.

2.1 OPBOUW VAN EEN WEBSITE MET CMS ReproVinci maakt gebruik van het Zend Framework. Dit Framework is in zijn geheel in PHP geïmplementeerd. Zend maakt het mogelijk om volgens het Model View Controller (MVC) principe aan het werk te gaan. Alleen de controllers, de models en de views moeten nog ingevuld worden, de rest staat klaar. Ook bevat Zend functies en modules die het ontwikkelen van een website ondersteunen, dat wil zeggen dat veel gebruikte functies al geïmplementeerd zijn (zoals mails versturen en pdf’s maken). Dit Framework zorgt er voor dat hetgeen wat de bezoeker van de website wil zien ook te zien krijgt. Dus zijn request wordt omgezet in een response. Voordat de response wordt opgebouwd uit de request moeten er een aantal controles worden uitgevoerd, zoals bijvoorbeeld authentificatie (mag de bezoeker het opgevraagde deel wel zien?). De pagina (de view) die de bezoeker wil zien, wordt dus opgebouwd door de controller met behulp van de models (gegevens uit de database ordenen en leesbaar maken). Ook het CMS is op basis van het Zend Framework gebouwd. Wanneer er bij een website ‘/admin’ achter het adres van de website wordt getypt volgt er het inlogscherm van het CMS waarvan alleen de beheerder van de website de inloggegevens weet (de authenticatie controle in Zend).


Voor het CMS, een website en het Zend Framework worden in totaal rond de 10.000 bestanden gebruikt, waarvan ongeveer 1000 voor de website zelf. Er zitten nu dus achter elke website 9000 bestanden die gebruikt worden door het CMS. Het kan ook zijn dat een klant niet alle functies van het CMS koopt bij zijn website (bijvoorbeeld geen winkelwagentje of iets dergelijks). In dat geval worden wel alle bestanden neergezet, maar de gebruiker heeft dan geen rechten op deze Website CMS onderdelen.

64

De website en het CMS maken gebruik van een MySQL-database. Daarin wordt niet alleen de structuur en de inhoud van de website opgeslagen, maar ook de gegevens van gebruikers van de website die een formulier invullen. Dit doen ze bijvoorbeeld bij het bestellen van een product.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

Database

|

Final report

2.2 FUNCTIES EN ELEMENTEN BINNEN HET CMS Met het beheren van de website wordt bedoeld dat de klant van ReproVinci niet alleen de teksten en knoppen aan kan passen op de website, maar ook, wanneer het een webwinkel is, producten en orders kan beheren. De belangrijkste elementen van de website kunnen dus beheerd worden. Hieronder staan alle functies en elementen op een rijtje die vervolgens worden uitgelegd: • • • • • • •

Structuur (2.2.1) Content (2.2.2) Formulieren (2.2.3) E-commerce (2.2.4) Nieuwsbrief (2.2.5) Mediabibliotheek (2.2.6) Gebruikersbeheer (2.2.7)

Voor elk van de functies bestaat er een controller. Deze controllers kunnen gebruik maken van dezelfde models. Hieronder wordt kort per punt een beschrijving gegeven van de werking en van wat er allemaal beheerd kan worden.

2.2.1 STRUCTUUR Een website is opgebouwd als een boomstructuur. De hoofdknoop van de boom is de ‘home’ (begin) pagina van de website. De items in het menu die op de beginpagina te zien zijn, zijn de knopen in de eerste laag onder de eerdergenoemde hoofdknoop. Hoe meer lagen de boomstructuur van een site heeft, des te dieper is de structuur van de site. Meer lagen betekent dat de bezoeker verder `door kan klikken’ in het menu. De bezoeker van de website bezoekt dus een bepaalde knoop en daarmee een bepaald onderdeel van de website. Met behulp van het CMS kan de beheerder van de website deze boom beheren. Hij kan knopen toevoegen en verwijderen in de structuur. Deze knopen worden allemaal opgeslagen in de database. In het volgende onderdeel `content’ wordt uitgelegd wat de bezoeker daadwerkelijk te zien krijgt wanneer hij een bepaalde knoop bezoekt. Om een voorbeeld te geven van welke models voor de website en het CMS gebruikt worden, kijken we naar het knoopmodel, NavigationNode genaamd. Dit is een model die de eigenschappen van een knoop bevat zoals de naam van de knoop, verwijzing naar ‘children’-knopen (knopen in de volgende laag in de boom) en verwijzing naar de ‘parentnode’ (knoop in een laag hoger in de boom). De NavigationCollection is een verzameling van NavigationNodes, wat dus de eigenlijke boom voorstelt. Dus de NavigationCollection is een verwijzing naar de hoofdknoop. In de NavigationCollection zitten recursieve functies zodat er door de boom gezocht kan worden.

2.2.2 CONTENT


Content is eigenlijk het beste uit te leggen met voorbeelden. Onder content vallen alle soorten entiteiten die op de site te vinden zijn. Deze entiteiten verschillen per website, zo heeft een webwinkel van sjaals een sjaalentiteit, een boekhandel een boekentiteit en een nieuwssite een nieuwsentiteit. Zo moet een ‘koopbaar’ product een prijselement hebben en kunnen worden toegevoegd aan het winkelwagentje, en een nieuwsitem een tekstvak als element hebben om het nieuwsbericht in te plaatsen. Deze eigenschappen zijn in blauwdruk opgeslagen, dat dus ook verschilt per website. Hierdoor hoeft niet heel de code aangepast te worden, maar alleen de blauwdruk zodat de code zich aanpast op deze blauwdruk. Dat wil zeggen dat alle maatwerk voor een klant zich binnen dit bestand bevindt.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

65

Door de beheerder van de website kunnen van elk contententiteit instanties worden gemaakt. Dit zijn dus, bij het voorbeeld van de nieuwssite, de eigenlijke nieuwsitems op de site. Deze objectinstanties kunnen aan een knoop in de boom vastgemaakt worden en stellen dus eigenlijk de blaadjes voor die aan de boom vast zitten. Nog even terug naar het voorbeeld: als in de structuur van deze nieuwssite elke knoop een categorie van het nieuws voorstelt, kunnen de sportnieuwsitems aan de knoop sport vastgemaakt worden. Deze instanties worden opgeslagen in de databasetabel bij het desbetreffende content-object hoort (bv. nieuwsitem in de nieuws-tabel). Wanneer de bezoeker een knoop bezoekt, bezoekt hij eigenlijk de lijst van blaadjes die daaraan vast zitten (in het voorbeeld dus het nieuwsoverzicht). Als de bezoeker een blaadje bezoekt aan het einde van de node, bezoekt hij dus een content-item. De links tussen de knopen en blaadjes zijn ook allemaal in de database opgeslagen. Nu hebben we dus een boom met knopen en aan die knopen zitten de content-items. Maar hoe worden nu die content-items op de website neergezet? De request van de bezoeker van de website wordt behandeld door de controller van de site. Aan de hand van de link die de gebruiker ingevoerd heeft in de browser wordt bepaald naar welke knoop verwezen moet worden. De controller zoekt met behulp van een aantal models (onder andere de NavigationNode model) de goede content items op in de database en die worden dan in de view neergezet. De view zelf is een template in HTML die code bevat dat voor elke pagina hetzelfde zijn (bijvoorbeeld een plaatje bovenaan de site). Deze template met daarin de response op de request van de user wordt in de browser neergezet als de pagina die de bezoeker wil zien.

2.2.3 FORMULIEREN Een voorbeeld van een formulier is op een contactpagina te vinden is. De bezoeker van de website kan dan een aantal invoervelden invullen (naam, adres, woonplaats etc.). Deze formulieren kunnen in het CMS aangemaakt en verwijderd worden. Ook is er in het CMS te zien wat er allemaal in het formulier is ingevuld. Om zo’n formulier op de website weer te geven moet deze ook vastgemaakt worden aan een knoop in de boom en wordt dus daarmee ook een blaadje in de boom. De formulierstructuren worden opgeslagen in de database. Dus wanneer een bezoeker dit blaadje bezoekt, ziet hij een invulformulier.

2.2.4 E-COMMERCE Bij websites die een zogenoemd ‘winkelwagentje’ op de website hebben, is het e-commerce gedeelte geactiveerd. Hier kunnen de bestellingen van de klanten beheerd worden. Ook kunnen er statistieken worden bekeken over de omzet, afzet, winst, etc. Deze gegevens zijn ook allemaal in de database te vinden. De models maken van deze gegevens in de database dus bruikbare informatie, zoals dat voor elke maand de omzet berekend wordt van de orders van die maand in de database. In het overzicht van alle bestellingen kan hier ook de factuur en een etiket worden geprint en daarbij aangegeven worden welke status de bestelling heeft (in behandeling, verzonden (waarbij ook de track and trace code opgegeven kan worden) etc.). Ook is het hier mogelijk om een bestelling, of een deel ervan, te crediteren wanneer hij teruggestuurd wordt door de klant.


2.2.5 NIEUWSBRIEF

66

Bij websites die gebruik maken van een nieuwsbrief is dit gedeelte geactiveerd. Hier kan doormiddel van een grafische interface een nieuwsbrief samengesteld worden door de beheerder van de website. Een nieuwsbrief kan op verschillende manieren worden opgebouwd: er kan zelf tekst in getypt worden maar er kunnen ook content-items (uit de boom) aan vast worden gemaakt, zodat er onderdelen van de site meegestuurd kunnen worden. Ook kan ingesteld worden wanneer deze verstuurd moet worden en naar wie. Wanneer een bezoeker zich inschrijft op een nieuwsbrief, komt deze in de bijbehorende nieuwsgroep te staan in de database. De

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

beheerder van de website kan bij het verzenden, doormiddel van selecteren van deze nieuwsgroep, gelijk een hele groep mensen mailen die deze nieuwsbrief willen hebben.

2.2.6 MEDIABIBLIOTHEEK We gebruiken weer even het voorbeeld van de nieuwssite. Het kan zijn dat bij een nieuwsitem een aantal foto’s moeten worden toegevoegd. Deze kunnen dan hier worden geüpload. De foto’s worden dan op de server van de website gezet met een verwijzing ernaar in de database. Bij het bewerken van een nieuwsitem (zie 2.2.2) kunnen dan deze plaatjes toegevoegd worden. Naast plaatjes is het ook mogelijk om ander soort bestanden hier te uploaden die als downloadbestand bij een content-item toegevoegd kunnen worden.

2.2.7 GEBRUIKERSBEHEER Bij dit onderdeel is een overzicht te vinden van alle gebruikers in het systeem. Ook kan hier aangegeven worden welke rechten de gebruikers hebben. Als een gebruiker een product koopt op de website, zich aanmeldt op de nieuwsbrief enz. wordt hij toegevoegd aan de database. Als een ingelogde gebruiker meerdere knopen van de boom mag zien dan een anonieme gebruiker, kan dat hier ook ingesteld worden.

2.3 HUIDIGE MANIER VAN UPDATEN


Zoals hierboven verteld bestaat het CMS uit verschillende controllers, models en views. Dit zijn allemaal aparte bestanden. Er bestaan vooral veel models. Dit zijn, zoals bekend, de bestanden waarin de meeste berekeningen plaatsvinden. Stel dat er een uitbreiding in het systeem wordt doorgevoerd (eerst lokaal), dan wordt de controller aangepast, komen er models bij of worden de huidige models uitgebreid en zijn er mutaties nodig in de database. Er ontstaat dan dus lokaal een nieuwe versie van het systeem met deze uitbreiding erin. Om deze nieuwere versie door te voeren naar verschillende websites die online staan op één van de servers moet als eerst de database achter elke website geüpdatet worden doormiddel van synchronisatie met de vernieuwde lokale database. Daarna moeten de aangepaste bestanden geupload worden. Wanneer er veel aangepaste bestanden bestaan wordt voor het gemak alles opnieuw geupload. Als deze update dus achter verschillende websites gezet moet worden, kost dit veel tijd. Ook kan het zijn dat een website niet helemaal vlekkeloos werkt met de nieuwe versie. Dan moet er met alle haast gekeken worden waar dat aan kan liggen, zodat de tijd dat de website onbereikbaar is, geminimaliseerd kan worden.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

67

3. VOORGESTELD SYSTEEM 3.1 OVERZICHT In het huidige system kost het updaten veel tijd. Dit is niet het enige probleem. Elke website zit, zoals verteld, gekoppeld aan een versie van het CMS. Deze twee onderdelen zijn opgebouwd met behulp van het Zend Framework. Als het CMS en het Framework nu gecentraliseerd worden, kunnen we meerdere websites op dezelfde bestanden aansluiten. Dit biedt veel meer stabiliteit voor de klanten van het bedrijf. Door middel van een gebruiksvriendelijk systeem moet het up-/downgraden dus straks in een handomdraai gebeuren. In de interface, vanaf nu versiebeheersysteem genaamd, is een overzicht te vinden van alle websites en versie van het CMS. Vanuit het versiebeheersysteem is het mogelijk om een website te selecteren en deze te upgraden of downgraden naar een andere versie. Daarbij wordt gelijk de versie van het Framework gebruikt die bij de versie van het CMS hoort en ook wordt de database goedgezet naar de goede versie. Ook moet het mogelijk zijn om nieuwe versies van het CMS en websites in het systeem toe te voegen, zodat de nieuwe releases en websites gelijk in de interface te beheren zijn en er bestaande websites op de nieuwe versie van het CMS aangesloten kunnen worden. Bij het toevoegen van een CMS moeten de daarbij behorende bestanden geupload worden naar elke server. Bij het toevoegen van een website hoeft alleen een standaard database van de website klaargezet te worden door het versiebeheersysteem. De bestanden van de website zelf worden gewoon via ftp geupload.

3.2 FUNCTIONELE EISEN


Er is één type gebruiker van het systeem en dat is de beheerder van de websites. Dit zijn de eisen wat de gebruiker moet kunnen doen: Niet geauthentificeerde gebruikers mogen geen toegang tot het systeem kunnen krijgen. De webapplicatie dient overal waar een internetverbinding ter beschikking is gebruikt te kunnen worden. Een overzicht tonen van alle websites waarbij: o De versie van het CMS zichtbaar is o De versie van het Zend Framework zichtbaar is De websites vanuit het overzicht op gemakkelijke wijze naar een hogere versie upgraden of naar een lagere versie downgraden. Nieuwe releases van het CMS uploaden, met daarbij eventueel een nieuwe versie van het Framework, naar alle servers. Nieuwe websites toevoegen aan het systeem. Bestaande websites verwijderen uit het systeem. Overzicht servers en de mogelijkheid tot het toevoegen en verwijderen van servers Meer structuur aanbrengen in websites overzicht in plaats van één grote lijst. Bij alle of specifieke websites berichten of nieuwsmeldingen binnen het CMS plaatsen die informatie geven aan de klanten. Zend versie los kunnen uploaden van een CMS versie. Dit komt voor als er een bug in Zend zit en er nog geen nieuwe versie uit is van het CMS. Automatische versie synchronisatie van de releases tussen de servers Site verplaatsen tussen verschillende servers Filterfunctie (zoekveld) in het websites overzicht om sneller websites te vinden Meerdere websites tegelijk naar een bepaalde versie brengen

68

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.3 NIET-FUNCTIONELE EISEN 3.3.1 GEBRUIKERSINTERFACE EN MENSELIJKE FACTOREN De gebruikers hebben enige verstand van computers, omdat ze ook de beheerders zijn van de websites. Het versiebeheersysteem moet overzichtelijk zijn en vooral snel werken, omdat het updaten op de oude manier te veel tijd vergt.

3.3.2 DOCUMENTATIE Er is geen handleiding nodig om overweg te kunnen met het systeem, aangezien de gebruikers die er gebruik van maken allemaal weten hoe het werkt binnen het bedrijf.

3.3.3 HARDWARE OVERWEGINGEN Het systeem werkt volgens een webinterface dus een PC met internetverbinding is vereist. Wanneer er een nieuwe versie van het CMS geupload moet worden, is een snelle internetverbinding aanbevolen. Verder zijn er geen systeemeisen verbonden aan deze webapplicatie, want hij zou in elke browser gewoon moeten werken.

3.3.4 PRESTATIE KARAKTERISTIEKEN Er hoeft bij het wijzigen van versie van een website nagenoeg geen data verplaatst te worden, waardoor dit zeer snel kan gebeuren. Bij het installeren van een nieuwe versie zal meer tijd in beslag nemen. Dit komt ondermeer door de eventuele grote hoeveelheid data wat geüpload moet worden.

3.3.5 FOUTAFHANDELING EN EXTREME CONDITIES Het systeem moet goed kunnen omgaan met extreme condities. Wanneer tijdens het uploaden van een nieuwe versie de verbinding met internet wegvalt, moet bij het terugkeren van de internetverbinding de nieuwe versie alsnog geïnstalleerd kunnen worden. De gebruiker moet kunnen zien wanneer hoever de installatie is en of deze geslaagd is. Wanneer de database of stroomtoevoer uitvalt, is het nodig dat het systeem weet wat er wel en wat er niet gelukt is. Bepaalde deel processen (een upload die halverwege is) moeten een rollback kunnen ondergaan, zodat het systeem correct kan blijven werken.

3.3.6 SYSTEEM INTERFACE Alle servers bevatten alle beschikbare versies van het CMS en het Framework. De beheeromgeving (inclusief database) voor het voorgestelde systeem staat op één van deze servers. Bezoekers van een website waarbij een update wordt uitgevoerd, moeten een notificatie ontvangen dat de website offline is (http 503 fout).

3.3.7 KWALITEITSEISEN


Het systeem moet bijna volledige stabiliteit bieden en maximale bereikbaarheid genieten. Dit is voor een groot deel ook afhankelijk van derden, zoals ISP’s. Daarnaast mag het systeem niet meer dan 50 MB geheugen gebruiken. Dit is maximaal nodig voor het doorsturen van de nieuwe releasebestanden. 

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

69

3.3.8 SYSTEEM AANPASSINGEN De gebruiker heeft een goed overzicht van alle websites, met daarbij de CMS en Framework versie en op welke server deze websites staan.

3.3.9 FYSIEKE OMGEVING Geen bijzondere eisen.

3.3.10 VEILIGHEIDSEISEN Het systeem moet goed beveiligd zijn, aangezien het van alle websites, en dus alle klanten, het CMS beheert.

3.3.11 RESOURCES EN BEHEERZAKEN Het wijzigen van een versie van een website mag niet teveel resources in beslag nemen, omdat dit anders de overige websites vertraagt. Het updaten zal wel wat meer resources gebruiken, omdat er dan geruime tijd data wordt verstuurd.

3.4 CONSTRAINTS (“PSEUDO EISEN”) Het systeem wordt een webapplicatie en zal gebruik maken van de volgende (programmeer)talen: • PHP • MySQL voor de database • HTML • CSS • JavaScript / AJAX • XML Overige technieken die gebruikt gaan worden zijn: • Simple Object Access Protocol (SOAP)


Van het volgende PHP Framework wordt gebruik gemaakt: • Zend Framework

70

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5 SYSTEEM MODELLEN 3.5.1 USE CASE MODEL


3.5.1.1 USE CASE DIAGRAM

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

71

3.5.1.2 USE CASE BESCHRIJVINGEN USE CASE LOGIN (1) Gebruiker:

Websitebeheerder

Doel:

Inloggen voor toegang tot het systeem.

Preconditions:

De gebruiker beschikt over een gebruikersnaam met bijbehorende wachtwoord om in te kunnen loggen.

Samenvatting:

De gebruiker gaat naar de website van het systeem. Hij moet inloggen in het system door middel van het invullen van zijn gebruikersnaam en wachtwoord in de goede invulvelden.

Gerelateerde UCs:

Login is nodig voordat één van de andere use cases uitgevoerd kan worden.. Actie gebruiker:

Stappen:

Reactie systeem: 2. Toon twee invulvelden, één voor de gebruikersnaam en één voor het wachtwoord. 4. Checkt of de inloggegevens correct zijn. a. correct: de gebruiker krijgt toegang. b. incorrect: een foutmelding wordt getoond. Ga terug naar stap 2.

1. Start het system.

3. Vult de velden in en drukt op de submitknop om de inlogactie waar te maken.

Post conditions:

De gebruiker is ingelogd in het systeem en kan gebruik maken van de functies binnen het systeem.

USE CASE OVERZICHT WEBSITES RAADPLEGEN (2) Gebruiker:

Websitebeheerder

Doel:

Het inzien van het overzicht van alle websites.

Preconditions:

De gebruiker is ingelogd.

Samenvatting:

De gebruiker kan alle websites zien, met daarbij de versie van het CMS en Framework.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker klikt op ‘overzicht raadplegen’.

Stappen:

De gebruiker heeft een overzicht van alle websites.


Post conditions:

Reactie systeem: 2. Het systeem geeft een overzicht van alle websites met daarbij de versies van het CMS en Framework.

72

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

USE CASE WEBSITE TOEVOEGEN (3) Gebruiker:

Websitebeheerder

Goals:

Er wordt een website toegevoegd aan het systeem.

Preconditions:

De gebruiker is ingelogd en weet welke website hij gaat toevoegen. Hij weet op welke server hij dat doet en welke versie van het CMS nodig is voor deze website. Het overzichtscherm met websites is geopend.

Samenvatting:

De gebruiker klikt op de knop ‘website toevoegen’. Hij geeft aan welke versie van het CMS er gekoppeld moet worden aan de website. De server zet dan een lege database klaar, die bij die versie van het CMS hoort.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker toevoegen’.

Stappen:

klikt

op

‘website

3. De gebruiker vult de naam in en selecteert een versie van het CMS uit de lijst. Daarna drukt hij op de submit knop.

In het overzicht van de websites is een website toegevoegd met daarbij de juiste versie van het CMS dat erbij hoort.


Post conditions:

Reactie systeem: 2. Het systeem geeft een scherm terug met een aantal invulvelden: - Naam website - Welke server - Lijst van versies van het CMS 4. Het systeem zet een lege database klaar en maakt de mappenstructuur aan. Hij geeft aan dat de website toegevoegd is en gaat terug naar het overzicht maar dan met de melding dat het gelukt is.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

73

USE CASE WEBSITE VERWIJDEREN (4) Gebruiker:

Websitebeheerder

Goals:

Er wordt een website verwijderd van het systeem.

Preconditions:

De gebruiker is ingelogd en weet welke website hij gaat verwijderen. Het overzichtscherm met websites is geopend.

Samenvatting:

De gebruiker klikt op de website die hij wil verwijderen en klikt daarna op de knop ‘website verwijderen´ achter deze website. Na een bevestiging wordt de website verwijderd.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker selecteert achter de website die hij wil verwijderen de knop ‘website verwijderen’. 3. De gebruiker drukt op ‘Ja’.

Stappen:

Het overzicht van de websites toont de verwijderde website niet meer.


Post conditions:

Reactie systeem: 2. Het systeem geeft een melding terug met de vraag of de gebruiker wel zeker weet dat hij deze wil verwijderen. 4. Het systeem verwijdert de website uit de database en geeft het overzicht terug zonder de betreffende website erin, met de melding dat deze verwijderd is.

74

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

USE CASE WEBSITE UP- / DOWNGRADEN (5) Gebruiker:

Websitebeheerder

Goals:

Een website wordt aan een andere CMS gekoppeld in het systeem.

Preconditions:

De gebruiker is ingelogd en weet welke website hij gaat koppelen aan welke versie van het CMS.

Samenvatting:

De gebruiker klikt op de knop ‘bewerken´ achter de betreffende website, daarna gaat hij de website veranderen van CMS-versie.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker klikt op het knopje ‘website bewerken’ naast de te bewerken website.

Stappen:

3. De gebruiker klikt een andere versie van het CMS aan en drukt op ‘opslaan’.

In het overzicht van de websites is te zien dat de bewerkte website een andere CMS-versie heeft.


Post conditions:

Reactie systeem: 2. Het systeem geeft een scherm terug met daarin de huidige instellingen en informatie over de website. Zoals: - Naam website - Lijst van versies van het CMS Hierbij is ‘de lijst van versies van het CMS’ een dropdown menu. 4. Het systeem up-/downgrade de website en geeft het overzicht terug met de veranderde versie van het CMS achter de website, met de melding de site geup-/downgrade is.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

75

USE CASE OVERZICHT RELEASES RAADPLEGEN (6) Gebruiker:

Websitebeheerder

Goals:

Het inzien van het overzicht van alle CMS releases.

Preconditions:

De gebruiker is ingelogd.

Samenvatting:

De gebruiker gaat naar het overzicht van alle releases.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker klikt op ‘releases overzicht’

Stappen:

Post conditions:

Reactie systeem: 2. Het systeem geeft een overzicht van alle releases

De gebruiker ziet een lijst met alle releases

USE CASE NIEUWE RELEASE TOEVOEGEN (7) Gebruiker:

Websitebeheerder

Goals:

Er wordt een nieuwe versie van het CMS toegevoegd in het systeem.

Preconditions:

De gebruiker is ingelogd en weet welke release hij gaat uploaden. Het overzichtscherm met releases is geopend.

Samenvatting:

De gebruiker klikt op de knop ‘release toevoegen’. Hij geeft aan welke bestanden geupload moeten worden en welke versienaam hij heeft. De server zet de nieuwe release op de goede plaats.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker klikt op toevoegen release.

Stappen:

3. De gebruiker vult de naam in, geeft aan welke map geupload wordt en selecteert de zend versie. Daarna drukt hij op de submit knop.

In het overzicht van de releases staat een extra release.


Post conditions:

Reactie systeem: 2. Het systeem geeft een scherm terug met een aantal invulvelden: - Naam release - Bestand upload scherm - Selecteer Zend versie of upload nieuwe 4. Het systeem upload de aangegeven bestanden naar de juiste locatie. Als het mislukt is gaat hij terug naar stap 1, met de melding van het mislukken. Anders geeft hij aan dat hij toegevoegd is en gaat ook terug naar het overzicht maar dan met de melding dat het gelukt is.

76

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

USE CASE BESTAANDE RELEASE VERWIJDEREN (8) Gebruiker:

Websitebeheerder

Goals:

Er wordt een release verwijderd van het systeem.

Preconditions:

De gebruiker is ingelogd en weet welke release hij gaat verwijderen. Het overzichtscherm met releases is geopend.

Samenvatting:

De gebruiker klikt op de knop ‘release verwijderen´ achter de betreffende release. Na een bevestiging wordt de release verwijderd.

Gerelateerde UCs:

Login is nodig. Actie gebruiker: 1. De gebruiker klikt op verwijderen release.

Stappen:

3. De gebruiker drukt op Ja.

In het overzicht van de releases zonder de release die net verwijderd is.


Post conditions:

Reactie systeem: 2. Het systeem geeft een melding terug met de vraag of hij de gebruiker wel zeker weet dat hij deze wil verwijderen. 4. Het systeem verwijderd de release en geeft het overzicht terug zonder de betreffende release erin, met de melding dat het verwijderd is.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

77

3.5.2 OBJECT MODEL 3.5.2.1 DATA BIBLIOTHEEK • • • •

Website: naam, omschrijving, CMS-versie, server CMS-release: versienummer, Zend-versienummer Zend Framework: Zend-versienummer Server: aantal websites, aantal CMS releases, aantal Frameworks

3.5.2.2 KLASSE DIAGRAM 3.5.2.2.1 KLASSE DIAGRAM BESCHRIJVING • • • •

Een server bevat 0 of meer websites, CMS releases en Frameworks. Een website staat op een bepaalde server en is aan één CMS versie gekoppeld. Een versie van het CMS staat op elke server en heeft één bepaald soort Framework gekoppeld en wordt door 0 of meer websites gebruikt. Het Framework staat op elke server en wordt door 0 of meer CMS versies gebruikt.


3.5.2.2.2 KLASSE DIAGRAM

78

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5.3 DYNAMIC MODELS 3.5.3.1 ACTIVITY DIAGRAM: BESTAANDE RELEASE VERWIJDEREN


3.5.3.2 STATE DIAGRAM: SERVER STATUS

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

79

3.5.3.3 SEQUENCE DIAGRAMMEN 3.5.3.3.1 TOEVOEGEN WEBSITE


3.5.3.3.2 TOEVOEGEN RELEASE

80

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5.3.3.3 VERWIJDEREN WEBSITE


3.5.3.3.4 VERWIJDEREN RELEASE

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

81


3.5.3.3.5 UPGRADE / DOWNGRADE WEBSITE

82

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5.4 GEBRUIKERSOMGEVING 3.5.4.1 LOGINSCHERM

Dit is het inlogscherm dat de gebruiker ziet wanneer hij naar de pagina gaat en hij nog niet ingelogd is. In het bovenste veld moet, zoals verwacht, de gebruikersnaam ingevuld worden en in het onderste veld het wachtwoord. Doormiddel van de ‘inloggen’ knop kan ingelogd worden op het systeem.

3.5.4.2 HOMESCHERM

Dit is het beginscherm dat de gebruiker te zien krijg wanneer hij ingelogd is. In het menu aan de linkerkant kunnen op de knopjes websites en releases geklikt worden om naar de bijbehorende overzichten en opties te gaan.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010


Beschrijving:

83

3.5.4.3 WEBSITEOVERZICHT SCHERM

Beschrijving:


Overzicht van de websites. Doormiddel van de knopjes achter de websitenaam is het mogelijk om resprectivelijk de site te upgraden/downgraden en de site te verwijderen van de server. Het knopje rechtsbovenin, het documentje met het plusje, is het knopje om een website toe te voegen aan het systeem.

84

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5.4.4 WEBSITE TOEVOEGEN SCHERM

Beschrijving:


Wanneer er op het knopje van website toevoegen is gedrukt komt dit scherm tevoorschijn. Hierbij moet de naam van de website ingevuld worden, welke meestal overeenkomt met de domeinnaam van de website. Daaronder kan een versie van het CMS geselecteerd worden die bij de website hoort. Daar weer onder kan de site op een bepaalde server neergezet worden. Door op de opslaanknop te klikken (floppy rechtsbovenin) wordt de website toegevoegd.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

85

3.5.4.5 WEBSITE UPGRADE/DOWNGRADE SCHERM

Beschrijving:


Dit is eigenlijk het scherm waar alles om draait, de websites up-/downgraden op een simpele manier. De naam van de website is hier niet aan te passen. Onder de naam van de website staat de huidige versie van het CMS. Wanneer er op de dropdown wordt geklikt, worden alle versies van het CMS zichtbaar die op de servers staan. Door de versie te selecteren waarnaar de website geup-/gedowngrade moet worden en op de opslaanknop (floppy rechtsbovenin) te klikken, wordt er van een andere versie van het CMS gebruik gemaakt.

86

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5.4.6 RELEASEOVERZICHT SCHERM

Beschrijving:


Overzicht van de releases op de servers. Doormiddel van de knopjes achter de releasenaam is het mogelijk om resprectivelijk de release te wijzigen van naam en de release te verwijderen van de server. Het knopje rechtsbovenin, het documentje met het plusje, is het knopje om een release toe te voegen aan de servers.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

87

3.5.4.7 RELEASE TOEVOEGEN SCHERM

Beschrijving:


Hier kan een release van het CMS toegevoegd worden zodat hij te selecteren is bij het bewerken of het toevoegen van een website. De bestanden moeten weer in een zip geupload worden. De Zend-versie kan al op de server bestaan, als dit het geval is hoeft deze alleen maar geselecteerd te worden en dan hoeft er geen nieuwe versie van het Zend Framework geupload te worden. Door op de opslaanknop te klikken (floppy rechtsbovenin) wordt de release toegevoegd.

88

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

I ADD 1. INTRODUCTIE 1.1 DOEL VAN HET SYSTEEM ReproVinci Internetdiensten B.V. wil een beheersysteem voor al zijn websites (inclusief CMS) laten ontwerpen. De volgende hoofddoelen heeft het systeem: • • •

Overzicht hebben van alle websites die online staan. Gemakkelijk up- en downgraden van een bepaalde website. Gemakkelijk verschillende versies van het CMS beheren.

1.2 DESIGN DOELEN De beslissingen zijn genomen op de volgende volgorde van prioriteit (hoog naar laag): 1. 2. 3. 4.

betrouwbaarheid effectiviteit/efficiëntie gebruiksgemak onderhoudbaarheid

1. BETROUWBAARHEID

Omdat het hier gaat om het updaten van websites van klanten, moet het natuurlijk wel betrouwbaar zijn. De klanten moeten minimale hinder hebben van het updaten van een website. Dat wil zeggen dat de tijd dat de website eruit ligt minimaal moet zijn. Ook moet er, als er iets mis gaat met het updaten of dat de vernieuwde versie die gekoppeld is aan een website problemen geeft, weer snel teruggegaan kunnen worden naar de oude versie. Ook moet de applicatie goed kunnen omgaan met het onverwachts uitvallen van de internetverbinding. Wanneer er een updateproces of uploadproces gaande is als de internetverbinding uitvalt, moet dit geen problemen geven voor de rest van de websites. 2. EFFECTIVITEIT

Het gebruiken van het versiecontrolesysteem moet veel effectiever zijn dan de huidige manier van updaten. Dit moet ervoor zorgen dat het updaten minder tijd kost en zo goedkoper is voor het bedrijf. Er hoeven minder handelingen uitgevoerd te worden dan bij de huidige manier van updaten. 3. GEBRUIKSGEMAK

Het gehele systeem moet voor ervaren gebruikers eenvoudig te bedienen zijn. Deze gebruikers hebben kennis van de opbouw van de servers en van de websites met het CMS. 4. ONDERHOUDBAARHEID


Gezien eventuele toekomstige uitbreidingen dient het systeem zo opgebouwd te zijn dat veranderingen vrij gemakkelijk kunnen worden doorgevoerd. Bijvoorbeeld wanneer er een extra server bijkomt, moet het niet zo zijn dat er enorm veel code wordt veranderd. Een extra record in de Servers tabel in de database zou voldoende moeten zijn.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

89

1.3 BELANGRIJKE DESIGN KWESTIES Bij het ontwerpen van het systeem moeten er keuzes gemaakt worden. Sommige hiervan hebben veel invloed op het systeem en worden daarom als een ‘belangrijke kwestie’ gezien. De kwesties worden eerst aangegeven en daarna worden de opties weergegeven. Verderop gaan we in op de gemaakte oplossingskeuzes voor de problemen. Kwesties met opties: 1. Wat gebeurt er als er een upload bezig is en het internet valt weg? • Optie 1: het uploaden wordt automatisch hervat zodra de verbinding met het internet hersteld is. • Optie 2: er wordt een melding gegeven van de foutieve upload. Het geuploade deelbestand wordt verwijderd en de upload dient handmatig te worden herstart. • Optie 3: er worden meldingen gegeven over de status van de upload. Wanneer er een fout optreedt kan de upload handmatig terug worden gedraaid. 2. Wat gebeurt er als er op meerdere plaatsen wordt ingelogd? • Optie 1: Dit is niet mogelijk, toegang tot het systeem wordt geblokkeerd op het moment dat er ingelogd wordt, waardoor het niet mogelijk is om op meerdere plaatsten tegelijk in te loggen. • Optie 2: Dit is mogelijk, mits de server in idle-status is (zie RAD state-diagram). • Optie 3: Dit is altijd mogelijk. Als er een update in progress is bij één gebruiker zit deze website bij de overige gebruikers op slot. 3. Hoe wordt er omgegaan met de versies van het CMS op de servers? • Optie 1: Wanneer de gebruiker een nieuwe release upload, wordt deze achtereenvolgens naar elke server geupload. • Optie 2: De gebruiker upload de release naar één server. De server zorgen er onderling, middels synchronisatie, voor dat deze release overal terecht komt. 4. Hoe wordt de verbinding tussen de applicatie en de verschillende servers opgezet? • Optie 1: SOAP • Optie 2: XINS Gekozen oplossingen: 1.

2.

3.


4.

90

Wat gebeurt er als er een upload bezig is en het internet valt weg? • Gekozen is voor optie 3. Optie 1 valt af omdat deze te lastig is om uit te werken in de eerste fase. Ook met optie 2 is het lastig om automatisch te bepalen of de upload foutief is of dat de servers nog bezig zijn en valt daarom ook af. Wat gebeurt er als er op meerdere plaatsen wordt ingelogd? • Hier is voor optie 3 gekozen. Het is niet nodig om rekening te houden met het uploaden van nieuwe releases want dit gebeurt niet vaak, en al zeker niet tegelijk. Wel is het nodig rekening te houden met het updaten van een website. Als dit enige tijd duurt dan moet deze website gelocked worden totdat hij klaar is, zodat er tegelijkertijd door een andere user geen wijzigingen in kunnen worden aangebracht. Hoe wordt er omgegaan met de versies van het CMS op de servers? • Het gaat er als eerste vooral over de connectie tussen de applicatie en de verschillende servers en niet over de connectie tussen de servers. Daarom hebben wij als eerste optie 1 gekozen. Optie 2 is wellicht een mooie feature voor de vervolgversie van de applicatie. Hoe wordt de verbinding tussen de applicatie en de verschillende servers opgezet? • SOAP.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

2. VOORGESTELDE SOFTWARE ARCHITECTUUR 2.1 SUBSYSTEEM DECOMPOSITIE ARCHITECTUUR DIAGRAM

Het onderstaande diagram geeft schematisch de architectuur weer van ons systeem. De scheidingslijn geeft aan waar de grens zit tussen de opslag van de websites (webservers) en de eigenlijke applicatie die we gaan schrijven (webapplicatie). Dichte pijlen zijn controle pijlen, gestippelde zijn responses.

CONTROLLER De Controller van de webapplicatie bestuurt de Controllers van de overige (web)servers. Dit wordt gerepresenteerd door de pijl vanaf de Controller aan de webapplicatie kant naar de Controller aan de Webservers kant. Het ‘*-teken’ bij de Webservers geeft aan dat het hier meerdere servers betreft. Momenteel zijn er 4 servers die zijn ingericht als webserver. Een hiervan zal ook de webapplicatie gaan bevatten. Er is dus één pijl van Controller naar Controller die eigenlijk een zelfverwijzing is, echter de functie verschilt. De Controller van de Webapplicatie doet aanroepen, de Controllers van de webservers zijn vrij passief; er kan alleen een connectie mee opgesteld worden zodat ze (archief) bestanden kunnen ontvangen en ze zijn in staat deze bestanden uit te pakken en op de juiste plek neer te zetten. Verder beschikken ze over minimale lees- en schrijffunctionaliteit voor bepaalde bestanden die aangepast moeten worden.

VIEW De interface, het zichtbare gedeelte van de webapplicatie.

MODEL


Het Model bevat de diverse modellen met daarin functies die daar direct betrekking op hebben, zoals het opvragen van eigenschappen van een bepaalde website (naam, adres, ..)

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

91

SERVERINDELING

De webapplicatie draait op één server (Deimos). De verschillende versies van het CMS en het Zend Framework staan op alle servers. Een website staat op één bepaalde server. Het volgende diagram geeft dit schematisch weer: Deimos update-applicatie websites CMS* / Zend*

IO

Titania

Mars

websites

websites

websites

CMS* / Zend*

CMS* / Zend*

CMS* / Zend*

*meerdere versies CLIENT/SERVER COMMUNICATIE

Het volgende diagram toont hoe de communicatie verloopt tussen de diverse servers en de webapplicatie die door de gebruiker wordt aangestuurd. -


-

De gebruiker voert acties uit vanaf zijn locale computer die via internet verbonden is met de webapplicatie, die op server Deimos draait Aan Deimos hangt een database die o.a. verwijzingen bevat die laat zien op welke server welke websites draaien. Deimos stuurt berichten naar de overige servers (bijv. tijdens het uploaden van een nieuwe CMSrelease).

92

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

2.2 PERSISTENT DATA BEHEER DATABASE DIAGRAM

De Website tabel bevat alle websites. De name van de website is meestal gewoon de domeinnaam. De website kan geïdentificeerd worden doormiddel van het id. Een website staat op een server en aan een website hangt een CMS vast. Dit zijn dus de serverid en releaseid die in de website tabel weergegeven worden. Het veld createdate bevat de datum waarop de website is toegevoegd. De CMSRelease tabel bevat alle releases van het CMS. Deze kan ook geïdentificeerd worden aan de hand van de Primary Key id. Aan elk CMS zit een frameworkid en elke release heeft een version (zoals bijvoorbeeld CMS versie 1.3.2.1). Het veld createdate bevat de datum waarop de release is toegevoegd. Deletedate bevat de datum waarop de release is verwijderd. De reden dat de release niet direct wordt verwijderd is, omdat de eventuele databasewijzigingen bewaard moeten worden. Een release wordt locked op het moment dat deze door één of meer website wordt gebruikt. Op deze manier is makkelijk te controleren of een release uit het overzicht met releases verwijderd mag worden. Als een release databaseveranderingen bevat dan is het sqlmod veld op 1 gezet, anders 0. Deletedate is null wanneer de release wordt gebruikt. De ZendFramework tabel bevat alle releases van Zend die op de servers staan. Deze heeft naast het id ook een version om net zoals bij een CMS-release het versienummer van de versie van Zend aan te geven.


De Server tabel bevat alle servers die op dit moment in het systeem staan. Elke server heeft een id om zich te identificeren en heeft een name zodat dit makkelijker maakt ermee te werken. Waar op de server de websites geplaatst moeten worden staat in websitepath en waar de release bestanden komen in releasepath. Het master veld geeft aan of de betreffende server een hoofdserver is waarop de applicatie draait of dat het enkel een configurator betreft. De velden lastreleaseid en lastwebsiteid bevatten de id’s van de laatst ontvangen website of release.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

93

De ServerStatus tabel bevat de status van een server. Voor elke combinatie van server (serverid) en mogelijke status (statusid) wordt een record gemaakt met een value. Het aantal records in deze tabel is in principe aantal servers × aantal statussen. De Status tabel bevat alle mogelijke statussen met een message en het soort (kind) waarbij ze horen: website of release. Een status wordt geïdentificeerd aan de hand van zijn id. In de User tabel staan alle gebruikers die toegang hebben tot het systeem. Dit is nodig om de inloggegevens op te slaan zodat er gecontroleerd kan worden of de gebruiker daadwerkelijk toegang heeft. Het bevat een combinatie van username, password en name. DATA LOCATIE

In de database worden eigenlijk alleen maar verwijzingen opgeslagen. De daadwerkelijke bestanden van de website staan op een bepaalde server. De bestanden die bij het CMS en bij een Zend Framework versie horen staan op elke server. Op basis van de namen van de releases en de naam van het Zend Framework worden de mappen aangemaakt.

2.3 TOEGANGSCONTROLE Het inloggen gebeurt via server authentificatie. Inloggen kan vanaf iedere plek waar een internetverbinding ter beschikking is. De ingevoerde gebruikersnaam en wachtwoord worden gecontroleerd met die op de server staan. Bij overeenkomst wordt toegang tot het systeem gegeven.

2.4 CONCURRENCY CONCURRENCY BINNEN HET SYSTEEM

Concurrency binnen het systeem kan plaatsvinden wanneer wordt toegestaan dat op meerdere plaatsen tegelijk ingelogd kan worden in het systeem. OVERZICHT WEBSITES RAADPLEGEN

Dit levert in principe geen problemen op. Het kan zijn dat er een nieuwe website wordt toegevoegd (of een bestaande verwijderd) en deze elders nog niet zichtbaar is (of nog in het overzicht voorkomt). Dit levert echter geen conflicten op, aangezien het hier alleen raadplegen betreft. WEBSITE TOEVOEGEN

Dit gaat altijd goed. Wanneer dezelfde website vanaf verschillende locaties wordt toegevoegd, wordt dit afgevangen doordat er een controle is ingebouwd of de toegevoegde website niet al bestaat. Op verschillende locaties websites toevoegen zou in principe (in de toekomst) mogelijk moeten zijn. WEBSITE VERWIJDEREN

Dit kan problemen opleveren wanneer gebruiker X website A wil verwijderen en op hetzelfde moment wil op een ander systeem gebruiker Y website A aanpassen (upgraden/downgraden). Hiervoor zou bijvoorbeeld met website “locks” gewerkt kunnen worden of voordat de website verwijderd wordt, wordt gecontroleerd of deze nog wel bestaat. WEBSITE UPGRADEN/DOWNGRADEN

Zie website verwijderen. Wanneer meerdere gebruikers de versie van dezelfde website willen veranderen treedt concurrency op.


OVERZICHT RELEASES RAADPLEGEN

94

Net als bij het overzicht van websites raadplegen, levert dit geen problemen op.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

NIEUWE RELEASE UPLOADEN

Dit gaat altijd goed. Wanneer dezelfde release op verschillende locaties wordt toegevoegd, wordt dit afgevangen doordat er een controle is ingebouwd of de toegevoegde release niet al bestaat. Op verschillende locaties releases toevoegen zou in principe (in de toekomst) mogelijk moeten zijn. EEN BESTAANDE RELEASE VERWIJDEREN

Dit kan problemen opleveren wanneer gebruiker X release A wil verwijderen en op hetzelfde moment wil op een ander systeem gebruiker Y release A gebruiken voor een website (upgraden/downgraden). Hiervoor zou bijvoorbeeld met “locks” gewerkt kunnen worden of op het moment dat een website van CMS versie wordt veranderd wordt gecontroleerd of de release nog wel bestaat.

2.5 PROGRAM CONTROL Het systeem bestaat uit verschillende delen. Het is daarom belangrijk om vast te leggen welke verantwoordelijkheden waar liggen. Belangrijk is om het MVC principe goed te handhaven. Dat wil bijvoorbeeld zeggen, dat we ervoor moeten zorgen dat er minimale functionaliteit komt te zitten in het Model en geen functionaliteit in de View. Verder is het van belang dat de communicatie tussen de webapplicatie en de database hiervan, alsmede de communicatie vanaf de controller van de webapplicatie naar de diverse webservers goed verloopt.

2.6 RANDGEVALLEN De belangrijkste randgevallen zijn al opgenomen in het hoofdstuk “Belangrijke Design Kwesties” CRASH


Bij een crash gaan alle objecten in het geheugen verloren. Het kan voorkomen dat niet alle acties van een taak uitgevoerd zijn en er inconsistente data op de servers aanwezig is. Wanneer er wordt gewerkt met controle flags, of iets dergelijks, hoeft dit verder geen problemen op te leveren. Bijvoorbeeld, als een update of upload niet volledig slaagt, wordt dit aangegeven en wordt er een rollback knop geactiveerd. Na deze rollback kan pas weer een nieuwe update of upload door de gebruiker worden gestart.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

95

J TDD INHOUDSOPGAVE


1. Inleiding ............................................................................................................................................................. 98 1.1 Architectuur Diagram .................................................................................................................................. 98 2. Klasse indeling ................................................................................................................................................. 100 Webapplicatie ................................................................................................................................................. 100 Overige Servers ............................................................................................................................................... 102 3. Technische Aspecten ....................................................................................................................................... 103 3.1 Zend Framework ....................................................................................................................................... 103 3.2 SOAP .......................................................................................................................................................... 105 3.3 Verwijzingen .............................................................................................................................................. 108 3.4 Zip-archief downloaden en uitpakken ...................................................................................................... 110 3.5 Database Mutaties .................................................................................................................................... 111 3.6 Veranderen status ..................................................................................................................................... 112 Bibliografie .......................................................................................................................................................... 114

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

97

1. INLEIDING Dit document geeft het technisch ontwerp van ons systeem. Het is het laatste document voorafgaand aan de implementatiefase en bevat de opdeling van het systeem in diverse klassen. Dit document wordt, wanneer er tijdens de implementatie bepaalde oplossingen zijn gekozen, aangepast tijdens de implementatiefase.

1.1 ARCHITECTUUR DIAGRAM Hieronder is nogmaals (zie ADD) het architectuur diagram gegeven van ons systeem. De scheidingslijn geeft aan waar de grens zit tussen de opslag van de websites (webservers) en de eigenlijke applicatie die we gaan schrijven (webapplicatie). Dichte pijlen zijn controle pijlen, gestippelde zijn responses.

CONTROLLER


De Controller van de webapplicatie, weet hoe hij de Configurators van de overige servers kan bereiken. Vandaar de twee pijlen tussen Controller aan de webapplicatie kant en de Configurators aan de Webservers kant. In werkelijkheid zijn dit er nog meer, vandaar de “..”. Momenteel zijn er 4 servers die zijn ingericht als webserver. Een hiervan zal ook de webapplicatie gaan bevatten. Er is dus één pijl van Controller naar Configurator die eigenlijk een zelfverwijzing is, echter de functie verschilt. De Controller van de Webapplicatie doet aanroepen, waar de Configurator van de webservers vrij passief zijn en waar alleen een connectie mee opgesteld wordt zodat ze bestanden kunnen ontvangen.

98

Ook zorgt de controller ervoor dat de acties die de gebruiker doet in de views verwerkt worden. Zo geeft hij de lijst met websites door aan de views. Er zijn in totaal vier controllers voor de views, één voor het afhandelen van de login, één voor de homepagina, één voor de alle acties die betrekking hebben op de releases pagina en één voor de acties die betrekking hebben op de websites pagina. De laatste twee controllers zijn eigenlijk de belangrijkste controllers. De acties die daarin uitgevoerd kunnen worden komen redelijk overeen met elkaar. Zo kan er een website en een release worden toegevoegd, verwijderd en er kan een overzicht getoond worden. Echter een website bewerkt worden voor een release kan dat nog niet. Dit is volgens ons op dit moment nog niet nodig en valt dus onder de wensen.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

CONFIGURATOR

De Configurator is dus eigenlijk de klasse die connecties aan kan gaan met de webapplicatie en de webserver. De webapplicatie geeft aan wat er moet gebeuren op de webservers. De Configurator kan de aanvragen van de webapplicatie afhandelen op de webserver. Er zijn twee Configurators om de aanvragen af te handelen, één die betrekking heeft op de websites en één die betrekking heeft op de releases. Beide hebben een aantal functionaliteiten welke hieronder op een rijtje zijn gezet (voor meer details wordt verwezen naar de voorgaande documenten): WebsiteConfigurator: -

Aanmaken verwijzingen van de website naar centrale versie van CMS. Structuur database website veranderen naar goede versie. Zo nodig, cache website verwijderen en opnieuw opbouwen.

ReleaseConfigurator: -

Controleren en uitpakken zip-bestand in de centrale map. Verwijderen en opschonen van de verwijderde releases.

Omdat er ook nog een verbinding de andere kant op opgezet moet worden voor het terugzenden van de status van de server (zie SOAP), is er ook nog een Configurator nodig aan de kant van de webapplicatie. Dit is de StatusConfigurator die maar één funcitie heeft: het veranderen van de status van een server in het versiebeheersysteem. VIEW


Per scherm is er een .phtml bestand die de views voorstellen. Er is voor .phtml gekozen omdat er ook PHP in de HTML bestanden zit. Er is één ‘hoofdview’ dat het frame voorstelt waar de rest van de views in geplaatst worden. Daarnaast is er nog een los scherm dat het login scherm voorstelt. Dit valt ook binnen een apart frame.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

99

2. KLASSE INDELING WEBAPPLICATIE CONTROLLER


VIEW

100

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

MODEL

context User inv: id <> null inv: username.length > 3 inv: password.length > 5 inv: name.length > 3

context Framework inv: id <> null inv: name <> null context Release inv: id <> null inv: name <> null inv: framework <> null

context Server inv: id <> null inv: name <> null inv: hostname <> null inv: path <> null

Final report

|

John Ciocoiu


context Website inv: id<> null inv: name.length > 2 inv: cms_id <> null inv: server_id <> null inv: locked <> null

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

101

OVERIGE SERVERS


CONFIGURATOR

102

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3. TECHNISCHE ASPECTEN Op de drie webservers waar de webapplicatie niet (volledig) op draait, moet een Configurator komen die de ‘requests’ van de webapplicatie uitvoert. De Configurator moet verbinding kunnen maken met de server waarop de webapplicatie draait zodat het de aanvragen en kan ontvangen. Daarnaast moet de Configurator de status terug kunnen sturen van het verwerken van de aanvraag. Deze communicatie, beide kanten op, verloopt via SOAP. Hieronder worden technieken waar het systeem gebruik van maakt beschreven.

3.1 ZEND FRAMEWORK Het Zend Framework is een open source framework voor webapplicaties en services met PHP. Zend is een bedrijf dat zich met PHP bezighoudt en het Framework is door hen ontwikkeld (1). Het framework is geheel object-georiënteerd en zorgt er voor dat de webapplicatie, die met behulp van het Zend Framework gemaakt wordt, ook op een objectgeoriënteerde manier in elkaar wordt gezet (2). Het framework zorgt standaard voor een Model-View-Controller omgeving. Zend Framework is gericht op het bouwen van veilige, betrouwbare en moderne Web 2.0-applicaties en web services. Elk component is losjes gekoppeld aan andere componenten, wat ontwikkelaars in staat stelt om gebruik te maken van de afzonderlijke componenten. Daarentegen vormen de Zend Framework componenten binnen de standaard bibliotheek een krachtig geheel wanneer deze gecombineerd worden gebruikt. Om een idee te geven van een aantal functies binnen het Zend Framework, laten we twee voorbeelden zien. Er is voor deze voorbeelden gekozen omdat er in het versiebeheersysteem ook gebruik wordt gemaakt van deze functionaliteiten uit het Zend Framework. De volgende voorbeelden worden beschreven: automatisch inladen van php-klasse bestanden en het koppelen van de goede controller en functie daarin aan de url die ingegeven is. In PHP moet er naar elk bestand verwezen worden voordat het gebruikt kan worden. Omdat een webapplicatie uit meerdere, bij ReproVinci over de 700, klassenbestanden bestaat, wordt het een hele lange lijst met zogenaamde ‘includes’. In het Zend Framework is daar een oplossing voor gemaakt: de Autoloader. Deze Autoloader laadt zelf de bestanden in die nodig zijn. Bij het laden van de webapplicatie worden de locaties aangegeven waar de klassenbestanden te vinden zijn. Wanneer er een nieuwe instantie wordt gemaakt van een klasse, wordt automatisch het klassenbestand, met dezelfde naam als de klasse zelf, erbij geopend. Het volgende voorbeeld dat behandeld wordt, is de manier waarop het Zend Framework omgaat met de ingevoerde url’s. Wanneer er achter de domeinnaam geen variabelen meegegeven worden, wordt de IndexController aangesproken met daarin de indexAction methode. Als er in de url achter de domeinnaam bijvoorbeeld ‘/admin’ wordt ingetypt, gaat Zend op zoek naar de indexAction methode binnen de AdminController. Door de url langer te maken, bijvoorbeeld met ‘/admin/content’, kunnen meerdere methodes binnen de aangegeven controller aangeroepen worden. Een voordeel van het gebruik maken van het Zend Framework is dat het een stuk makkelijker en professioneler wordt om een webapplicatie op te zetten. Makkelijker omdat er gebruik wordt gemaakt van standaard componenten en professioneler omdat de code er netter door wordt en er worden standaard programmeer modellen gebruikt (zoals MVC). Je beschikt met Zend over een goed fundament, dat al grondig getest is. Dit neemt een aantal verantwoordelijkheden weg bij de programmeurs en het scheelt in implementatietijd. (3)

Het versiebeheersysteem zal, zoals hierboven al is verteld, ook gebruik gaan maken van het Zend Framework. Van de standaardbibliotheek gebruiken we het MVC raamwerk als basis voor onze applicatie. Wat ook mee woog in de keuze voor Zend, is dat het bestaande CMS hier ook op draait en de kennis dus aanwezig is binnen

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010


We zijn nog geen nadelen tegengekomen die betrekking hebben op het Zend Framework.

103

het bedrijf. Van de twee hierboven genoemde voorbeelden wordt ook gebruik gemaakt binnen het versiebeheersysteem. Zo zijn er nog meer functies die gebruikt worden door ons systeem, een paar belangrijke functies volgen: • •

De component Zend_Auth wordt gebruikt voor gebruikersauthentificatie. Van dit component zullen wij gebruik maken voor gebruikersauthentificatie. De component Zend_Soap wordt gebruikt voor het opzetten van de soap-server en soap-client.


Het component Zend_Db wordt gebruikt voor het opzetten van de connectie naar de database, ook zijn er subcomponenten die ervoor zorgen dat er gegevens uit de database ingeladen kunnen worden en mutaties aangebracht kunnen worden in de database. Door één syntax te gebruiken is het mogelijk om van verschillende typen databases gebruik te maken.

104

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.2 SOAP SOAP (Simple Object Access Protocol) is een ‘open standaard’ protocol dat gebruikt wordt voor communicatie tussen verschillende soorten componenten. Deze componenten kunnen zijn geschreven in verschillende programmeertalen. SOAP is een standaard die ondersteund wordt door verschillende grote software bedrijven, waaronder IBM, Microsoft en Apache Software Foundation. De berichten die SOAP gebruikt zijn opgebouwd in eXtensible Markup Language (XML) die meestal worden verzonden over het HTTP, maar het kan ook over SMTP, HTTPS en FTP. (4) Naast SOAP is er nog een service die ongeveer dezelfde resultaten biedt, namelijk XINS (XML Interface for Network Services). XINS is een relatief nieuwe aanpak voor webservices. Net zoals bij SOAP zijn alle specificaties XML-gebaseerd. Vanuit de specificaties kan XINS code worden gegenereerd voor server en client en HTML-gebaseerde testformulieren en documentatie. De keuze tussen deze twee services is gevallen op SOAP. Dit omdat SOAP een standaard component is in het Zend Framework en er veel informatie over is te vinden op internet. Ook zijn er al SOAP functies geïmplementeerd in PHP, waarvan op een gemakkelijke manier gebruik van gemaakt kan worden. De rest van dit hoofdstuk gaat over de werking van SOAP en de toepassing ervan in het versiebeheersysteem. Een SOAP-bericht is grofweg onder te verdelen in drie onderdelen: de envelop, header en body. Als we het gaan vergelijken met een brief die je op de post doet, is het eigenlijk gewoon de envelop (SOAP envelop) met daarop een adres (SOAP header) en de brief erin (SOAP body). In de header bevinden zich encodeerregels voor de datatypen die gebruikt worden. De body bestaat uit een representatie van 'remote procedure calls' (uitvoeren van code op een ander platform) en antwoorden, wat het mogelijk maakt om met componenten die gebruik maken van verschillende programmeertalen te communiceren, de eigenlijke kracht is van SOAP. (5) Voorbeeld SOAP code: <soap:Envelope xmlns:soap="http://www.w3.org/2001/12/soap-envelope" soap:encodingStyle="http://www.w3.org/2001/12/soapencoding"> <soap:Body xmlns:m="http://www.example.org/stock"> <m:GetStockPrice> <m:StockName>Example

SOAP is ervoor gemaakt om via het HTTP protocol te werken. Het voordeel hiervan is dat je niet met proxy en firewall problemen te maken krijgt die de connectie kunnen blokkeren. SOAP werkt met aanvragen (request) en antwoorden (responses) (6). De kant die de request uitvoert is de client, de server stuurt vervolgens een response.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010


Om de communicatie tussen webservices te beschrijven, wat nodig is voor het versiebeheersysteem, wordt er gebruik gemaakt van WSDL. WSDL is een soort XML. De input en de output van de methodes die gebruikt worden via SOAP, zijn gedefinieerd in een WSDL document. Dit document wordt opgebouwd door het Zend Framework.

105

In het versiebeheersysteem is communicatie nodig is tussen verschillende webservers om bepaalde functies op afstand uit te voeren. Via SOAP is dit te realiseren. Nu bekend is wat SOAP is en hoe het werkt, kunnen we het toe gaan passen op het versiebeheersysteem. Er moet gedefinieerd worden wat de server en wat de client moet gaan worden. Omdat er requests van beide kanten uitgevoerd gaan worden, zijn de webserver met het versiebeheersysteem en de overige webservers beide afwisselend SOAP-client of SOAP-server. Bij twee verschillende componenten van het systeem wordt SOAP gebruikt. Een voor bij het aanmaken en wijzigen van een CMS-versie van een website en één voor het neerzetten van een nieuwe CMS-versie op servers. Hieronder volgen twee tabellen met de requests en responses die nodig zijn bij de acties: Aanmaken / updaten van een website versiebeheersysteem (1) SOAP request “update website x naar versie y op server z” 

webserver Verwijzingen aanmaken, database updaten, cache opruimen (2)

(4) Aangeven aan de gebruiker wat de status is van de server bij het updaten van de website

 SOAP request “status a website x” (3)

Het versiebeheersysteem stuurt een request naar de server met een website om deze van CMS-versie te veranderen. Met die aanroep worden een aantal parameters meegestuurd die wel bekend zijn bij het versiebeheersysteem maar niet bekend zijn op de server: -

Websitepath: plaats waar de websites te vinden zijn op de server. Websitenaam: naam van de website, één map dieper dan de websitepath. Releasepath: pad waar de release te vinden is, samen met versienummer. Frameworkpath: zelfde als releasepath, maar dan voor het framework. Database versions: de CMS-versies die gebruikt moeten worden om de databasestructuur aan te passen.

De webserver voert een aantal functies uit, nodig om de website te updaten. Telkens wordt de status van de server teruggestuurd naar de webapplicatie, deze kan dan weer aangeven of de update gelukt is. Als de server klaar is kan de website in het versiebeheersysteem weer vrijgegeven worden voor bewerking. Uploaden van een release versiebeheersysteem (1) SOAP request “location zip” 

webserver Downloaden/uitpakken zip (2)

 SOAP request “status x server y” (3)

(4) Status servers weergeven

Het versiebeheersysteem stuurt een request naar elke server om aan te geven dat er een versie klaarstaat. Ook hier worden verschillende parameters meegegeven met gegevens die onbekend zijn op de server: Link naar releasezip locatie: de link naar de locatie van de zip. Releases path: plaats waar de releases op de server te vinden zijn. Releasepath: naam van de map waarin de release neergezet moet worden, een niveau dieper dan de vorige parameter.


-

106

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

Wanneer er een nieuw framework wordt geüpload, worden dezelfde parameters meegegeven, maar dan in plaats van de releasedetails de frameworkdetails. Als de upload opgehaald is door de webserver en uitgepakt, en indien het de juiste mappen bevat (de upload is een zip-archief, zie een aantal kopjes hieronder), stuurt de webserver naar het versiebeheersysteem dat de upload geslaagd is. Tijdens het uploaden van een release geeft de View van de webapplicatie de status van de upload, het controleren en uitpakken van de diverse servers aan. Het versiebeheersysteem kan eventueel het zip-bestand verwijderen op het moment dat alle servers deze opgehaald en uitgepakt hebben. VAN WEBAPPLICATIE NAAR WEBSERVER

Vanuit de webapplicatie naar de webserver zijn er twee momenten waarbij we SOAP gebruiken. De methodes die de opdrachten uitvoeren op de webserver zijn geïmplementeerd in twee configurators die via SOAP aangesproken worden. Hieronder zijn deze twee Configurators gegeven met daarbij hun functies: -

WebsiteConfigurator: o Make Appfile o Database Update o Cache Update

-

ReleaseConfigurator: o Zip ophalen o Zip uitpakken

De WebsiteConfigurator wordt gebruikt tijdens het toevoegen of wijzigen van een website in het versiebeheersysteem. Zie verder Verwijzingen, Database Updaten en Cache Update. De ReleaseConfigurator wordt gebruikt tijdens het toevoegen van een nieuwe release. Zie het bovenstaande voorbeeld en Downloaden uitpakken .zip. VAN WEBSERVER NAAR WEBAPPLICATIE

Andersom wordt de connectie maar op één manier gebruikt: het aangeven hoever de server is met het uitvoeren van de ‘requests’. -

StatusConfigurator: o Change status

De StatusConfigurator wordt gebruikt voor het veranderen van een status. Zie voor de oplossing: veranderen status. PROBLEMEN


Het kan zijn dat er meerdere SOAP aanroepen achter elkaar gedaan worden. Dit komt vooral voor bij het aanpassen van de status. Omdat een SOAP aanroep wat vertraging kan hebben, is het mogelijk dat ze niet op chronologische volgorde doorkomen, en uitgevoerd worden. Hier moet rekening mee gehouden worden, want normaal gesproken werkt de code op de volgorde dat het uitgevoerd wordt. Hier wordt verder op ingegaan onder het kopje ‘veranderen status’.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

107

3.3 VERWIJZINGEN 3.3.1 APP.PHP

Omdat de bestanden van het CMS waar de website aan gekoppeld is niet meer in dezelfde map zullen staan als de website zelf maar op een centrale plek, is het duidelijk dat er een uitbreiding moet komen aan het huidige CMS. Ook moet er bij de website zelf verwezen worden naar de centrale locatie. Op de centrale plek staan verschillende versies van het CMS die worden gebruikt door verschillende websites. Voor de verwijzingen van de website naar de bijbehorende versie van het CMS wordt het bestand ‘app.php’ gecreëerd. Dit bestand wordt elke keer aangemaakt (en dus vervangen als hij al bestaat) wanneer de website van CMS-versie verandert, of een website wordt toegevoegd aan het systeem. De inhoud van app.php kan er als volgt uitzien:

In dit voorbeeld zijn 0_9_7 als CMS-versie en 1_9_7 als framework-versie gebruikt. ‘/domains/_manager/’ is het pad naar de centrale bestanden. Dit pad is afhankelijk van de server waarop de website zich bevindt. App.php wordt in de hoofdmap van de website geplaatst, naast het indexbestand van de website. In dit indexbestand worden de variabelen die ingesteld zijn in app.php opgehaald en gebruikt. Er is nu alleen een probleem. Het versiebeheersysteem heeft geen rechten op andere mappen dan zichzelf, waardoor het toevoegen van het app.php bestand niet direct mogelijk is. De volgende twee oplossingen zijn mogelijk: -

In de serverconfiguratie rechten geven aan het versiebeheersysteem voor bewerkingen in alle mappen. Het plug-in aan het CMS toevoegen die mogelijk maakt om app.php aan te maken, want het CMS heeft deze rechten wel.

De keuze is vooralsnog gevallen op de eerste optie. Deze brengt de minste mutaties met zich mee. Ook de beveiliging van het systeem gaat er niet onder lijden. 3.3.2 BESTANDSLOCATIE

De bestanden die nu gecentraliseerd zijn moeten te vinden zijn door de websites en het CMS. Deze bestanden staan op een andere locatie dan eerst. Met de bestanden bedoelen we onder andere plaatjes en Javascript bestanden. Er moet een oplossing worden gevonden voor hoe deze centrale bestanden gevonden kunnen worden door de website. Deze verwijzingen hebben te maken met het ‘documentpath’ van de website. Er moeten wellicht aliassen aangemaakt worden in de virtual host van een bepaalde website om te verwijzen naar deze centrale bestanden. We hebben nu een aantal oplossingen gevonden, met de volgende voor- en nadelen.


-

108

In de virtualhost van de betreffende website aliassen aanmaken voor de nieuwe gecentraliseerde mappen. Hierbij wordt het versienummer telkens aangepast wanneer de CMS-versie van de desbetreffende website verandert. o Voordeel: in de bron van de website is niet te achterhalen welk versienummer er draait. o Nadeel: het virtualhost-bestand moet steeds aangepast worden, dit is niet wat je wil, want elke keer moet dan de server opnieuw opgestart worden. Ook zijn dit bewerkingen op serverconfiguratie niveau, wat niet wenselijk is.

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

-

In de virtualhost alleen verwijzen naar de map waar alle versies instaan. Dan kan er in de code van de website verwezen worden naar het versienummer in die map met releases. Dit kan natuurlijk met een variabele voor elke mapverwijzing. o Voordeel: virtualhost wordt uitgebreid met maar één wijziging. Dit hoeft alleen maar te gebeuren wanneer de website wordt toegevoegd, wat nu ook al het geval is. o Nadeel: in de html-code van een pagina zijn de versienummers van het CMS te vinden, als deze veranderd worden kunnen ook andere versies bezocht worden.

Deze twee opties zijn eigenlijk beide niet wenselijk, omdat de nadelen te zwaar wegen. Er moet een combinatie gezocht worden die wel de voordelen van beide heeft, maar niet de nadelen. Hiervoor zijn we tot de onderstaande oplossing gekomen. Om deze duidelijk te maken, illustreren we de werking aan de hand van een voorbeeld: Stel, de volgende link wordt aangeroepen: www.domein.nl/central/javascript/script.js. 1. 2. 3.

.htaccess ziet de aanroep /central, en verwijst dit door naar central.php met variabele ‘javascript/script.js’. central.php veranderd de verwijzing in ‘/app/%versienummercms%/html/javascript/script.js’ de ‘/app’ verwijzing verwijst naar de centrale map. Door wat erachter staat weet de browser waar het bepaalde bestand te vinden is.

Voordelen hiervan zijn: -

De bezoeker van de website ziet geen verwijzing naar een versienummer, want deze verwijzing gebeurd onderwater. Er hoeft bij geen enkele update een verandering gedaan te worden op server niveau, wat een eis is van deze webapplicatie.

Om later nog te weten hoe het geheel werkt, en om de technische uitwerking duidelijk te maken hebben we de oplossing verder uitgewerkt in technische details (stapgewijs opgezet): -

-

-

In het .htaccess bestand van de website de verwijzing ‘central’ aanmaken naar een bepaald bestand. (Het .htaccess bestand zorgt voor url verwijzingen naar bepaalde bestanden, wat het mogelijk maakt om naar andere mappen te verwijzen. Dit is een optie die nodig is om de verwijzing naar het centrale CMS te maken.) In de virtualhost (VHOST) van elke website een verwijzing (alias) aanmaken naar de centrale mappen, dus niet naar een map met een versie, maar naar de hoofdmap. Dan hoeft alleen het VHOST bestand aangepast te worden wanneer een website wordt aangemaakt, wat nu ook al het geval is. Deze verwijzing houdt in dat als er /app achter de url getypt wordt, hij verwijst naar die centrale hoofdmap. Door in het bestandje central.php (die aangeroepen wordt door .htaccess) aan te geven welke versie er gebruikt wordt, kan door middel van de /app verwijzing in de VHOST naar de goede map worden verwezen. In central.php wordt gebruik gemaakt van app.php (zie onderdeel 3.1) zodat bekend is in welke mappen er gezocht moet worden.

Wel treedt er nog een probleem op wanneer deze oplossing ingevoerd wordt. De websites hebben namelijk standaard geen rechten op de centrale CMS-mappen. Dit is weer op te lossen door de rechten van de website uit te breiden naar de hoofdmap van de centraliseerde CMS-versies. Dat wordt gedaan door in de virtualhost van elke website de open_basedir uit te breiden met het pad naar de plaats waar de centrale CMS-versies staan.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010


We hebben deze oplossing besproken met de begeleider binnen het bedrijf en hij keurde deze goed.

109

3.4 ZIP-ARCHIEF DOWNLOADEN EN UITPAKKEN Om de bestanden van een CMS-release op een server te krijgen moeten deze in een zip-bestand gearchiveerd staan zodat ze als één bestand geupload kunnen worden via het versiebeheersysteem. Tijdens het uploaden van een nieuwe release selecteert de beheerder het bestand dat de CMS bestanden bevat. Dit bestand wordt vervolgend geupload naar de server waar de webapplicatie op draait en klaargezet voor de overige webservers waar de upload naar toe moet. Twee opties zijn overwogen voor de overdracht van het zip-bestand: -

De server krijgt een link van waar het zip-bestand is geupload op de hoofdserver, zodat hij via deze link het zip-bestand kan downloaden. De server krijgt via SOAP het zip-bestand door en gaat daarmee aan het werk.

De tweede optie is een hele klus, aangezien je niet zomaar een heel zip-bestand kan versturen via SOAP. Deze moet dan helemaal gecodeerd worden naar een XML-gerelateerde vorm en aan de kant van de webservers weer gedecodeerd worden op het originele zip-bestand terug te krijgen. De eerste oplossing is daarom veel praktischer. Doordat enkel de link wordt verstuurd wordt er veel minder data via SOAP verstuurd. Het versiebeheersysteem verstuurt de link van de upload naar deze overige servers, zodat deze het CMS archiefbestand kunnen downloaden. De Configurators van de webservers controleren eerst nogmaals de structuur van de inhoud van de ZIP en pakken vervolgens het archiefbestand uit waarna ze de release in een map met het bijbehorende versienummer als mapnaam plaatsen. De nieuwe release is nu geïnstalleerd. De functies die voor het downloaden en uitpakken worden gebruikt, zijn geïmplementeerd in PHP zelf. Daarom is het slechts een kwestie van op de goede manier deze functies gebruiken en de goede mappen aangeven. STRUCTUUR VAN DE VERPLICHTE INHOUD VAN HET ZIP-ARCHIEF

/application /model /view /controller /html /admin /libraries /site /? /? /sql* /upgrade.sql /downgrade.sql


* niet verplicht

110

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.5 DATABASE MUTATIES Bij het toevoegen van een nieuwe versie van het CMS kan het voorkomen dat de database is veranderd. Het kan zijn dat er extra kolommen bijkomen in bestaande tabellen, of er zijn nieuwe tabellen toegevoegd. Er wordt gebruik gemaakt van een MySQL database. Bij het aanmaken van een website wordt er een standaard database ingeladen. Bij elke nieuwe toevoeging van een CMS-release moeten de veranderingen ten opzichte van deze standaard database aanwezig zijn. Bij elke upload wordt binnen de zip in een sql-map, die ook in elke releasemap wordt uitgepakt, geupload. In die sqlmap zitten .sql bestanden met daarin alle mutaties ten opzichte van de vorige versie van het CMS. Hierbij wordt aangenomen dat iedere versie die aan het systeem wordt toegevoegd een opvolger is van de versie ervoor. Het zip-bestand dat geüpload wordt bevat de map /sql. In deze map komen twee bestanden: upgrade.sql en downgrade.sql. Wanneer een website naar een nieuwere versie van het CMS wordt gebracht, moet elk upgrade.sql bestand aangeroepen worden vanaf de eerstvolgende CMS-versie ten opzichte van de huidige tot en met de CMS-versie die geselecteerd is. Wanneer een website gekoppeld wordt aan een oudere CMS-versie, dan wordt downgrade.sql aangeroepen. Ook dan moet downgrade.sql vanaf de eerst vorige versie tot aan de CMS-versie waarnaar hij gedowngraded wordt aangeroepen worden. Wanneer er een CMS-release uit het systeem wordt verwijderd, moeten deze bestanden blijven bestaan. Dit is nodig, omdat het up- of downgrade stappenproces anders updates mist van die bewuste release.


Een ander idee dat bestond was om bij elke versie van het CMS alle mutaties ten opzichte van de standaard database toe te voegen. Het probleem daarbij is dat het systeem niet weet wat de wijzigingen zijn ten opzichte van de vorige versie wanneer een website naar een andere versie wordt geup- of downgraded. Wanneer deze wijzigingen niet bekend zijn, moet er telkens eerst naar de standaard versie van de database gegaan worden en daarna de updates uitvoeren van de geselecteerde CMS-versie. Dit kost veel meer performance dan de uitwerking die eerder genoemd is.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

111

3.6 VERANDEREN STATUS Om als gebruiker een goed overzicht te hebben van wat de servers aan het doen zijn, is het nodig dat de servers dat aangeven. Na elke actie die een server uitvoert wordt er een statuswijziging naar de webapplicatie teruggestuurd (via een SOAP bericht), die op zijn beurt deze statuswijzigingen kenbaar maakt aan de gebruiker. Na overleg met de begeleider van het bedrijf hebben we besloten dat dit onderwerp ook belangrijk is in het versiebeheersysteem. Voor elke server moet er te zien zijn wat zijn status is: Bij het toevoegen van een release: • • • • •

uploaden van pc naar hoofdserver (alleen op hoofdserver) connectie maken met hoofdserver downloaden van hoofdserver controleren uitpakken

Bij het toevoegen van een website / veranderen van CMS-versie van website: • • •

app.php aanmaken database aanpassingen cache opbouwen

Deze statussen kunnen verschillende waardes hebben: 1. 2. 3. 4.

Niet bekend Bezig Voltooid Mislukt


Een server geeft aan of de acties die uitgevoerd moeten worden goed zijn verlopen of niet. Hieronder worden twee mogelijke oplossingen uitgelegd en vergeleken:

112

1.

Uitbreiden van de Server-tabel in de database met een status veld. In dit veld is een string te vinden met getallen. Elke status heeft zijn eigen getal binnen de string, de waarde ervan staat voor de waarde e e van de status. Beschouw bijvoorbeeld de string “01231”. Hierbij heeft de 1 status de waarde 0, de 2 e status de waarde 1, de 3 status de waarde 2, enz. Om de verschillende statussen aan te geven is ook een tabel aangemaakt die voor elk getal een statusbericht definieert. Voordeel: weinig mutaties in de software, het is een kwestie van uitlezen van de string in de database en deze linken aan de goede statussen. Nadeel: hierbij komt het probleem naar voren dat SOAP zijn berichten niet chronologisch stuurt. Als er een character in de string veranderd moet worden moet deze eerst uitgelezen worden. Dit kan langer duren waardoor de volgende statuswijziging ook nog de oude string gebruikt. Hierdoor wordt één van de twee wijzigingen niet doorgevoerd.

2.

Database uitbreiden met een extra tabel, die linkt elke status van een server aan elke server, en de daar bijbehorende statuswaarde. Om de verschillende statussen aan te geven is ook hierbij een tabel aangemaakt die voor elk getal een statusbericht definieert. De tabel krijgt als inhoud het aantal servers maal het aantal statussen. Door deze verwijzingen uit te lezen kan er aan de gebruiker getoond worden wat er in de database gebeurd en wat de status is van een server. De voordelen en nadelen hiervan zijn eigenlijk precies het tegenovergestelde van optie één:

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

-

-

Voordeel: de niet-chronologische manier van doorsturen maakt hierbij niet uit. Elke keer wordt er één entry in de database veranderd en het maakt niet uit in welke volgorde dit gebeurd. Nadeel: er moet relatief veel aangepast worden aan de software, er moeten links gelegd worden tussen de nieuwe tabellen en de servers moeten op een andere manier uitgelezen worden.


De keuze hierbij is gevallen op de tweede optie. Hierbij is het voordeel groter dan het nadeel. De mutaties in de software hebben verder geen invloed op het juist functioneren ervan. De eerste optie heeft dit wel, omdat statussen door de niet-chronologische manier van doorsturen van soap berichten ervoor kan zorgen dat statussen onjuist worden opgeslagen en weergegeven.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

113

BIBLIOGRAFIE 1. Zend Contact. Zend The PHP Factory. [Online] 2010. [Cited: 5 19, 2010.] http://www.zend.com/en/company/contact-us/. 2. About. Zend Framework. [Online] Zend, 2010. [Cited: Mei 7, 2010.] http://framework.zend.com/about/overview. 3. Zend Framework Manual. Zend Framework. [Online] 2010. [Cited: 5 6, 2010.] http://zendframework.com/manual/en/introduction.overview.html. 4. SOAP. Wikipedia. [Online] Wikipedia, 2010. [Cited: Mei 7, 2010.] http://nl.wikipedia.org/wiki/SOAP. 5. W3 SOAP. SOAP Version 1.2. [Online] W3, 2010. [Cited: Mei 7, 2010.] http://www.w3.org/TR/2007/RECsoap12-part1-20070427/.


6. SOAP tutorial. w3schools. [Online] [Citaat van: 3 5 2010.] http://www.w3schools.com/soap/default.asp.

114

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

K Implementatieplan 1. INLEIDING Het MoSCoW is opgebouwd uit de functionele requirements welke zijn ingedeeld op prioriteit. Daarbij worden de ‘Must Haves’ sowieso geïmplementeerd. De andere eisen, dus eigenlijk wensen, worden ook per onderdeel op prioriteit gerangschikt. Hierbij wordt rekening gehouden met de programmatische afhankelijkheden. Deze MoSCoW indeling is gebruikt om het implementatieplan op te stellen. Het implementatieplan bevat tevens een schatting van de benodigde manuren per onderdeel. Hierna wordt er per onderdeel aangegeven waarop deze getest dient te worden en hoe. Als laatst wordt er een overzicht gegeven van de planning.

2. MOSCOW 2.1 MUST HAVE -

-

Niet geauthentificeerde gebruikers mogen geen toegang tot het systeem kunnen krijgen. De webapplicatie dient overal waar een internetverbinding ter beschikking is gebruikt te kunnen worden. Een overzicht tonen van alle websites waarbij: o De versie van het CMS zichtbaar is o De versie van het Zend Framework zichtbaar is De websites vanuit het overzicht op gemakkelijke wijze naar een hogere versie upgraden of naar een lagere versie downgraden. Nieuwe releases van het CMS uploaden, met daarbij eventueel een nieuwe versie van het Framework, naar alle servers. Nieuwe websites toevoegen aan het systeem. Bestaande websites verwijderen uit het systeem.

2.2 SHOULD HAVE -

Bij alle of specifieke websites berichten of nieuwsmeldingen binnen het CMS plaatsen die informatie geven aan de klanten. Meer structuur aanbrengen in websites overzicht in plaats van één grote lijst. Zend versie los kunnen uploaden van een CMS versie. Dit komt voor als er een bug in Zend zit en er nog geen nieuwe versie uit is van het CMS.

2.3 COULD HAVE -

Filterfunctie (zoekveld) in het websites overzicht om sneller websites te vinden Meerdere websites tegelijk naar een bepaalde versie brengen Site verplaatsen tussen verschillende servers

2.4 WOULD HAVE Overzicht servers en de mogelijkheid tot het toevoegen en verwijderen van servers Automatische versie synchronisatie van de releases tussen de servers VERSIE BEHEER SYSTEEM

-

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

115

3. IMPLEMENTATIE PLAN Dit plan is gebaseerd op het MoSCoW. De verschillende functionaliteiten zijn opgedeeld in milestones. Hierbij wordt aangegeven wat geïmplementeerd moet worden per onderdeel en hoeveel dagen dit ongeveer kost. De volgende indeling is gebruikt: -

Must Haves: Milestones 1, 2 en 3 Should Haves: Milestones 4 en 5 Could Haves: Milestones 6 en 7 Would Haves: Niet opgenomen in planning

3.1 MILESTONE 1: VIEW/USER INTERFACE Doel: Als eerste moet de software opgezet worden. De models, views en controllers moeten neergezet worden. Ook het Zend Framework, wat we zelf ook gebruiken voor het versiecontrolesysteem, moet klaar worden gezet. De overzichten van de servers, websites en releases moeten geïmplementeerd zijn en daarbij de schermen van toevoegen en bewerken van websites. Ook moet de loginfunctie werken. Te implementeren: -

Opzetten Framework (1 d) Database opzetten (1/4 d) Login scherm en functie (1 d) Overzichten (2 d) Testen (4 d)*

3.2 MILESTONE 2: ONLINE SERVERS KLAARZETTEN Doel: De servers moeten anders ingedeeld worden. De CMS versies achter de websites moeten weggehaald worden en de configuratiebestanden van de websites aangepast worden. Te implementeren: -

Ruimte maken voor CMS’en en verwijzen naar die ruimtes op de server s (3 d) Testen (2 d)*

3.3 MILESTONE 3: CONNECTIE MAKEN, UPLOADEN / UP-DOWNGRADEN Doel: Dit is de laatste milestone voor de ‘must haves’. De connectie tussen de servers en de client worden opgezeten en kunnen gebruikt worden. Sites en releases kunnen geupload worden naar alle servers en ook weer verwijderd worden van alle servers.


Te implementeren:

116

-

Connecties (7 d) Uploaden naar servers (4 d) Bestanden uitpakken en neerzetten op server (2 d) Database mutaties per versie (7 d) Verwijderen van releases en websites (3 d) Testen (6 d)*

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

3.4 MILESTONE 4: EXTRA FUNCTIONALITEITEN, GEBRUIKSVRIENDELIJKER Doel: Er moet een centraal kanaal komen om nieuwsberichten op te plaatsen om zo de klanten informatie te geven over de gang van zaken, of de klanten te informeren over aankomend onderhoud aan de servers. Ook kan gelijk meegenomen worden dat websites in de overzichten gesorteerd kunnen worden op verschillende eigenschappen. Te implementeren: -

Ontwerpen (1 d) Database uitbreiden (1/4 d) Controllers uitbreiden (2 d) UI uitbreiden (2 d) CMS uitbreiden (3 d) Testen (3 d)*

3.5 MILESTONE 5: ZEND VERSIE LOS TE UPDATEN Doel: De versies van het Zend Framework zijn netzoals de versies van de releases te beheren in een bepaald overzicht. Ook zijn deze toe te voegen en te verwijderen. Bij een release is het dan mogelijk om een Framework dat via dit is geupload aan zich vast te maken. Te implementeren: -

Ontwerpen (1 d) Controllers uitbreiden (2 d) UI uitbreiden (2 d) Testen (3 d)*

3.6 MILESTONE 6: ZOEKFUNCTIE INBOUWEN Doel: De zoekfunctie toevoegen voor het zoeken van websites. Dit heeft te maken met sommige activiteiten in milestone 4. Te implementeren: Ontwerpen (1/2 d) Controllers, models uitbreiden (1 d) UI uitbreiden (1 d) Testen (1 d)*


-

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

117

3.7 MILESTONE 7: FUNCTIONALITEITEN OPTIMALISEREN Doel: Hier worden meerdere onderdelen tegelijk gedaan wat allemaal valt onder het optimaliseren van de functionaliteiten. Deze functies zijn namelijk al mogelijk in het systeem maar het kost meer klikken en meer tijd om deze uit te voeren. Daarbij hebben we over het verplaatsen van een site van server naar server (kan nu door verwijderen en dan weer toevoegen van een website). Door dit te laten werken door een connectie tussen de servers kan dit sneller en is het niet afhankelijk van de upload van de verbinding waar de website vandaan geupload wordt. Ook moet het mogelijk zijn om meerdere sites tegelijk aan te klikken en te updaten. Dit is als mogelijk door elke site apart te updaten, maar door ze alleen maar te selecteren en één maal de versie aan te klikken kan dit sneller. Te implementeren: Ontwerpen (2 d) Connectie tussen servers opzetten (3 d) Controllers, models uitbreiden (4 d) UI uitbreiden (2 d) Testen (4 d)*


-

118

12 juli 2010

|

Bachelorproject

|

Elwin Dokter

|

John Ciocoiu

|

Final report

4. PLANNING In de planning wordt beschreven hoeveel dagen we nodig denken te hebben voor het implementeren van de verschillende milestones en de bijbehorende testfuncties. We hebben deze uren als volgt verdeeld over de verschillende milestones, waarbij testen inbegrepen is: Milestone Voorbereiding Milestone 1 Milestone 2 Milestone 3 Milestone 4 Milestone 5 Milestone 6 Milestone 7 Afronding

Tijd (in dagen) 25 9 5 29 12 8 4 15 10

Deadline 7 mei 2010 14 mei 2010 19 mei 2010 11 juni 2010 16 juni 2010 23 juni 2010 25 juni 2010 - ** 2 juli 2010

* Testen wordt tussendoor natuurlijk ook gedaan, maar het echte testwerk na het implementeren wordt hierin neergezet. Ook de bugs die we dan tegenkomen en verbeteren staan in deze tijd.


** Wij plannen deze niet in, omdat wij niet verwachten dat hier tijd voor over is. Mocht de rest goed en snel verlopen, gaan we deze milestone proberen te halen.

Final report

|

John Ciocoiu

|

Elwin Dokter

|

Bachelorproject

|

12 juli 2010

119

FINAL REPORT. Bachelor project IN3405. (vervangend ST coördinator bachelorproject TU Delft)

Recommend Documents