Forbind din kode: ændr, kontrollér, godkend, udrul og rul tilbage i en rigtig kodebase

Navngiv projektet, og indsæt derefter lagerets adresse (fra GitHubs grønne Code-knap) og den gren, webstedet kører fra, normalt main. Vælg, hvordan aiKit får adgang. GitHub-token: et finkornet token, du laver på GitHub til netop dette lager med Contents sat til Read and write; det hører sammen med en https://-adresse. Deploy-nøgle: et nøglepar, der kun er lavet til dette lager, hvor den offentlige del tilføjes under lagerets Settings, Deploy keys, med Allow write access markeret; det hører sammen med en git@-adresse. Offentligt lager: kun læseadgang, så godkendte ændringer har ingen steder at blive gemt; brug det kun til at kigge rundt.

Du indsætter selv tokenet eller nøglen. Den gemmes krypteret på aiKits motor og vises aldrig igen, for nogen. Siden viser kun et fingeraftryk. Forbind lageret kopierer koden til motoren og læser, hvilken type projekt det er (Laravel, JavaScript eller statiske filer). Intet i lageret ændres.

Et projekt, du allerede har, kan også forbindes: på dets Hosting-fane ser ejeren Forbind din kode.

Din egen server: webstedet bliver præcis, hvor det er. Angiv serverens adresse, SSH-porten (normalt 22), loginet aiKit bruger (opsætningstrinene laver et kaldet aikit), webstedets mappe (for et Laravel Forge-site, /home/forge/dit-site.dk), udrulningskommandoen webstedet allerede bruger (normalt bash scripts/deploy.sh) og de sider, der skal svare efter hver udrulning, én fuld adresse pr. linje. Indsæt serverloginets private nøgle (lavet i opsætningstrin 1). Gem og kontrollér forbindelsen.

Første gang aiKit når serveren, viser den serverens fingeraftryk og spørger Er det din server? Sammenlign det med det, serveren udskrev i opsætningstrin 6. Tryk kun på Det passer. Forbind, når de er identiske. Herefter afvises en anden server på den adresse. Når kontrollen består, viser siden, hvilken version serveren kører lige nu.

aiKit-hosting: aiKit bygger og serverer selv koden, med en gratis adresse til start. Bedst til websteder og frontends.

Under Serveropsætning viser siden otte trin, du kan kopiere og indsætte, allerede udfyldt med dine værdier; hvert har en Kopiér-knap. Trin 1 og 8 køres på din computer, trin 2 til 7 på serveren som en bruger med sudo.

Det de opretter: et login uden adgangskode og uden shell (trin 2). Dets ene nøgle er låst til et lille gate-script (trin 3 og 5), som kun accepterer to kommandoer: status (hvilken version der kører, og om webstedet er i vedligeholdelsestilstand) og deploy af én bestemt commit. Deploy kører som webstedets egen bruger via én sudo-regel, kontrollerer at grenen på GitHub peger på præcis den commit, og kører derefter dit eksisterende udrulningsscript uændret. Trin 4 sætter mappetilladelser, så loginet kun når webstedets mappe: ikke de andre sites i samme hjemmemappe, og aldrig .env. Trin 7 tester alt og siger, hvad du skal se for hver linje, og trin 8 tester loginet fra din computer, før du indsætter dets nøgle i aiKit.

Hvis en server også hoster andre virksomheder, er det pointen: aiKit-loginet kan kun udrulle dette ene websted og intet andet. Webstedets kode kører stadig som webstedets bruger, præcis som når du selv udruller fra GitHub, og derfor bliver hver ændring gennemgået, og risikable filer er beskyttet.

Fire fliser øverst. Repository: lageret, grenen, den nyeste commit og projekttypen. Kører på: din egen server (med loginet og hvornår den sidst svarede) eller aiKit-hosting. Aktiv udgivelse: den udgivelse, webstedet kører, hvem der lavede den, og hvornår. Sider: hvor mange af de sider, der skal svare, der svarede ved sidste kontrol; Kontrollér nu besøger dem igen, og en side, der ikke svarede, vises nedenunder med det, den returnerede.

Under flisene: Anmod om en ændring (eller den ændring, der er åben lige nu), Udgivelser, Ændringslog, Beskyttede filer og, for ejeren, Forbindelse.

Skriv, hvad der skal ændres, med navn på siden og hvad du vil se, og tryk på Lav ændringen. Kortet bliver til Ændring #1 med live-status: hentning af den nyeste kode, de filer AI'en læser og redigerer, og derefter hver kontrol. AI'en redigerer kun filer; den kører ingen kommandoer. Der er én åben ændring ad gangen pr. projekt, og hver anmodning tæller med i projektets AI-grænse.

Når den er færdig, ser du: anmodningen og hvem der bad om den; hvad AI'en siger, den gjorde; kontrollerne, hver med et flueben eller et kryds og sit output; Forhåndsvisning-knapper til de kontrollerede sider; filerne med Tilføjet, Ændret eller Fjernet og et Beskyttet-mærke, hvor det gælder; og forskellene fil for fil, grønt for tilføjede linjer og rødt for fjernede linjer. Forskellene er præcis det, der bliver committet og udrullet.

Godkend og udrul (ejere og bygmestre) gemmer ændringen på grenen med en besked, der angiver, hvem der bad om den, og hvem der godkendte den, skubber den op (aldrig tvunget: hvis nogen har skubbet i mellemtiden, markeres ændringen som Forældet, og intet udrulles), udruller den og tjekker siderne. Kassér smider ændringen væk efter en bekræftelse; intet er blevet udrullet. Anmeldere kan læse alt, men kan ikke trykke på nogen af knapperne.

Efter at kontrollerne er bestået, er det en indstilling under Forbindelse, Kontroller og gennemgang. Afvent godkendelse er standard. Udrul automatisk udruller kun en ændring af sig selv, når alle kontroller er bestået, og ingen beskyttet fil er ændret; alt andet venter stadig.

For et Laravel-projekt er kontrollerne: hver ændret PHP-fil analyseres (php -l); hver Blade-visning kompileres (php artisan view:cache); front end bygges (npm run build); og appen starter i en testkørsel med en midlertidig SQLite-database, migreret og fyldt med data fra repositoryet, hvor hver side under Sider, som testkørslen skal åbne, skal svare 200. Kontrollerne køres på aiKits motor, aldrig på din server og aldrig mod din live-database. Projektets .env-fil kopieres eller læses aldrig; testkørslen får midlertidige indstillinger.

En mislykket kontrol blokerer Godkend. Kun ejeren kan sætte kryds i Udrul, selv om kontroller er fejlet, for en kontrol, der fejlede af en grund, som ikke påvirker den live side.

Forhåndsvisning åbner den ændrede app fra testkørslen i en ny fane, med testdata og formularer slået fra. Den stopper 15 minutter efter sidste brug og afsluttes, når ændringen godkendes eller kasseres.

AI'en lader beskyttede filer være i fred. Listen starter med: migreringer, der allerede er kørt på den live side (alle migreringer i den live udgivelse, da hver udrulning kører dem), nye migreringer (de ville ændre den live database ved næste udrulning), udrulningsscriptet og afhængighedsfilerne (composer.json, composer.lock, package.json, package-lock.json). Hver post forklarer hvorfor. Ejeren tilføjer en fil eller mappe (config/** betyder alt under config) med en begrundelse, fjerner poster og trykker på Gem beskyttede filer.

For at ændre en beskyttet fil med vilje sætter ejeren kryds i Tillad beskyttede filer til denne anmodning. Ændringen viser så, hvilke beskyttede filer den har berørt, og kun ejeren kan godkende den, efter at have sat kryds i Ja, udrul ændringerne til beskyttede filer. En bygmester, der ikke sætter kryds, får ingen adgang til beskyttede filer.

.env-filer, private nøgler og auth.json er i et strengere niveau: aldrig læst, aldrig ændret, aldrig en del af en diff, og ingen kan slå det fra.

Første gang aiKit når din server, registrerer den, hvad serveren kører, som udgivelse 1, Før aiKit, så selv aiKits første udrulning kan rulles tilbage. Derefter er hver udrulning en nummereret udgivelse: Ændring (en godkendt ændring; dens navn åbner den ændring), Udrul igen eller Tilbagerulning, med sin commit, hvem der gjorde det, sin status (Live, Tidligere, Live, men sider fejler, Udrulning mislykkedes), hvor mange sider der svarede, og udrulningsloggen. aiKit gemmer de sidste 5.

Udrul seneste kode udruller det nyeste, der findes på grenen lige nu, efter en bekræftelse, for eksempel når nogen har skubbet en rettelse direkte.

Rul tilbage til denne på en tidligere udgivelse laver en ny commit, hvis filer præcis er den udgivelses filer, skubber den op og udruller den på den normale måde og tjekker derefter siderne. Historikken omskrives aldrig, så selve tilbagerulningen kan rulles tilbage.

Hver anmodning med sit nummer, anmodningen, hvem der bad om den, hvem der godkendte eller kasserede den, hvornår, og hvor den står. Tryk på en række for at åbne ændringen med dens kontroller og diff; adressen får ?change=<id>, så du kan dele linket med dit team.