Continuous Delivery - continued

Sinds mijn vorige blog over Continuous Delivery hebben we nog een aantal grote stappen gemaakt. Single-click deployment naar onze test- en productieserver is een feit. Een katalysator is geweest dat we zijn overgestapt van Subversion naar GIT voor versiebeheer.

Korte terugblik

In het eerste deel van het blog over Continous Delivery wordt uitgelegd wat het precies inhoudt en wordt een groot deel van de terminologie uitgelegd. Het is aan te raden om dat blog eerst te lezen voor een duidelijker beeld. 

Even een korte opfrissing: bij Continuous Delivery ga je uit van het standpunt dat de software die je ontwikkelt op elk moment stabiel genoeg is om online te zetten. Hiervoor gebruik je:

  • Automated Testing, zodat je op elk moment zeker weet dat alle functionaliteit werkt.
  • Continuous Integration, onderverdeeld in versiebeheer en automated builds (waarbij gelijk alle testen worden gedraaid) van de gehele website.
  • Automated Deployment, zodat zonder menselijke tussenkomst de nieuwe versie online gezet kan worden.

Bijna een jaar geleden waren we erg blij met wat we hadden bereikt op het gebied van Continuous Delivery: testdriven werken, automatisch deze testen laten draaien bij een commit in Subversion en wijzigingen automatisch live zetten met Magallanes (hierbij moesten nog een aantal stappen wel handmatig worden opgestart).

Weer een grote stap voorwaarts

We merkten dat het branchen en terugmergen in Subversion steeds vaker problemen gaf (deels ook doordat we zelf ooit hebben gekozen voor 1 grote repository waar alles in staat). Ook misten we een natuurlijke workflow hoe om te gaan met releases, test versies, en bugfixes.

Git

Als vervanger van Subversion kwam natuurlijk direct Git boven. Onze Subversion server stond bij ons op kantoor, maar we wilden nu graag naar een cloud oplossing met automatische backups en zo min mogelijk onderhoud van onze kant. We hebben verschillende tools met verschillende pricing models bekeken. Omdat onze repositories natuurlijk private zijn, hebben we niet gekozen voor de bekendste: Github. Uiteindelijk zijn we uitgekomen bij Bitbucket van Atlassian. Bijkomend voordeel is dat er integraties mogelijk zijn met Jira, dat we ook gebruiken.

Gitflow

Qua workflow kwamen we al snel uit op de Gitflow workflow. Schematisch is dit als volgt weer te geven:

git-workflow-release-cycle-4maintenance

  • De master is altijd identiek aan de versie die op de live server staat.
  • De develop is gelijk aan de versie die op de testserver staat
  • Vanuit de develop branch maak je zogenaamde feature branches waarin je nieuwe features ontwikkelt. Als een feature klaar is, merge je hem naar develop. Hiermee trigger je een automatische build en als die slaagt, wordt de versie op de testserver gezet.
  • Als alle features klaar zijn, maak je een release. Deze gaat naar master, wat weer een automatische build triggert. Als die slaagt, wordt de versie live gezet.
  • Ten slotte zijn er nog zogenaamde hotfixes (kritieke bugfixes op de live omgeving) die je in een branch van de master maakt. Als de hotfix klaar is, wordt deze naar master en develop gezet. Dit triggert weer de automatische builds. Als deze slagen, wordt de hotfix automatisch op de live server en op de testserver toegepast.

Jenkins

We begonnen met het gebruik van Jenkins puur als server waar een automatische build werd gemaakt en daarna de testen werden gedraaid. Daarna moesten we zelf nog met Magallanes aan de slag om de wijzigingen op de testserver of op de live server te zetten. Ook merkten we dat een aantal stappen van het live zetten in Magallanes lastig te doen waren, waardoor er toch nog wat handwerk bij kwam kijken. Niet wenselijk natuurlijk!

Gelukkig kan je in Jenkins veel meer. Een push naar develop of master triggert nog steeds een request naar onze Jenkins server. In een zogenaamde Jenkins file wordt per project gedefinieerd welke stappen moeten worden doorlopen voor en push naar develop of een push naar master. Dit is een zogenaamde pipeline die is onderverdeeld in verschillende stages. Wij hebben de volgende stages:

  1. Checkout (haal het project op uit Git)
  2. Build (zorg dat het hele project inclusief alle dependencies klaar wordt gezet)
  3. Tests (Codeception draait alle testen)
  4. Deploy (zorg dat wijzigingen in de master naar de live server gaan en wijzigingen in develop naar de testserver)

OTAP

Door het volgen van deze workflow hebben we automatisch voor al onze projecten een OTAP straat ingericht. Hierdoor heeft de klant altijd toegang tot een up-to-date testomgeving en kunnen we garanderen dat wijzigingen die naar de live server gaan geen fouten opleveren.

Dependencies

Voorheen stonden de versies van de Webmagiër en modules van derden (jQuery, Yii, PHPUnit, etc.) die we specifiek voor het project gebruikten in één repository. Dit maakte het erg omslachtig om een nieuwe versie ergens van te gaan gebruiken of updates door te voeren. Hiervoor zijn we overgestapt op Composer (voor PHP) en npm (voor JavaScript). Ook aan de front-end kant is hier veel veranderd, lees daarover meer in het blog Package Management.

De Webmagiër is daarbij ook een losse module geworden, zodat het voor onze projecten ook veel makkelijker wordt om een specifieke release van de Webmagiër te gebruiken en ervoor te zorgen dat we eenvoudig elk kwartaal een nieuwe versie van de Webmagiër kunnen uitrollen bij al onze projecten.

En nu?

We zijn nu erg tevreden over onze infrastructuur op het gebied van Continuous Delivery. Er gaat minder fout bij een livegang. We hebben ook meer tijd over om ons met development bezig te houden in plaats van code live te zetten, tests te draaien, etc. Die tijd zetten de programmeurs in om de technieken, modellen, codestyle, best practices en design patterns die gebruikt worden voor het maken van online applicaties te verbeteren. Maar daar over later meer in een ander blog :)

Geschreven door Job Kelderman

Hoofd ontwikkeling / eigenaar

Blijf up-to-date en ontvang updates in je mailbox

Lees ook deze interessante blogs

Kiezen van een webdesignbureau: waar moet je op letten?

Je wilt een nieuwe website en bent op zoek naar een goed webdesignbureau. In Nederland zijn er zeker honderd webdesignbureaus en een groot aantal ZZP’ers die websites maken. Allemaal pretenderen ze goed te zijn. Maar hoe scheid je het kaf van het koren en kies je een bureau die bij jouw organisatie past? Wij zetten 14 punten op een rij waar op je moet letten bij de keuze van een webdesignbureau.

Watervalmethode vs Scrum

Scrum is geliefd bij veel software-ontwikkelaars. Zo ook bij ons; wij houden echt van scrummen. Maar soms – heel soms – werken wij nog volgens de watervalmethode. Dit doen wij vooral bij projecten waarbij de projectleider aan de klantzijde geen beslissingsbevoegdheid heeft en elk stap aan een leidinggevende, het management of een stuurgroep moet worden verantwoord. Soms is de watervalmethode ook meer geschikt voor website waarop content centraal staat en al in een vroeg stadium...

Totaalpakket: grondig renoveren website, inclusief teksten en beelden

Het besluit is genomen: je wilt een nieuwe website voor je bedrijf. Dit besluit is meteen de startpunt van een reeks volgende beslissingen. Wat te doen met de content – foto’s en teksten – op de huidige site? Passen deze nog bij de nieuwe weg die je in wilt slaan? Of doen deze juist afbreuk aan de nieuwe website en de communicatieboodschap die je wilt uitdragen? En wat als nieuwe teksten nodig zijn: zelf schrijven of iemand anders? En zo ja, wie dan? Oftewel: keuzes,...