Deployen, dat doe je zo!

Er zijn 1001 manieren om je site te deployen. Met Novation werkten we een manier van werken uit.

Laten we het eens hebben over ‘deployen’… Voor velen is dit een abstract begrip dat vaak in 1 adem wordt genoemd met andere buzzwords zoals Continuous Integration, Unit testing, enz. Maar wat is deployen nu eigenlijk? En waarvoor dient het? Laten we dat even illustreren met een concreet voorbeeld van onze klant Novation.

Wat is deployen?

Deployen is het klaarmaken van je website of applicatie om gebruikt te worden. Heb je dus een prachtige applicatie gebouwd die werkt op je laptop? Heb je die opgeslagen in een versiecontrole-systeem? En vindt jouw klant alles super? Dan is alles klaar voor ingebruikname! Maar hoe doe je dit precies? Je eerste reflex is wellicht om de bestanden te uploaden naar een server via FTP. Oei nee, FTP is dood, dat weten we ondertussen :-). Uploaden via SFTP dan? Perfect mogelijk en wellicht ook doenbaar, zeker in het begin. Maar als je veel sites online moet zetten of vaak wijzigingen wil aanbrengen, dan wordt dit manuele proces al snel vervelend.

Met deployment automatiseren we het proces om jouw applicatie online te zetten.

Wat is deployen niét?

Deployen wordt vaak genoemd in combinatie met andere buzzwords zoals Continuous Integration, Unit testing, ... Dit is niet volledig onterecht, want deployment is slechts 1 stap in het ontwikkelproces van een applicatie. Er is inderdaad zoveel méér: testing, kwaliteitscontrole, validatie door gebruikers, ... Als alles goed is, heb je voor het volledige proces een strategie uitgewerkt (of wij helpen je daarbij). Maar deployen op zich is belangrijk genoeg om een artikel aan te wijden!

Novation als voorbeeld

Even voorstellen

Even voorstellen…

Novation is een digital agency dat gebeten is door de internetmicrobe en al meer dan 10 jaar ervaring heeft in de sector. Het spreekt vanzelf dat Novation een gestructureerde manier van werken heeft ontwikkeld waarbij alle websites en applicaties in het versiecontrole-systeem Git Git worden opgeslagen. Ook werken zij al met een systeem waarbij elke website een test- en productieversie heeft. De testversie van de site bevat steeds de laatste versie en wordt gebruikt om eventuele wijzigingen aan de klant te tonen.

Onder het motto ‘alles kan beter’ werkten wij samen met Novation een manier uit om dit proces te automatiseren.

Aan de slag met het script Magallanes

De eerste stap is het bouwen van een deployscript. Dat heeft als taak om met 1 commando een lokale versie van de website te kopiëren naar een server. Dit kopiëren gebeurt via SSH. Jaja, met containers is dat allemaal anders, maar dat is voor binnenkort :-)

Wat we hier willen bereiken, is dus het volgende:

Programmeur Jan werkt lokaal op zijn pc en gebruikt Git als versiesysteem. Met een deployscript wil hij met 1 commando de website deployen naar de testserver en de productieserver.

Als deployscript zijn er heel wat mogelijkheden. Capistrano is een van de bekendste. Het is geschreven in Ruby en is heel erg robuust en wijdverspreid.

Voor Novation hebben we niet gekozen voor Capistrano, maar wel voor Magallanes. Het is minder bekend en minder uitgebreid, maar is wel heel eenvoudig in gebruik en perfect geschikt voor de taak. Bovendien is het geschreven in PHP waardoor je het heel makkelijk kan uitbreiden en aanpassen.

Hoe werkt Magallanes concreet? In de map van je website maak je een .mage-map met enkele configuratiebestanden:

.
├── config
│   ├── environment
│   │   ├── test.yml
│   │   └── prod.yml
│   └── general.yml
└── logs

In general.yml staat algemene info:

name: 'My fantastic app'
email: peter [at] level27.be
notifications: 'true'
logging: 'true'
maxlogs: '30'
ssh_needs_tty: 'false'

En dan heb je voor elke server waarop je je website wil zetten 1 configuratiebestand:

deployment:
    user: username
    from: ./
    to: /var/web/websitenaam/deploy
    excludes:
        - sites/default/settings.php
    strategy: rsync
releases:
    enabled: true
    max: 10
    symlink: current
    directory: releases
hosts:
    - test.website.be
tasks:
    pre-deploy: null
    on-deploy: null
    post-release:
        - { level27-shared-files: { sharedfile: /sites/default/settings.php } }
        - { level27-shared-files: { sharedfile: /sites/default/files } }
        - { level27-drush: { params: 'cc all', workingdir: /sites/default } }
    post-deploy: null

Hierbij wat meer uitleg hierover:

  • Het vak deployment geeft aan onder welke gebruiker Magallanes mag kopiëren en naar welke locatie. Ook kan je hier enkele excludes meegeven, dat zijn bestanden of mappen die niet gekopieerd hoeven te worden naar de server.
  • Het blok releases bevat de info over hoe de server gestructureerd moet worden. Als je werkt met releases, wordt er een bestandsstructuur opgezet op de server met een symlink naar de laatste en werkende deploy.
  • Bij hosts geef je de namen op van de servers waarnaar je wil deployen. Dit kunnen er ook meerdere zijn (bijvoorbeeld bij een clustered set-up).
  • Tasks zijn erg krachtig en belangrijk. Hiermee kan je op elk gewenst moment een taak uitvoeren. Dit voorbeeld gebruikt de taken om configuratiebestanden te symlinken en drush uit te voeren.

De eigenlijke deploy kan je dan uitvoeren als volgt:

mage deploy to:test

Alle acties die Magallanes doet, worden bijgehouden in logbestanden. Met deze Magallanes-configuratie kan de programmeur voortaan met 1 commando de site deployen naar de locatie naar keuze. Hiervoor heeft de programmeur toegang nodig tot de test- en productieserver.

Ben je benieuwd naar de details? Wil je weten hoe we omgaan met de configuratiebestanden (tip: we steken ze niet in Git)? Contacteer ons even.

Nadien is er nog Jenkins!

Magallanes is allemaal goed en wel, maar we zijn er nog niet. De programmeur moet toegang hebben tot de test- en productieserver en er is nog geen sprake van volledige automatisatie. Enter Jenkins.

In essentie is Jenkins niet meer dan een tool om scripts te starten en de output te verzamelen. Maar het is wél een verdomd uitgebreide tool met enorm veel mogelijkheden.

Dit willen we bereiken:

De belangrijkste wijziging is dat Jenkins de applicatie zal halen van Git en dat de deploy naar de servers gebeurt vanop de Jenkins server. Dit heeft de volgende voordelen:

  • Programmeurs moeten geen toegang meer hebben tot de test- of productieserver.
  • Git kan Jenkins verwittigen dat een nieuwe versie van de code klaarstaat en er dus automatisch gedeployed moet worden.
  • Meerdere programmeurs kunnen werken (en deployen) aan hetzelfde project.
  • De logbestanden van elke deploy worden bewaard in Jenkins. Een stukje uit de Jenkins-configuratie:

En last but not least, zo ziet het eruit in Slack:

Extra mogelijkheden

Jenkins kan meer dan deployen alleen natuurlijk. Staat je deployproces op punt, dan kan je met kleine stapjes telkens meer bereiken. Voorbeelden:

  • Geautomatiseerde tests om je code te valideren
  • Code-analyse zoals ‘PHP Mess detector’ of ‘Copy paste detector’
  • Automatische generatie van assets, minifying, ...

Conclusie

Lijkt dit je wat? Wij staan klaar om je te helpen een eigen deploymentproces op maat te ontwikkelen. Contacteer ons vandaag nog!

Vragen of opmerkingen?

Laat het ons zeker weten via onze chatbox!
We helpen je graag verder.

Deel deze blog via