Koppel je code: wijzig, controleer, keur goed, publiceer en draai terug in een echte codebase

Geef het project een naam en plak daarna het adres van de repository (via de groene knop Code op GitHub) en de branch waaruit de site draait, meestal main. Kies hoe aiKit er toegang toe krijgt. GitHub-token: een fine-grained token die je op GitHub maakt voor deze ene repository, met Contents ingesteld op Read and write; die hoort bij een https://-adres. Deploy-sleutel: een sleutelpaar dat alleen voor deze repository is gemaakt; het publieke deel voeg je toe onder Settings, Deploy keys van de repository, met Allow write access aangevinkt; die hoort bij een git@-adres. Openbare repository: alleen-lezen, dus goedgekeurde wijzigingen kunnen nergens worden opgeslagen; gebruik dit alleen om rond te kijken.

Je plakt het token of de sleutel zelf. Het wordt versleuteld opgeslagen op de engine van aiKit en nooit meer getoond, aan niemand. De pagina toont alleen een vingerafdruk. Bij Repository koppelen wordt de code naar de engine gekopieerd en wordt gelezen welk soort project het is (Laravel, JavaScript of statische bestanden). Er verandert niets in de repository.

Een project dat je al hebt, kun je ook koppelen: op het tabblad Hosting ziet de eigenaar Koppel je code.

Je eigen server: de site blijft precies waar hij staat. Vul het adres van de server in, de SSH-poort (meestal 22), de login die aiKit gebruikt (de installatiestappen maken een login aikit aan), de map van de site (bij een Laravel Forge-site /home/forge/jouw-site.nl), het publicatiecommando dat de site al gebruikt (meestal bash scripts/deploy.sh), en de pagina's die na elke publicatie moeten antwoorden, één volledig adres per regel. Plak de privésleutel van de serverlogin (gemaakt in installatiestap 1). Sla op en controleer de verbinding.

De eerste keer dat aiKit de server bereikt, toont het de vingerafdruk van de server en vraagt Is dit je server? Vergelijk die met wat de server heeft getoond in installatiestap 6. Druk alleen op Het klopt als ze identiek zijn. Daarna wordt een andere server op dat adres geweigerd. Als de controle slaagt, toont de pagina welke versie de server nu draait.

aiKit-hosting: aiKit bouwt en serveert de code zelf, met een gratis adres om mee te beginnen. Het beste voor sites en frontends.

Onder Serverinstallatie staan op de pagina acht stappen om te kopiëren en plakken, al ingevuld met jouw waarden; elke stap heeft een knop Kopiëren. Stap 1 en 8 draaien op je eigen computer, stappen 2 tot en met 7 op de server als gebruiker met sudo.

Wat ze aanmaken: een login zonder wachtwoord en zonder shell (stap 2). De enige sleutel daarvan is vastgezet op een klein poortscript (stappen 3 en 5) dat precies twee commando's accepteert: status (welke versie draait, en of de site in onderhoudsmodus staat) en deploy van één exacte commit. Publiceren draait als de eigen gebruiker van de site via één sudo-regel, controleert of de branch op GitHub naar precies die commit wijst, en draait daarna je bestaande publicatiescript ongewijzigd. Stap 4 zet mappenrechten zo dat de login alleen de sitemap bereikt: niet de andere sites in dezelfde thuismap, en nooit .env. Stap 7 test dit allemaal en zegt bij elke regel wat je moet zien, en stap 8 test de login vanaf je eigen computer voordat je de sleutel in aiKit plakt.

Als een server ook andere bedrijven hosten, is dit het punt: de aiKit-login kan deze ene site publiceren en niets anders. De code van de site draait nog steeds als de gebruiker van de site, precies zoals wanneer je zelf vanaf GitHub publiceert. Daarom wordt elke wijziging beoordeeld en worden riskante bestanden beschermd.

Vier tegels bovenaan. Repository: de repository, branch, de nieuwste commit en het soort project. Draait op: je eigen server (met de login en het moment waarop hij voor het laatst antwoordde) of aiKit-hosting. Live release: de release die de site draait, wie die heeft gemaakt en wanneer. Pagina's: hoeveel van de pagina's die moeten antwoorden er bij de laatste controle hebben geantwoord; Nu controleren bezoekt ze opnieuw, en elke pagina die niet antwoordde staat eronder met wat ze teruggaf.

Onder de tegels: Een wijziging aanvragen (of de wijziging die nu open staat), Releases, Wijzigingslogboek, Beschermde bestanden en, voor de eigenaar, Verbinding.

Typ wat er moet veranderen, met de naam van de pagina en wat je wilt zien, en druk op Wijziging doorvoeren. De kaart wordt Wijziging #1 met live voortgang: de nieuwste code ophalen, de bestanden die de AI leest en bewerkt, en daarna elke controle. De AI bewerkt alleen bestanden; hij voert geen commando's uit. Per project staat er één wijziging tegelijk open, en elke aanvraag telt mee voor de AI-limiet van het project.

Wanneer het klaar is, zie je: de aanvraag en wie hem deed; wat de AI zegt dat hij heeft gedaan; de controles, elk met een vinkje of een kruisje en de uitvoer; knoppen Voorbeeld voor de gecontroleerde pagina's; de bestanden met Toegevoegd, Gewijzigd of Verwijderd en waar van toepassing een badge Beschermd; en het verschil, bestand voor bestand, groen voor toegevoegde regels en rood voor verwijderde regels. Dat verschil is precies wat wordt vastgelegd en gepubliceerd.

Goedkeuren en uitrollen (eigenaren en bouwers) zet de wijziging in de branch met een bericht waarin staat wie erom vroeg en wie goedkeurde, duwt die door (nooit geforceerd: als iemand intussen iets heeft gepusht, wordt de wijziging als Verouderd gemarkeerd en wordt er niets uitgerold), rolt hem uit en controleert de pagina's. Weggooien gooit de wijziging weg na een bevestiging; er is niets uitgerold. Reviewers kunnen alles lezen maar geen van beide knoppen gebruiken.

Nadat de controles zijn geslaagd is een instelling onder Verbinding, Controles en review. Wachten op goedkeuring is de standaard. Automatisch uitrollen rolt een wijziging zelf uit, alleen als alle controles zijn geslaagd en geen beveiligd bestand is gewijzigd; in alle andere gevallen wacht de wijziging nog steeds.

Voor een Laravel-project zijn de controles: elk gewijzigd PHP-bestand wordt gecontroleerd op syntaxis (php -l); elke Blade-view wordt gecompileerd (php artisan view:cache); de front end wordt gebouwd (npm run build); en de app wordt gestart in een testrun met een wegwerp-SQLite-database, die is gemigreerd en gevuld vanuit de repository, waarbij elke pagina in Pagina's die de testrun moet openen met 200 moet antwoorden. Ze draaien op de engine van aiKit, nooit op jouw server en nooit tegen je live database. Het .env-bestand van het project wordt nooit gekopieerd of gelezen; de testrun krijgt wegwerpinstellingen.

Een mislukte controle blokkeert Goedkeuren. Alleen de eigenaar kan Uitrollen aanvinken, ook als controles zijn mislukt, voor een controle die is mislukt om een reden die de live site niet raakt.

Preview opent de gewijzigde app uit de testrun in een nieuw tabblad, met testdata en formulieren uitgeschakeld. Het stopt 15 minuten na het laatste gebruik en eindigt wanneer de wijziging wordt goedgekeurd of weggegooid.

De AI laat beveiligde bestanden met rust. De lijst begint met: migraties die al op de live site zijn uitgevoerd (elke migratie in de live release, omdat elke uitrol ze uitvoert), nieuwe migraties (die de live database bij de volgende uitrol zouden wijzigen), het uitrolscript en de afhankelijkheidsbestanden (composer.json, composer.lock, package.json, package-lock.json). Elk item vermeldt waarom. De eigenaar voegt een bestand of map toe (config/** betekent alles onder config) met een reden, verwijdert items en drukt op Beveiligde bestanden opslaan.

Om opzettelijk een beveiligd bestand te wijzigen, vinkt de eigenaar Beveiligde bestanden toestaan voor dit verzoek aan. De wijziging toont dan welke beveiligde bestanden zijn aangeraakt, en alleen de eigenaar kan hem goedkeuren, nadat hij Ja, de wijzigingen in beveiligde bestanden uitrollen heeft aangevinkt. Een bouwer die niets aanvinkt, krijgt geen toegang tot beveiligde bestanden.

.env-bestanden, privésleutels en auth.json vallen in een strengere categorie: ze worden nooit gelezen, nooit gewijzigd, maken nooit deel uit van een diff, en niemand kan dit uitschakelen.

De eerste keer dat aiKit je server bereikt, legt het vast wat de server draait als release 1, Vóór aiKit, zodat zelfs de eerste uitrol van aiKit kan worden teruggedraaid. Daarna is elke uitrol een genummerde release: Wijziging (een goedgekeurde wijziging; de naam opent die wijziging), Opnieuw uitrollen of Terugdraaien, met de commit, wie het deed, de status (Live, Eerder, Live maar pagina's falen, Uitrollen mislukt), hoeveel pagina's antwoordden, en het uitrollogboek. aiKit bewaart de laatste 5.

Nieuwste code uitrollen rolt uit wat er nu het nieuwst op de branch staat, na een bevestiging, bijvoorbeeld wanneer iemand direct een oplossing heeft gepusht.

Terugdraaien naar dit, op een eerdere release, maakt een nieuwe commit waarvan de bestanden precies die van die release zijn, duwt die door en rolt hem uit op de gewone manier, waarna de pagina's worden gecontroleerd. De geschiedenis wordt nooit herschreven, dus de terugdraaiing zelf kan ook worden teruggedraaid.

Elk verzoek met zijn nummer, het verzoek, wie het aanvroeg, wie het goedkeurde of weggooide, wanneer, en waar het nu staat. Klik op een rij om die wijziging te openen met de controles en diff; het adres krijgt ?change=<id>, zodat je de link met je team kunt delen.