Stagingsites voor een branch van je Laravel-app

Een stagingsite is een kopie van een site op dezelfde server die een andere branch van dezelfde repository deployt, op een eigen adres. Gebruik hem om een branch, zoals develop of staging, uit te proberen voordat die live gaat: elke push naar die branch deployt de stagingsite, en alleen de stagingsite.

Stagingsites zijn echte sites. Elke heeft eigen pagina's (deployments, omgeving, domeinen, logs enzovoort), een eigen map op de server, een eigen deploy key en een eigen deploy-URL. Ze staan op de pagina Staging van de site die ze nabootsen, en daaronder op de pagina Sites van de server.

Een stagingsite maken#

1. Open de site en klik in de zijbalk op Staging.
2. Klik op Nieuwe stagingsite.
3. Kies de Branch. Met een Git-koppeling worden de branches van de repository voorgesteld (de branch die de site zelf deployt blijft weg); je kunt ook een branch typen die je later pusht.
4. Kies het adres:
   • een Adres op on-deploy.link, ingevuld met een gegenereerde naam die met staging- begint (als gegenereerde adressen beschikbaar zijn). Het krijgt vanzelf HTTPS zodra het adres naar de server wijst; of
   • klik op Eigen domein gebruiken en vul een Domein in, zoals staging.example.com. Staat het domein in een zone van een van je DNS-integraties, dan zie je welke records Vimonto Deploy gaat maken, net als wanneer je een domein toevoegt. Voor een stagingdomein wordt geen www.-record gemaakt.
5. Laat De .env kopiëren aan staan om te beginnen met de .env van de site (zichtbaar als de site er een heeft).
6. Laat Deployen bij elke push aan staan om de stagingsite bij elke push naar zijn branch te deployen (zichtbaar voor sites met een Git-koppeling).
7. Klik op Stagingsite aanmaken.

De stagingsite wordt als achtergrondtaak ingericht, net als een nieuwe site, en de eerste deploy start zodra de inrichting klaar is.

Welke database gebruikt een stagingsite?#

Nooit de live database. Op een server met een database krijgt elke stagingsite een nieuwe, lege database en een eigen gebruiker, genoemd naar het adres (bijvoorbeeld staging_example_com). Draai je migraties en seeders erop: php artisan migrate --force in het deployscript wijzigt altijd alleen de stagingdatabase.

Op een server zonder database (bijvoorbeeld een webserver waarvan de database op een aparte databaseserver draait) krijgt de stagingsite geen database-instellingen: de gekopieerde .env heeft lege DB_DATABASE, DB_USERNAME en DB_PASSWORD. Maak een database voor staging en vul ze in op de pagina Omgeving, nooit met de gegevens van de live database.

Wat krijgt een stagingsite?#

Een stagingsite wordt gemaakt met Site klonen, op dezelfde server, met deze verschillen:

De .env van een stagingsite#

Met De .env kopiëren aan krijgt de stagingsite de .env van de site, met:

• APP_URL op het stagingadres;
• APP_ENV=staging;
• de DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME en DB_PASSWORD van de eigen database, of lege database-instellingen op een server zonder database.

Al het andere, zoals mail-, cache- en queue-instellingen, blijft hetzelfde als op de live site. Pas die aan op de pagina Omgeving van de stagingsite als hij eigen waarden nodig heeft.

Met De .env kopiëren uit krijgt de stagingsite een verse .env, zoals een nieuwe site, met APP_ENV=staging.

Hoe pushes worden gedeployd#

De site en elk van zijn stagingsites hebben een eigen webhook bij je Git-host, elk met een eigen deploy-URL. Een push bereikt ze allemaal, en elke site deployt alleen als de push naar zijn eigen branch ging:

• een push naar main deployt de site die main volgt;
• een push naar develop deployt de stagingsite die develop volgt.

De andere webhooks antwoorden dat de push niet naar hun branch ging, en er gebeurt verder niets. Deployen bij elke push zet je voor een stagingsite later aan of uit op de pagina Deployments.

Stagingsites deployen, openen en verwijderen#

De pagina Staging toont elke stagingsite van de site, met zijn branch, of hij bij elke push deployt en zijn laatste deployment. Per stagingsite kun je:

• op Deployen klikken om zijn branch meteen te deployen;
• op Site openen klikken om zijn adres in een nieuwe tab te openen;
• op zijn adres klikken om naar de eigen pagina's van de stagingsite te gaan;
• op Verwijderen klikken, het adres typen en op Stagingsite verwijderen klikken om hem te verwijderen.

Een stagingsite verwijderen werkt als een site verwijderen: hij verdwijnt van de server met zijn releases, .env, workers en certificaten, en Vimonto Deploy verwijdert de DNS-records die het ervoor maakte en zijn deploy key en webhook bij je Git-host. De database blijft bewaard; verwijder hem op de pagina Databases van de server.

In de kop van de site zie je hoeveel stagingsites hij heeft; de kop van een stagingsite toont Staging van met een link terug naar zijn site.

Wie kan stagingsites maken?#

Elk lid kan stagingsites zien. Ze maken, deployen en verwijderen vraagt de rechten om sites te beheren, die eigenaren, beheerders, managers en developers hebben. Stagingsites staan op dezelfde server als hun site, dus leden die de site kunnen openen, kunnen ook zijn stagingsites openen.

Veelgestelde vragen#

Kan elke site stagingsites hebben?#

Sites met een repository wel. WordPress-, phpMyAdmin- en loadbalancer-sites niet, en een stagingsite kan zelf geen stagingsites hebben.

Wat gebeurt er met stagingsites als ik de site verwijder?#

Ze blijven bestaan, als eigen sites. Verwijder ze eerst op de pagina Staging als je ze niet meer nodig hebt.

Kan ik een stagingsite op een andere server zetten?#

Niet vanaf de pagina Staging: stagingsites staan op de server van hun site. Gebruik Site klonen om een kopie op een andere server te maken.

Waarom wordt de branch van de stagingsite niet voorgesteld?#

Branches worden voorgesteld voor sites met een Git-koppeling. Typ bij een site met alleen een Git-URL de naam van de branch.