Entwickler · Rezepte für dein CI
Dein CI, das auf SWPanel deployt
Kopiere das Rezept deines Tools, speichere deinen Token als Secret und pushe. SWPanel empfängt das Paket, validiert und analysiert es und veröffentlicht es auf deinem Hosting oder deiner Cloud, mit einer Kopie des Bestehenden.
- GitHub Actions, GitLab CI, Bitbucket und Jenkins
- Testmodus für Pull Requests
- Rollback mit einem Aufruf
~/mi-web npm run build && tar -czf web.tgz -C dist .~/mi-web curl -X POST …/services/$SERVICIO/deployment/ \ -H "Authorization: Bearer $SWPANEL_TOKEN" -F "[email protected]"Paket vollständig empfangen ok SHA-256Validiert ok Pfade, Größe und DateienAnalysiert ok ohne schwere FehlerKopie des Bestehenden, gespeichert okAuf deiner Website veröffentlicht ok
Bevor du beginnst
Drei Dinge und du kannst deployen
-
Erstelle in SWPanel einen Token
Am besten einer nur für Deployments, auf den Dienst beschränkt, auf dem du veröffentlichst, mit Ablaufdatum und deinen IPs.
-
Speichere ihn als Secret
In deinem CI unter dem Namen
SWPANEL_TOKEN. Niemals im Repository. -
Gib den Dienst an
Die Kennung des Hostings oder der Cloud, auf der deine Website liegt, in der Variable
SERVICIO.
Rezepte
Wähle dein Tool, kopieren und einfügen
Alle tun dasselbe: Sie bauen die Website wie immer, verpacken sie und laden sie mit einem API-Aufruf hoch.
on:
push:
branches: [main]
jobs:
desplegar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build && tar -czf web.tgz -C dist .
- run: |
curl -X POST \
https://api.swpanel.com/public/services/$SERVICIO/deployment/ \
-H "Authorization: Bearer ${{ secrets.SWPANEL_TOKEN }}" \
-F "[email protected]"
# Läuft bei jedem Push auf main
desplegar:
stage: deploy
image: node:20
rules:
- if: $CI_COMMIT_BRANCH == "main"
script:
- npm ci && npm run build && tar -czf web.tgz -C dist .
- >
curl -X POST
"https://api.swpanel.com/public/services/$SERVICIO/deployment/"
-H "Authorization: Bearer $SWPANEL_TOKEN"
-F "[email protected]"
# Läuft bei jedem Push auf main
image: node:20
pipelines:
branches:
main:
- step:
name: Desplegar en SWPanel
script:
- npm ci && npm run build && tar -czf web.tgz -C dist .
- curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/"
-H "Authorization: Bearer $SWPANEL_TOKEN"
-F "[email protected]"
# Läuft bei jedem Push auf main
pipeline {
agent any
environment { SWPANEL_TOKEN = credentials('swpanel-token') }
stages {
stage('Construir') {
steps { sh 'npm ci && npm run build && tar -czf web.tgz -C dist .' }
}
stage('Desplegar') {
when { branch 'main' }
steps {
sh 'curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/" -H "Authorization: Bearer $SWPANEL_TOKEN" -F "[email protected]"'
}
}
}
}
// Der Token, als Jenkins-Credential gespeichert
tar -czf web.tgz -C dist . curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/" \ -H "Authorization: Bearer $SWPANEL_TOKEN" \ -F "[email protected]" # Aus deinem Terminal oder jedem Skript
composer install --no-dev tar -czf tema.tgz -C wp-content/themes/mi-tema . curl -X POST "https://api.swpanel.com/public/services/$SERVICIO/deployment/" \ -H "Authorization: Bearer $SWPANEL_TOKEN" \ -F "[email protected]" # Dein Theme, aus dem Repository, ohne wp-config.php oder die Uploads anzufassen
Beispielrezepte. Alle Optionen des Aufrufs (Testmodus, Branch, Commit und geschützte Dateien) stehen in der API-Dokumentation.
Pull Requests
Teste es vor dem Mergen
Mit dem Testmodus validiert und analysiert SWPanel das Paket jeder Pull Request und sagt dir, was passieren würde, ohne etwas zu veröffentlichen. So hat alles, was auf main landet, den Filter bereits bestanden.
- Dieselbe Analyse wie in der Produktion: Fehler, Sicherheit und Abhängigkeiten
- Deine Regeln gelten auch: Ein Flow kann das Deployment blockieren
- Keine einzige Zeile der Website ändert sich
on: pull_request
jobs:
probar:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- run: npm ci && npm run build && tar -czf web.tgz -C dist .
- run: |
curl -X POST \
https://api.swpanel.com/public/services/$SERVICIO/deployment/ \
-H "Authorization: Bearer ${{ secrets.SWPANEL_TOKEN }}" \
-F "[email protected]" \
-F "dry_run=true"
# Bei jeder Pull Request: validiert und analysiert, ohne zu veröffentlichen
Was danach passiert
Vom Aufruf zur Website
Was SWPanel mit jedem Paket macht, bevor es deine Website anfasst.
-
Empfängt es
Vollständig: Bis es komplett ankommt und sein Fingerabdruck (SHA-256) stimmt, wird es nicht verwendet.
-
Validiert es
Pfade, Größe (standardmäßig bis 50 MB) und verbotene Dateien.
-
Analysiert es
Fehler, Schwachstellen und Abhängigkeiten mit bekannten Mängeln.
-
Wendet deine Regeln an
Deine Flows können ein Deployment stoppen, und die Produktion kann eine Freigabe über SWPanel oder Telegram verlangen.
-
Veröffentlicht es
Mit einer Kopie der vorherigen Version und ohne deine geschützten Dateien anzufassen. Du und dein Team erhaltet die Benachrichtigung.
Keine Geheimnisse
Deploye ohne einen Schlüssel zu speichern
Mit OIDC weisen GitHub Actions und GitLab CI gegenüber SWPanel nach, welches Repository und welchen Branch sie deployen. Im CI gibt es keinen Schlüssel, der durchsickern könnte.
Rollback
Wenn etwas schiefgeht, ein Klick
Jedes Deployment bleibt im Verlauf: wer, wann, welcher Commit und was sich geändert hat. Du kehrst mit einem Klick in SWPanel oder mit einem API-Aufruf zur vorherigen Version zurück, und atomare Deployments schalten die Website auf einen Schlag um, ohne halbfertige Zustände.
Häufige Fragen
Fragen zu Deployments
Dein nächster Push, schon auf der Website
Erstelle deinen Token, kopiere das Rezept und pushe.
