Koppla din kod: ändra, kontrollera, godkänn, publicera och återställ en riktig kodbas

Namnge projektet och klistra sedan in förrådets adress (från den gröna knappen Code på GitHub) och den gren webbplatsen körs från, oftast main. Välj hur aiKit når det. GitHub-token: en finkornig token som du skapar på GitHub för just detta förråd med Contents satt till Read and write; den används med en https://-adress. Deploy key: ett nyckelpar som skapas enbart för detta förråd, där den publika delen läggs till under förrådets Settings, Deploy keys, med Allow write access ikryssat; den används med en git@-adress. Offentligt förråd: endast läsning, så godkända ändringar har ingenstans att sparas; använd det bara för att titta runt.

Du klistrar in token eller nyckel själv. Den lagras krypterad på aiKits motor och visas aldrig igen, för någon. Sidan visar bara ett fingeravtryck. Koppla förrådet kopierar koden till motorn och läser vilken typ av projekt det är (Laravel, JavaScript eller statiska filer). Ingenting i förrådet ändras.

Ett projekt du redan har kan också kopplas: på dess fliken Hosting ser ägaren Koppla din kod.

Din egen server: webbplatsen stannar exakt där den är. Ange serverns adress, SSH-porten (oftast 22), inloggningen aiKit använder (installationsstegen skapar en som heter aikit), webbplatsens mapp (för en Laravel Forge-webbplats, /home/forge/din-webbplats.com), det publiceringskommando webbplatsen redan använder (oftast bash scripts/deploy.sh) och de sidor som måste svara efter varje publicering, en fullständig adress per rad. Klistra in serverinloggningens privata nyckel (skapad i installationssteg 1). Spara och kontrollera anslutningen.

Första gången aiKit når servern visar den serverns fingeravtryck och frågar Är det här din server? Jämför det med vad servern skrev ut i installationssteg 6. Tryck bara på Det stämmer. Anslut när de är identiska. Därefter nekas en annan server på den adressen. När kontrollen godkänns visar sidan vilken version servern kör just nu.

aiKit-hosting: aiKit bygger och serverar koden själv, med en gratis adress för att komma igång. Bäst för webbplatser och gränssnitt.

Under Serverinstallation listar sidan åtta steg att kopiera och klistra in, redan ifyllda med dina värden; varje steg har en knapp för att kopiera. Steg 1 och 8 körs på din dator, steg 2 till 7 på servern som en användare med sudo.

Det de skapar: en inloggning utan lösenord och utan skal (steg 2). Dess enda nyckel är låst till ett litet grindskript (steg 3 och 5) som accepterar exakt två kommandon: status (vilken version som körs, och om webbplatsen är i underhållsläge) och deploy av en exakt commit. Publiceringen körs som webbplatsens egen användare genom en sudo-regel, kontrollerar att grenen på GitHub pekar på just den commiten och kör sedan ditt befintliga publiceringsskript oförändrat. Steg 4 sätter mappbehörigheter så att inloggningen bara når webbplatsens mapp: inte de andra webbplatserna i samma hemmapp, och aldrig .env. Steg 7 testar allt och säger vad du ska se för varje rad, och steg 8 testar inloggningen från din dator innan du klistrar in dess nyckel i aiKit.

Om en server även är värd för andra företag är det här poängen: aiKit-inloggningen kan publicera just den här webbplatsen och ingenting annat. Webbplatsens kod körs fortfarande som webbplatsens användare, precis som när du publicerar från GitHub själv, vilket är anledningen till att varje ändring granskas och att riskfyllda filer skyddas.

Fyra rutor överst. Repository: förrådet, grenen, den senaste commiten och typen av projekt. Körs på: din egen server (med inloggningen och när den senast svarade) eller aiKit-hosting. Aktiv version: versionen som webbplatsen kör, vem som gjorde den och när. Sidor: hur många av de sidor som måste svara som svarade vid senaste kontrollen; Kontrollera nu besöker dem igen, och varje sida som inte svarade listas nedanför med vad den returnerade.

Under rutorna: Begär en ändring (eller den ändring som är öppen just nu), Versioner, Ändringslogg, Skyddade filer och, för ägaren, Anslutning.

Skriv vad som ska ändras, med sidan och vad du vill se, och tryck på Gör ändringen. Kortet blir Ändring #1 med live-förlopp: hämtar den senaste koden, filerna AI:n läser och redigerar, och sedan varje kontroll. AI:n redigerar bara filer; den kör inga kommandon. En ändring är öppen i taget per projekt, och varje begäran räknas mot projektets AI-gräns.

När den är klar ser du: begäran och vem som bad om den; vad AI:n säger att den gjorde; kontrollerna, var och en med en bock eller ett kryss och dess utdata; knappar för Förhandsgranska för de kontrollerade sidorna; filerna med Tillagd, Ändrad eller Borttagen och en Skyddad-märkning där det gäller; och skillnaden, fil för fil, grönt för tillagda rader och rött för borttagna rader. Skillnaden är exakt det som kommer att sparas och publiceras.

Godkänn och publicera (ägare och byggare) skickar ändringen till grenen med ett meddelande som anger vem som bad om den och vem som godkände den, skickar upp den (aldrig tvingat: om någon hunnit pusha under tiden markeras ändringen som Föråldrad och inget publiceras), publicerar den och kontrollerar sidorna. Kassera slänger bort ändringen efter en bekräftelse; inget har publicerats. Granskare kan läsa allt men kan inte trycka på någon av knapparna.

Efter att kontrollerna har godkänts är en inställning under Anslutning, Kontroller och granskning. Vänta på godkännande är standard. Publicera automatiskt publicerar en ändring av sig själv endast när alla kontroller godkänts och ingen skyddad fil har ändrats; allt annat väntar fortfarande.

För ett Laravel-projekt är kontrollerna: varje ändrad PHP-fil tolkas (php -l); varje Blade-vy kompileras (php artisan view:cache); gränssnittet byggs (npm run build); och appen startar i en testkörning med en tillfällig SQLite-databas, migrerad och fylld med data från repositoryt, där varje sida i Sidor som testkörningen ska öppna måste svara 200. De körs på aiKits motor, aldrig på din server och aldrig mot din livedatabas. Projektets .env-fil kopieras eller läses aldrig; testkörningen får tillfälliga inställningar.

En misslyckad kontroll blockerar Godkänn. Endast ägaren kan bocka i Publicera även när kontroller misslyckats, för en kontroll som misslyckats av en orsak som inte påverkar den publicerade sajten.

Förhandsvisning öppnar den ändrade appen från testkörningen i en ny flik, med testdata och formulär avstängda. Den stängs 15 minuter efter senaste användning och avslutas när ändringen godkänns eller kasseras.

AI:n lämnar skyddade filer ifred. Listan börjar med: migreringar som redan körts på den publicerade sajten (varje migrering i den publicerade releasen, eftersom varje publicering kör dem), nya migreringar (de skulle ändra livedatabasen vid nästa publicering), publiceringsskriptet och beroendefilerna (composer.json, composer.lock, package.json, package-lock.json). Varje post anger varför. Ägaren lägger till en fil eller mapp (config/** betyder allt under config) med en orsak, tar bort poster och trycker på Spara skyddade filer.

För att ändra en skyddad fil med avsikt bockar ägaren i Tillåt skyddade filer för den här begäran. Ändringen visar sedan vilka skyddade filer den berörde, och endast ägaren kan godkänna den, efter att ha bockat i Ja, publicera ändringarna i skyddade filer. En byggare som inte bockar i något får ingen åtkomst till skyddade filer.

.env-filer, privata nycklar och auth.json ligger i en strängare nivå: läses aldrig, ändras aldrig, ingår aldrig i en diff, och ingen kan stänga av det.

Första gången aiKit når din server registrerar den vad servern kör som release 1, Före aiKit, så att även aiKits första publicering kan återställas. Därefter är varje publicering en numrerad release: Ändring (en godkänd ändring; dess namn öppnar den ändringen), Publicera igen eller Återställning, med sin commit, vem som gjorde den, sin status (Live, Tidigare, Live men sidor fungerar inte, Publicering misslyckades), hur många sidor som svarade och publiceringsloggen. aiKit sparar de senaste 5.

Publicera senaste koden publicerar det som är nyast på grenen just nu, efter en bekräftelse, till exempel när någon pushat en rättning direkt.

Återställ till detta, på en tidigare release, skapar en ny commit vars filer är exakt den releasens, skickar upp den och publicerar den på vanligt sätt och kontrollerar sedan sidorna. Historiken skrivs aldrig om, så själva återställningen kan återställas.

Varje begäran med sitt nummer, begäran, vem som bad om den, vem som godkände eller kasserade den, när och var den står. Tryck på en rad för att öppna ändringen med dess kontroller och diff; adressen får ?change=<id>, så att du kan dela länken med ditt team.