Sneller online, zonder fouten, zonder downtime

Als je een website of app laat bouwen dan wil je dat dit zo efficiënt mogelijk gebeurt. Dat scheelt tijd, geld en een hoop gedoe. Ik en de andere developers bij acato zijn daarom constant bezig om sneller en efficiënter te werken, zonder dat hierbij wordt ingeleverd op de kwaliteit. Zo schrijven wij tests om automatisch onze functionaliteit te testen en gebruiken wij tools om de site zo snel mogelijk te laden. Wij gebruiken een tool genaamd Deployer. Hiermee gaat het live zetten van een website of app veel sneller en voorkom je downtime. Hoe? Dat ga ik je nu vertellen.

Een website is opgebouwd uit verschillende bestanden, samen vormen deze het geraamte van de website. Deze bestanden staan lokaal (dus op je pc) opgeslagen. Wanneer er aanpassingen worden gedaan aan een website (of als de website volledig vernieuwd wordt), dan wijzig je deze bestanden dus ook lokaal. Heb je dat gedaan dan moet je deze bestanden verplaatsen naar een live-server. Op die manier worden ze zichtbaar op de test- of live-omgeving. Het overzetten van deze lokaal opgeslagen bestanden naar een live-server noemen we een deployment. Wanneer er vaak dingen wijzigen op een website worden er soms wel een aantal deployments per week uitgevoerd. Voor de leken onder ons: content wordt op de server toegevoegd, bijvoorbeeld door middel van een content management systeem (CMS). Het aanpassen van teksten e.d. wordt dus niet via deployments gedaan. Het gaat hier bijvoorbeeld om nieuwe functionaliteiten.

Voor we begonnen met het gebruiken van Deployer moesten we bij een deployment handmatig alle bestanden naar de server verplaatsen. Dat is foutgevoelig, want je vergeet wel eens wat te kopiëren. Daarnaast moeten er vervolgens nog allerlei handelingen gedaan worden, het legen van de cache bijvoorbeeld, en daar gaat tijd in zitten. Bovendien werden deze bestanden verplaatst naar de map die door de live-omgeving gebruikt wordt om de website te tonen. Omdat er van alles gebeurt in deze map gaat dit mis, waardoor er downtime ontstaat. Vervelend natuurlijk, als je altijd bereikbaar wilt zijn voor je klanten.

Tegenwoordig werken wij dus met Deployer en dat heeft ons leven een stuk eenvoudiger gemaakt! Hoe dat dan werkt?

 

1. Lokaal

Allereerst worden er lokaal twee omgevingen geconfigureerd voor de deployment naar de testomgeving (testing) en de live-omgeving (production). Via een unieke sleutel op de computer weet het script dat ik toegang heb tot deze omgevingen en kan ik een beveiligde verbinding maken om de bestandsoverdracht in gang te zetten. Hieronder zie je hoe dat er ongeveer uitziet. Mag je meteen weer vergeten als je geen developer bent:)

Nerd alert!!

server('production', 'prod-sample-acato.nl')
->user('prodsample')
->stage('prod')
->identityFile('~/.ssh/id_dsa.pub', '~/.ssh/id_dsa', '')
->env('deploy_path', '/home/prodsample/sample-acato.nl');

server(‘testing’, ‘test-sample-acato.nl’)
->user(‘testsample’)
->stage(‘test’)
->identityFile(‘~/.ssh/id_dsa.pub’, ‘~/.ssh/id_dsa’, ”)
->env(‘deploy_path’, ‘/home/testsample/sample-acato.nl’);

Willen we deployen naar de testomgeving dan gebruiken we ‘dep deploy test’, voor de live-omgeving gebruiken we ‘dep deploy prod’.

 

Bron afbeelding: deployer.org

2. Op de server

Op de server van de omgeving maken we 3 folders aan, namelijk:

• /current

Hier staat de versie van de site zoals we die live zien. Deze folder refereert naar de laatste release.

• /shared

Hier staan bestanden die nooit vervangen moeten worden zoals afbeeldingen.

• /releases

/release_1
/release_2
/release_3

Wanneer er wijzigingen zijn aangebracht wordt er een nieuwe release aangemaakt. Deze komen in deze map. Hier staan dus oude releases in, maar ook de meest recente.

3. Achter de schermen

Achter de schermen gebeurt vervolgens het volgende:

• Er wordt een nieuwe release aangemaakt op de server. In dit geval: release_4.
• Alle bestanden worden naar deze release overgezet.
• Wanneer alle bestanden zijn overgezet linken we de current folder naar release_4.
• Doordat er pas nadat alle bestanden zijn overgezet een koppeling wordt gemaakt tussen de laatste release en de current folder heb je dus geen last meer van downtime. Je zet de bestanden namelijk niet meer direct in de current folder (waar de live-omgeving zijn gegevens uithaalt).
• Ondanks testen toch iets fout gegaan? Geen probleem. We zorgen gewoon dat de current folder verwijst naar een eerdere stabielere release. In dit geval release_3 dus!

• Voor Terberg hebben we dit toegepast om de deployments naar de testomgeving te vereenvoudigen. We zijn hierdoor van 10 minuten per deployment naar slechts een aantal seconden gegaan.
• We zijn van plan om dit ook toe te passen bij de Buurtboer. Er werken dagelijks gemiddeld 20 mensen tegelijkertijd in de Buurtbase (CRM systeem op maat voor Buurtboer). We doen wekelijks meerdere deployments. Deze doen wij nu ‘s ochtends of na werktijd om ervoor te zorgen dat het systeem overdag blijft functioneren. Deployer kan ons helpen om ook overdag deployments te kunnen doen.

Ja! Deployer werkt out-of-the-box voor elk framework en CMS dat wij gebruiken, zoals WordPress, Concrete5 en Laravel. De komende tijd gaan we dit voor veel meer klanten inzetten. Denk je dat dit voor jou ook interessant kan zijn of wil je meer over Deployer weten? Neem dan gerust contact met ons op.