Als je je een Venn diagram voorstelt, zouden Kinsta’s testomgevingen samenkomen met zowel het ontwikkelen voor WordPress als de door jou gekozen DevOps levenscyclus. Ze kunnen deel uitmaken van je workflow vanaf de eerste planning tot aan de operationele fase. Denk hierbij aan lokaal werken met WordPress, het gebruik van versiebeheer en bijna elke andere taak die je hebt tijdens een cyclus.
In dit artikel gaan we kijken naar het ontwikkelen van sites met de testomgevingen van Kinsta. Doorheen dit artikel linken we dit aan een typische DevOps levenscyclus. Er is veel om te bespreken, dus laten we beginnen met waarom we denken dat je de testomgevingen van Kinsta zou moeten gebruiken.
De voordelen van het gebruik van Kinsta’s testomgevingen
Kinsta’s testomgevingen geven je veelzijdigheid en flexibiliteit als het gaat om het ontwikkelen en testen van websites. Met deze omgevingen kun je bouwen in een omgeving die je live omgeving weerspiegelt. Aangezien je live server ook op Kinsta staat, is het een betrouwbare en nauwkeurige testomgeving om vanuit te werken.
Natuurlijk kun je testomgevingen maken, beheren, klonen en verwijderen via het MyKinsta dashboard:
Als je meer flexibiliteit nodig hebt, krijg je met de Premium testomgeving add-on vijf extra omgevingen. Daarnaast profiteer je van onze robuuste infrastructuur, waaronder Google’s Premium Tier Network en Cloudflare integratie.
Zoals je zou verwachten, komt dit ook met meer kracht onder de motorkap. Afhankelijk van je pakket krijg je tot 12 CPU’s en 8GB geheugen, een aangepast aantal PHP workers ten opzichte van je live site en de optie om Kinsta CDN in te schakelen voor betere prestaties. Het is een opstelling die geschikt is voor een reeks taken, zoals A/B-testen, compatibiliteitscontroles van plugins, resource-intensieve tests en nog veel meer.
Voor lokale ontwikkeling is DevKinsta de perfecte aanvulling. Zodra je uit de eerste fasen bent, kun je je site rechtstreeks naar de testomgevingen van Kinsta pushen.
Over het geheel genomen kun je creëren, bouwen, ontwerpen, testen en debuggen binnen het ecosysteem van Kinsta. Bovendien is het ook geschikt voor je DevOps levenscyclus. We zullen er hieronder dieper op ingaan. Maar laten we eerst wat extra informatie geven over de testomgevingen van Kinsta.
Enkele bijkomstigheden over Kinsta’s testomgevingen
De testomgevingen van Kinsta zijn uitstekend als het gaat om het testen van een site op een live – zij het niet-productie – server. Er zijn echter enkele verschillen tussen testomgevingen en live omgevingen op Kinsta waar je je bewust van moet zijn:
- Ten eerste schakelen we standaard zowel full page caching als OPcache uit. Je kunt dit inschakelen als je wilt, maar zonder zul je waarschijnlijk hogere laadtijden van pagina’s zien.
- Ook is site-indexering uitgeschakeld binnen WordPress. Hoewel je dit opnieuw kunt inschakelen als dat nodig is, is er één aspect dat je niet kunt uitschakelen en dat zijn onze tijdelijke headers die URL indexering voorkomen.
- Cron jobs worden ook niet uitgevoerd in testomgevingen, hoewel ze nog steeds ‘op hun plaats’ zijn Dit betekent dat je er wijzigingen in kunt aanbrengen, die de cron jobs op je live site zullen vervangen zodra je ze live zet. In testomgevingen worden ze echter niet uitgevoerd.
- Houd er ook rekening mee dat je WordPress inloggegevens hetzelfde zijn voor je testomgevingen site als voor je live site.
Er is nog één aspect waar we kort op in willen gaan voordat we verder gaan met de workflow: hoe plugins samenwerken met testomgevingen.
Plugins gebruiken in Kinsta’s testomgevingen
Kinsta verbiedt een aantal plugins om te installeren in (live) WordPress vanwege de veiligheid en prestaties. Als het echter om testomgevingen gaat, zul je ook een aantal plugins van je site willen uitschakelen.
Er zijn drie situaties waarin je dit wilt overwegen:
- Als je plugin-licentie is gekoppeld aan je domeinnaam, werkt deze mogelijk niet in je testomgeving.
- Plugins zoals Jetpack schakelen automatisch over naar een testomgevingsmodus. Je ziet misschien geen verschil, hoewel geen van de gegevens die je verwerkt naar WordPress.com gaan. Je kunt Jetpack ook niet uitschakelen op testomgevingen.
- Sommige plugins maken verbinding en posten naar sociale media, zoals CoSchedule. In deze gevallen raden we je aan om ze uit te schakelen totdat je ze live zet. Dit komt omdat ze URL’s kunnen inplannen en posten vanuit je testomgeving.
We hebben meer informatie hierover (en nog veel meer) in onze documentatie. Het is essentieel leesvoer als je de testomgevingen van Kinsta wilt gebruiken en toch de effecten met betrekking tot je plugins en thema’s wilt minimaliseren.
Een typische ontwikkelworkflow met behulp van Kinsta’s testomgevingen
Je hebt waarschijnlijk al een typische workflow voor ontwikkeling. Met behulp van Kinsta’s testomgevingen kun je je DevOps levenscyclus voor Continuous Integration/Continuous Deployment (CI/CD) naadloos integreren.
In feite begint het proces met een lokale omgeving voor ontwikkeling. Het installatieproces neemt geen tijd in beslag en zorgt ook voor het bouwen van een MariaDB database.
DevKinsta is ook ideaal voor headless WordPress projecten. Hoewel WordPress hier verwant is aan een content Application Programming Interface (API), kun je de front-end nog steeds bouwen met een JavaScript framework zoals React of Vue.js.
Wanneer het tijd is om naar testomgevingen te gaan, zal DevKinsta de backend op de gebruikelijke manier afhandelen. Voor de front-end kun je deployen naar Kinsta’s Statische Site Hosting of naar onze Applicatie Hosting.
Dit is hoe de rest van een typische workflow eruit zou kunnen zien:
- Pushen naar de testomgeving. Zodra je klaar bent met je lokale ontwikkeling en voorbereidende testen, wil je pushen naar je testomgeving. Deze productie-replica zorgt ervoor dat je testresultaten vergelijkbaar zijn met die van je live site. Het is een cruciale stap in je CI/CD pipeline, omdat je geautomatiseerd testen en kwaliteitsborging kunt implementeren voordat je gaat deployen.
- Testen en debuggen. Je zult meer tests willen uitvoeren binnen testomgevingen, zoals prestatietests, beveiligingsscans en gebruikersacceptatietests (UAT). Omdat Kinsta de testomgevingen en live omgevingen isoleert, hebben deze tests geen invloed op de live site. Met behulp van Kinsta’s logging en Application Performance Monitoring (APM) tools kun je hier ook eventuele problemen opsporen.
- Continue integratie/deployment. Na de testfase en de laatste goedkeuringen moet je alle testomgevingen wijzigingen integreren in de live omgeving. Je kunt aspecten van dit proces automatiseren volgens je CD/CI workflow. Zo blijft je centrale versiebeheer up-to-date en kun je code met minimale input uitrollen naar productie.
- Monitoring en feedback. Na de uitrol is het cruciaal om eventuele problemen te identificeren en te verhelpen met behulp van een continue feedback- en monitoringsloop. Kinsta’s APM kan je helpen om alle uitdagingen na de deployment aan te pakken. Van hieruit kun je voortdurend verbeteringen doorvoeren met de inzichten en gegevens die je verzamelt.
Over het geheel genomen bieden Kinsta’s testomgevingen (en DevKinsta) een robuuste infrastructuur om je ontwikkelingsworkflow te helpen stroomlijnen. Het ondersteunt zelfs headless WordPress toepassingen. In de volgende paragraaf bekijken we hoe je je bestaande DevOps vaardigheden kunt gebruiken naast onze testomgevingen.
DevOps technieken toepassen bij het gebruik van Kinsta’s testomgevingen
Het toepassen van DevOps technieken binnen Kinsta’s testomgevingen kan de samenwerking aanzienlijk verbeteren en de ontwikkelingslevenscyclus stroomlijnen. Dit geldt vooral voor cross-functionele teams, omdat testomgevingen de productie zo goed mogelijk nabootst.
Hierdoor kunnen developers, Quality Assurance (QA) teams en anderen synchroon samenwerken tijdens de bouw-, test- en deploymentfase. Omdat dit in een gecontroleerde en geïsoleerde omgeving gebeurt, helpt het om eventuele conflicten te minimaliseren. Het zorgt er ook voor dat je eventuele problemen vroeg in het ontwikkelproces kunt identificeren en aanpakken.
In de kern probeert DevOps de barrières tussen typische en traditionele ‘silo’ teams, ontwikkeling en uitvoering weg te nemen. De praktijken die je implementeert zorgen voor een boost in samenwerking, automatisering en integratie.
Bovendien zijn de juiste DevOps practices gericht op het verbeteren van de snelheid, efficiëntie en veiligheid van je ontwikkeling en implementatie.
Je kunt dit in actie zien in de verschillende stadia van de DevOps levenscyclus. Er zijn er ongeveer vijf tot zeven, afhankelijk van je project en team:
- Ontwikkeling. Deze fase bevat planning en codering, samen met het kiezen van je testomgeving. Je zult hier code schrijven, testen en versiebeheer uitvoeren (waarschijnlijk met Git) voordat je naar de volgende fase gaat.
- Integratie. Hier voeg je wijzigingen in de code samen in een centrale repository en zorg je ervoor dat deze nieuwe toevoegingen je site niet kapot maken.
- Testen. Vervolgens automatiseer je tests die in de testomgeving worden uitgevoerd. Dit geeft je een tweede laag om bugvrije code van hoge kwaliteit te garanderen.
- Deployment. Nadat je je testomgevingen code hebt gevalideerd, kun je de deployment naar productie automatiseren. Dit zorgt ervoor dat je site altijd met de laatste versie draait.
- Monitoring. Na de deployment wil je de prestaties van je site monitoren. Dit is waar een robuust waarschuwingssysteem en proces waardevol zijn. De gegevens die je hier verzamelt zullen je ook helpen om in de toekomst te leveren.
- Feedback. Dit is een fase na de deployment waarin je inzichten en gegevens verzamelt van gebruikers – in dit geval bezoekers van de site. Je gebruikt de feedback uit deze fase om verbeterpunten te identificeren voor de volgende ontwikkelingscyclus.
- Operations. Tijdens deze fase heb je waarschijnlijk enige overlap met een nieuwe cyclus. Hier minimaliseer je uitval, werk je aan het verbeteren van de uptime en optimaliseer je serverconfiguraties.
Afhankelijk van het aantal stappen dat je in je eigen levenscyclus hebt, zullen sommige in een andere volgorde staan. De integratiefase kan bijvoorbeeld deel uitmaken van de ontwikkel- of testfase. Bovendien kan het zijn dat je sommige van deze stappen niet hebt, zoals een speciale feedback- of operations fase.
Kinsta’s testomgevingen zijn een integraal onderdeel van de ontwikkelingsfase, omdat ze een veilige, geïsoleerde ruimte bieden voor coderen, testen en QA pre-deployment. Het integreren van deze omgevingen in de DevOps levenscyclus kan de samenwerking bevorderen, de levertijden verbeteren en de kwaliteit van de deliverables verhogen.
Vervolgens laten we je zien hoe je ze kunt maken via het MyKinsta dashboard.
Hoe je een testomgeving opzet op Kinsta
Niet alle hosts bieden deze functionaliteit, maar Kinsta’s testomgevingen zijn beschikbaar voor elk pakket dat we aanbieden. Het hele proces neemt een paar minuten en minimale kliks in beslag.
Bovendien hoeven we hier niet elke stap te behandelen, omdat je die kunt vinden in onze kennisbank. In het kort kun je echter beginnen met het instellen via je MyKinsta dashboard:
Je eerste beslissing zal zijn om te kiezen voor een standaard of premium testomgeving. Ons advies is om te begrijpen hoe belangrijk testomgevingen zal zijn voor je live site. Zo zal een standaardomgeving waarschijnlijk geschikt voor je zijn als je alleen elementen buiten de productieomgeving hoeft te testen.
Daarentegen zal een premium omgeving nodig zijn als je hetzelfde niveau en dezelfde omvang van resources nodig hebt als je live site. Er zijn ook andere voordelen, zoals de mogelijkheid om meerdere testomgevingen op te zetten. Maar voor sites die veel resources vereisen (zoals e-commerce winkels), moet je de resources van je live site evenaren.
In de meeste gevallen zul je waarschijnlijk je bestaande site willen klonen, wat een van de opties is die je hebt na het kiezen van je type testomgevingenomgeving.
Vanuit DevKinsta kun je hier een lege omgeving opzetten. Er is een knop binnen de instellingen van je site in DevKinsta om naar testomgevingen te gaan. Je wil een paar minuten wachten tot je omgeving klaar is met instellen. Van daaruit kun je beginnen met het gebruiken van je Kinsta testomgevingen om je site te bouwen en te testen.
Je Kinsta testomgeving een goed subdomeinadres geven
Onder normale omstandigheden zal je Kinsta testomgeving in een submap op je server staan. Het zal een URL hebben die een subdomein is van kinsta.cloud, maar dit kan een paar problemen veroorzaken:
- Sommige plugins zullen niet werken, zoals plugins die een licentie moeten verifiëren via een specifieke domeinnaam.
- Bepaalde configuraties van WordPress Multisite ondervinden problemen met subdirectories op Kinsta of hebben een aangepast subdomein nodig om optimaal te kunnen werken.
Daarom is het een goed idee om een goed subdomeinadres in te stellen voor je Kinsta testomgevingen. Voor premium gebruikers biedt Kinsta speciale subdomeinadressen, maar zelfs dit kan je problemen niet oplossen.
Het antwoord is om een custom domein voor je site in te stellen en dan testomgevingen uit te voeren vanaf een subdomein met behulp van het DNS (Domain Name System). Een custom URL voor testomgevingen met een goed domein en subdomein heeft twee voordelen: ten eerste kun je alle problemen waar we het over hebben beperken. Ten tweede heb je een ‘mooier’ subdomein om te delen met medewerkers of klanten.
Een live site naar een testomgeving pushen
Een aspect van je testomgeving dat in het begin misschien niet duidelijk is, is hoe je je live site er na de installatie naartoe pusht. Als je eenmaal begrijpt dat een testomgeving gewoon een kopie is van je live site, is het gemakkelijker te visualiseren.
Voor alle duidelijkheid volgt hier een kort overzicht van de workflow:
- Wanneer je een testomgeving maakt, kopieer je in wezen je live site naar een subdomein. Dit bevat al je databases en bestanden. Het is een volledige één-op-één replica van je live site.
- Je brengt wijzigingen aan in de testomgeving volgens je DevOps levenscyclus. Dit zal subjectief zijn en betrekking hebben op je eigen project, workflow en doelen.
- Als het gaat om het live zetten van die wijzigingen, heb je een paar opties. Je kunt de ingebouwde Push to Live functionaliteit binnen Kinsta gebruiken of handmatig wijzigingen aanbrengen. Hier gaan we later dieper op in.
- Vanaf hier heb je weer een één-op-één replica van je site voor zowel de testomgevingen- als de live-omgeving.
Er is dus geen manier om je testomgeving te verversen op basis van de status van je live site. Ons advies is om je testomgeving te verwijderen en opnieuw op te bouwen wanneer je hem weer nodig hebt, omdat dit je huidige site kopieert. Dit is nog een goede reden om een custom subdomeinadres te gebruiken voor je Kinsta testomgevingen.
Kinsta maakt back-ups voor zowel je live site als de testomgeving. Dit betekent dat je een backup van je live site ook direct naar testomgevingen kunt terugzetten. Op deze manier kun je met meer gemak tussen je levenscyclus-fasen heen en weer schakelen en kun je eerdere versies van je site gebruiken tijdens de ontwikkeling.
Merk op dat je eerst je testomgeving moet instellen, maar je kunt zowel naar een standaard als premium omgeving terugzetten. Je kunt dit doen via het MyKinsta dashboard:
Dit kost een paar klikken en zal ook beide bestaande backups voor je live en testsites behouden, samen met alle custom domeinen die je hebt ingesteld.
Versiebeheer opnemen in je testomgevingen setup
Veel developers maken gebruik van versiebeheer, zoals Git, wat we aanraden. Zowel live als testomgevingen op Kinsta bieden integratie met Git, wat betekent dat je versiebeheer kunt uitvoeren op je testomgevingen site om bovenop je ontwikkelingsschema te blijven.
Het ophalen en klonen van een repo op de server van Kinsta zou een fluitje van een cent moeten zijn. Het proces bestaat uit een paar basisstappen:
- Maak verbinding met je site met Secure Shell (SSH).
- Haal je huidige repo op van GitHub, GitLab of een andere vergelijkbare dienst.
- Je kunt ook je repo klonen vanaf je externe locatie.
Hoe je je remote repo ophaalt zal verschillen, afhankelijk van of het publiek of privé is, of Two-Factor Authenticatie (2FA) heeft. Als het gaat om het pushen van je code naar de repo op afstand, zul je echter een geschikte workflow moeten vinden.
Dit komt omdat Kinsta’s testomgevingen en Git integratie nog geen commando ondersteunen zoals git push kinsta mijnsite. Toch zijn er workarounds. Je zou bijvoorbeeld een tool als WP Pusher kunnen gebruiken:
Slimme developers vinden ook unieke manieren om naar GitHub te pushen vanuit Kinsta, al is het maar door een eenvoudig commando uit te voeren vanuit een Git client of het proces te automatiseren met scripts. We zullen later meer vertellen over het algemene concept van het pushen van je code naar de live site.
Prestatie testen op Kinsta’s testomgevingen
Onderdeel van je test- en monitoringfase in de Lifecycle is het bekijken (en vergelijken) van de prestaties van je testomgevingen site met benchmarks. Het goede nieuws is dat je toegang hebt tot alle tools van Kinsta voor je testomgevingen site, net als voor de live site.
In het kort: je pakt benchmarks voor je live site, maakt doelen die je wilt bereiken en optimaliseert je code binnen testomgevingen. Van daaruit beoordeel je of die veranderingen een positief verschil maken. Zo ja, dan kun je verder gaan. Als dat niet het geval is, doorloop je de coderings- en teststappen.
Voor de testomgevingen van Kinsta zal de Kinsta APM tool waarschijnlijk een centrale plek zijn:
Dit is een custom tool die zich richt op WordPress problemen en alle activiteit die het verzamelt van een tijdstempel voorziet. Je kunt PHP processen, je HTTP calls, database queries en nog veel meer controleren. We merken bijvoorbeeld dat de meeste problemen met prestatievermindering terug te voeren zijn op een niet-optimale plugin of thema. Kinsta APM kan je dit tot in detail laten zien op het WordPress tabblad.
Je zult zien dat het mogelijk is om diep in individuele transacties te kijken, wat betekent dat je precies kunt zien waar je knelpunten zitten. Voor testomgevingen sites zul je niet vaak de Redis transactietijd in de gaten houden. In plaats daarvan zullen je PHP en MySQL tijden interessanter zijn.
Het gebruik van een absoluut tijdsbestek bij het oplossen van problemen helpt om probleemgebieden aan te wijzen. De Kinsta documentatie leidt je door de algemene workflow, maar in een notendop, traag ladende pagina’s zouden je eerste zorg moeten zijn.
Van daaruit kun je je verdiepen in de processen die deze transacties vormen en suboptimale code of slechte externe tools opsporen. Je zult waarschijnlijk een combinatie van tools gebruiken om lastige code op te sporen en te bestrijden. Voor de ontwikkeling van WordPress zijn WP_DEBUG en Query Monitor gebruikelijk.
Continue deployment: wijzigingen synchroniseren tussen testomgevingen en productie
De deploymentfase van je levenscyclus betekent dat je een beslissing moet nemen: welke code push je. Je eerste gedachte is misschien om alles in één keer te pushen, maar dat is niet altijd het beste idee.
Dit komt omdat, hoe vergelijkbaar je testomgevingen en live omgevingen ook zijn, ze toch verschillen zullen hebben. Een afgemeten aanpak kan verstandiger zijn, omdat je een suite van code kunt pushen voor een specifieke verbetering, de veranderingen kunt volgen en dan de volgende push kunt plannen.
Dit concept staat centraal bij continue deployment, omdat veilige deployment een belangrijk aandachtspunt moet zijn. In het verleden stuurde Kinsta’s push-to-live functionaliteit met één klik je hele site terug naar je live server, ongeacht je wijzigingen. Je hebt nu echter ook selectieve pushopties: je kunt je bestanden, database of beide terugzetten naar live:
Dit bevat echter ook je omgevingsinstellingen, zoals je Nginx, PHP en redirect configuraties. Dit kan nog steeds overkill zijn, vooral als je slechts kleine of kleine wijzigingen aanbrengt in één specifiek onderdeel van je site.
Natuurlijk heb je ook de optie om af te zien van Kinsta’s push-to-live opties en het werk zelf uit te voeren. De veiligste aanpak is om je wijzigingen te repliceren op de live site in plaats van ze te automatiseren. Natuurlijk duurt het langer om te deployen, maar je hebt de mogelijkheid om elke wijziging te controleren terwijl deze live gaat.
Echter, ongeacht je benadering van continue deployment, je backups zullen een vitaal onderdeel zijn. Kinsta maakt elke dag backups voor elke site binnen je account. Dit omvat backups die het systeem genereert en ook je handmatige backups.
Bovendien is elke backup een complete momentopname van een specifieke omgeving. Dit betekent dat je binnen enkele minuten terug kunt naar een bekende werkende configuratie als je een kapotte site moet repareren.
Samenvatting
De testomgevingen van Kinsta kunnen je helpen bij het maken, testen en deployen van je site naar productie, ongeacht het aantal fasen dat je uitvoert of de aard van elke stap in je workflow. Ze zijn flexibel en je kunt de standaard gratis testomgeving gebruiken op elke site die je met Kinsta uitvoert.
Met een premium testomgeving kun je echter meerdere instanties instellen, resources gebruiken die overeenkomen met je live site en nog veel meer. De testomgevingen van Kinsta zijn daarnaast fantastisch als ze worden gebruikt naast onze Applicatie Hosting. Hoe dan ook, je kunt je site van lokaal naar live brengen en genieten van toegang tot alle typische tools van Kinsta rechtstreeks vanaf het MyKinsta dashboard.
Heb je vragen over het gebruik van Kinsta’s testomgevingen naast je reguliere DevOps technieken? Laat ons weten wat je ervan vindt in de commentsectie hieronder!
Laat een reactie achter