Naar de inhoud
Vimonto Deploy
Taal
Aan de slag
Menu

Deployments

Deploys die je site nooit platleggen

Elke deploy bouwt een verse release naast de live versie en schakelt pas over als elke stap is gelukt. Push naar je branch, roep vanuit CI een deploy-URL aan of klik op Deployen.

Begin met deployenLees de documentatie over deployments

Hoe het werkt

Vier stappen, en alleen de laatste raakt de live site

  1. 1

    De code ophalen

    Je branch wordt gekloond naar een nieuwe releasemap, genoemd naar datum en tijd. De commit, de auteur en het bericht worden vastgelegd.

  2. 2

    De release bouwen

    De gedeelde .env (en voor Laravel storage/) wordt gekoppeld, waarna je deployscript in de nieuwe release draait als de gebruiker van de site.

  3. 3

    Atomair live

    current wijst met één rename naar de nieuwe release. PHP-FPM herlaadt zodat OPcache de nieuwe bestanden ziet, en queue workers herstarten.

  4. 4

    Vijf releases bewaren

    Oudere releases worden opgeruimd; de nieuwste vijf blijven op de server staan, zodat terugzetten direct gaat en geen build nodig heeft.

Deployscript

Een deployscript dat je kunt lezen en aanpassen

Elke site begint met een deployscript dat bij zijn framework past. Het is gewoon Bash, draait met set -e in de nieuwe release, en je past het aan in je browser.

Gebruik $VIMONTO_PHP en $VIMONTO_COMPOSER in plaats van php en composer, zodat het script de PHP-versie van de site volgt als je die wijzigt. De branch en commit die gedeployd worden zijn ook beschikbaar.

Deployscript — standaard voor Laravel
$VIMONTO_COMPOSER install --no-dev --no-interaction --prefer-dist --optimize-autoloader

if [ -f package.json ]; then
    if [ -f package-lock.json ]; then npm ci; else npm install; fi
    npm run build
fi

$VIMONTO_PHP artisan storage:link --force
$VIMONTO_PHP artisan migrate --force
$VIMONTO_PHP artisan optimize

Start een deploy zoals het jou uitkomt

  • Push to deploy

    Koppel een repository van GitHub, GitLab (ook self-hosted) of Bitbucket en er wordt automatisch een webhook toegevoegd. Pushes naar de branch van de site worden gedeployd; andere branches worden genegeerd.

  • Een deploy-URL voor CI

    Roep als laatste stap van je pipeline een geheime URL aan met POST, zodat een deploy pas start als je tests slagen. Antwoorden zijn gewone JSON.

  • Deployen

    Eén knop in de kop van de site. Volg de fases live, of sluit de pagina: de deploy draait op de server en je krijgt een bericht als hij klaar is.

  • API en CLI

    Start deploys vanuit je eigen scripts met de REST API, of vanuit CI met de deploy-CLI en --watch, zodat een mislukte deploy de pipeline rood kleurt.

    Automatisering

Volg elke deploy terwijl hij gebeurt

De pagina van een deploy toont de fases Ophalen, Bouwen en Live, de stap die nu draait en de uitvoer van elke stap. Een geslaagde of mislukte deploy stuurt een melding: in de app, per e-mail of naar je eigen endpoint.

Een afgeronde deploy in Vimonto Deploy met de fases Ophalen, Bouwen en Live, de commitgegevens en het log van elke stap
Eén deploy: fases, commit en log.

Mislukt een deploy, dan verandert er niets

Mislukt het ophalen van de code of het deployscript, dan wordt de nieuwe release weggegooid en blijft current onaangeroerd. Bezoekers krijgen gewoon de versie die live stond, en de deploypagina toont de fout met het volledige log.

Terug gaat net zo snel: kies Terugzetten bij een eerdere deploy en die release staat weer live, zonder iets te bouwen. Databasemigraties worden niet teruggedraaid; maak die zelf ongedaan als een release dat nodig heeft.

  • Per site draait er maar één deploy tegelijk
  • De eerste deploy bouwt .env op basis van je .env.example
  • Elke .env-wijziging wordt bewaard: herstel een van de laatste 50
  • Liever snellere builds? Zet een site op in-place deploys

Terugzetten in de documentatie

Veiligere releases

  • Stagingsites

    Een kopie van een site voor een andere branch, zoals develop, op een eigen adres en met een eigen database. Elke push naar die branch deployt hem.

  • Beveiligingscontroles

    Elke deploy controleert de Composer- en npm-afhankelijkheden van de nieuwe release voordat die live gaat. Kies per site of een bekende kwetsbaarheid waarschuwt of de deploy stopt.

  • Wat ging er mis

    Een mislukte deploy wordt in gewone taal uitgelegd op basis van het log, met voorgestelde oplossingen, de meest waarschijnlijke eerst.

Vragen over deployments

Moet ik de deploypagina openhouden?

Nee. Deploys draaien op de server als achtergrondtaken. Sluit de pagina gerust; wie de deploy startte krijgt een bericht als hij klaar is, en elke deploy staat op de activiteitenpagina en in het auditlog.

Hoeveel releases worden bewaard?

Vijf: de nieuwste releases, altijd inclusief de live release. Oudere worden na elke geslaagde deploy verwijderd.

Vanaf welke Git-hosts kan ik deployen?

GitHub, GitLab (ook self-hosted GitLab) en Bitbucket, met push to deploy. Elke andere Git-server werkt via een eigen Git-URL met de deploy key van de site; start die deploys met de deploy-URL.

Kan ik deployen zonder zero downtime?

Ja. Met deploys zonder downtime uitgeschakeld werkt elke deploy één release ter plekke bij. Dat houdt vendor/ en node_modules/ vast en bouwt sneller. Je levert terugzetten in, en bezoekers kunnen de site zien terwijl hij bouwt.

Gerelateerde pagina’s

Je volgende deploy kan live zijn voordat je koffie koud is.

Maak een organisatie aan, koppel een server en push. Meer is het niet.

Begin met deployenLees de documentatie