Verbinde deinen Code: ändern, prüfen, freigeben, veröffentlichen und zurücksetzen in einer echten Codebasis

Gib dem Projekt einen Namen und füge dann die Adresse des Repositorys (über den grünen Button Code bei GitHub) und den Branch ein, von dem die Website läuft, meist main. Wähle, wie aiKit darauf zugreift. GitHub-Token: ein feingranularer Token, den du bei GitHub nur für dieses eine Repository erstellst, mit Contents auf Read and write; er gehört zu einer https://-Adresse. Deploy-Schlüssel: ein Schlüsselpaar, das nur für dieses Repository erstellt wird. Den öffentlichen Teil fügst du unter den Einstellungen des Repositorys bei Deploy keys hinzu, mit aktiviertem Allow write access; er gehört zu einer git@-Adresse. Öffentliches Repository: nur Lesezugriff, daher können freigegebene Änderungen nirgends gespeichert werden; nutze es nur zum Ansehen.

Den Token oder Schlüssel fügst du selbst ein. Er wird verschlüsselt auf der Engine von aiKit gespeichert und nie wieder angezeigt, auch nicht für andere. Die Seite zeigt nur einen Fingerabdruck. Beim Verbinden des Repositorys wird der Code auf die Engine kopiert und erkannt, um welche Art von Projekt es sich handelt (Laravel, JavaScript oder statische Dateien). Am Repository wird nichts verändert.

Ein bereits vorhandenes Projekt kann ebenfalls verbunden werden: Auf seinem Tab Hosting sieht der Inhaber den Eintrag Code verbinden.

Dein eigener Server: Die Website bleibt genau dort, wo sie ist. Gib die Adresse des Servers, den SSH-Port (meist 22), den Login ein, den aiKit verwendet (die Einrichtungsschritte erstellen einen namens aikit), den Ordner der Website (bei einer Laravel-Forge-Website z. B. /home/forge/deine-seite.de), den Deploy-Befehl, den die Website bereits nutzt (meist bash scripts/deploy.sh), und die Seiten, die nach jeder Veröffentlichung antworten müssen, eine vollständige Adresse pro Zeile. Füge den privaten Schlüssel des Server-Logins ein (erstellt in Einrichtungsschritt 1). Speichern und Verbindung prüfen.

Wenn aiKit den Server zum ersten Mal erreicht, zeigt es den Fingerabdruck des Servers und fragt Ist das dein Server? Vergleiche ihn mit dem, was der Server in Einrichtungsschritt 6 ausgegeben hat. Drücke nur dann Stimmt überein. Verbinden, wenn beide identisch sind. Danach wird ein anderer Server unter dieser Adresse abgelehnt. Wenn die Prüfung besteht, zeigt die Seite an, welche Version der Server gerade ausführt.

aiKit-Hosting: aiKit erstellt und stellt den Code selbst bereit, zunächst mit einer kostenlosen Adresse. Ideal für Websites und Frontends.

Unter Servereinrichtung listet die Seite acht Schritte zum Kopieren und Einfügen auf, die bereits mit deinen Werten ausgefüllt sind; jeder hat einen Button Kopieren. Die Schritte 1 und 8 laufen auf deinem Computer, die Schritte 2 bis 7 auf dem Server als Benutzer mit sudo.

Was sie einrichten: ein Login ohne Passwort und ohne Shell (Schritt 2). Sein einziger Schlüssel ist an ein kleines Torskript gebunden (Schritte 3 und 5), das genau zwei Befehle annimmt: status (welche Version läuft und ob die Website im Wartungsmodus ist) und deploy eines genau festgelegten Commits. Deploy läuft als eigener Benutzer der Website über eine einzige sudo-Regel, prüft, ob der Branch auf GitHub genau auf diesen Commit zeigt, und führt dann dein bestehendes Deploy-Skript unverändert aus. Schritt 4 setzt die Ordnerrechte so, dass das Login nur den Website-Ordner erreicht: nicht die anderen Websites im selben Home-Ordner und niemals .env. Schritt 7 testet alles und sagt bei jeder Zeile, was du sehen solltest, und Schritt 8 testet das Login von deinem Computer aus, bevor du seinen Schlüssel in aiKit einfügst.

Hostet ein Server auch andere Unternehmen, liegt hier der Vorteil: Das aiKit-Login kann genau diese eine Website veröffentlichen und sonst nichts. Der Code der Website läuft weiterhin unter dem Benutzer der Website, genau so wie beim Veröffentlichen direkt von GitHub aus, deshalb wird jede Änderung geprüft und riskante Dateien sind geschützt.

Oben vier Kacheln. Repository: das Repository, der Branch, der neueste Commit und die Art des Projekts. Läuft auf: dein eigener Server (mit dem Login und dem Zeitpunkt der letzten Antwort) oder aiKit-Hosting. Live-Version: die Version, die die Website ausführt, wer sie erstellt hat und wann. Seiten: wie viele der Seiten, die antworten müssen, bei der letzten Prüfung geantwortet haben; Jetzt prüfen besucht sie erneut, und jede Seite, die nicht antwortete, wird darunter mit ihrer Rückmeldung aufgelistet.

Unterhalb der Kacheln: Änderung anfragen (oder die gerade offene Änderung), Versionen, Änderungsverlauf, Geschützte Dateien und, für den Inhaber, Verbindung.

Beschreibe, was sich ändern soll, nenne die Seite und was du sehen möchtest, und drücke Änderung durchführen. Die Karte wird zu Änderung #1 mit Live-Fortschritt: Abruf des neuesten Codes, die Dateien, die die KI liest und bearbeitet, und dann jede Prüfung. Die KI bearbeitet nur Dateien; sie führt keine Befehle aus. Pro Projekt ist jeweils eine Änderung offen, und jede Anfrage zählt auf das KI-Limit des Projekts.

Wenn sie fertig ist, siehst du: die Anfrage und wer sie gestellt hat; was die KI nach eigenen Angaben getan hat; die Prüfungen, jede mit Häkchen oder Kreuz und ihrer Ausgabe; Vorschau-Buttons für die geprüften Seiten; die Dateien mit Hinzugefügt, Geändert oder Entfernt und einem Geschützt-Hinweis, wo er zutrifft; und den Unterschied, Datei für Datei, grün für hinzugefügte und rot für entfernte Zeilen. Dieser Unterschied ist genau das, was committet und veröffentlicht wird.

Genehmigen und bereitstellen (Eigentümer und Entwickler) übernimmt die Änderung in den Branch mit einer Nachricht, die nennt, wer sie angefordert und wer sie genehmigt hat, und überträgt sie (nie erzwungen: Hat jemand inzwischen etwas übertragen, wird die Änderung als veraltet markiert und nichts wird bereitgestellt). Anschließend wird sie bereitgestellt und die Seiten werden geprüft. Verwerfen wirft die Änderung nach einer Bestätigung weg; nichts wurde bereitgestellt. Prüfer können alles lesen, aber keine der beiden Schaltflächen drücken.

Nach dem Bestehen der Prüfungen ist dies eine Einstellung unter Verbindung, Prüfungen und Review. Auf Genehmigung warten ist die Standardeinstellung. Automatisch bereitstellen stellt eine Änderung nur dann selbst bereit, wenn alle Prüfungen bestanden wurden und keine geschützte Datei geändert wurde; alles andere wartet weiterhin.

Bei einem Laravel-Projekt sind die Prüfungen: Jede geänderte PHP-Datei wird geparst (php -l); jede Blade-View wird kompiliert (php artisan view:cache); das Frontend wird gebaut (npm run build); und die App startet in einem Testlauf mit einer Wegwerf-SQLite-Datenbank, die aus dem Repository migriert und befüllt wird, wobei jede Seite unter Seiten, die der Testlauf öffnen muss, mit 200 antworten muss. Sie laufen auf der Engine von aiKit, niemals auf Ihrem Server und niemals gegen Ihre Live-Datenbank. Die .env-Datei des Projekts wird nie kopiert oder gelesen; der Testlauf erhält Wegwerf-Einstellungen.

Eine fehlgeschlagene Prüfung blockiert Genehmigen. Nur der Eigentümer kann Bereitstellen ankreuzen, obwohl Prüfungen fehlgeschlagen sind, und zwar für eine Prüfung, die aus einem Grund fehlschlug, der die Live-Seite nicht betrifft.

Vorschau öffnet die geänderte App aus dem Testlauf in einem neuen Tab, mit Testdaten und deaktivierten Formularen. Sie endet 15 Minuten nach ihrer letzten Nutzung und wird beendet, sobald die Änderung genehmigt oder verworfen wird.

Die KI lässt geschützte Dateien in Ruhe. Die Liste beginnt mit: Migrationen, die bereits auf der Live-Seite gelaufen sind (jede Migration der Live-Version, da jede Bereitstellung sie ausführt), neue Migrationen (sie würden die Live-Datenbank bei der nächsten Bereitstellung verändern), das Bereitstellungsskript und die Abhängigkeitsdateien (composer.json, composer.lock, package.json, package-lock.json). Jeder Eintrag nennt den Grund. Der Eigentümer fügt eine Datei oder einen Ordner hinzu (config/** bedeutet alles unter config) mit einem Grund, entfernt Einträge und drückt Geschützte Dateien speichern.

Um absichtlich eine geschützte Datei zu ändern, setzt der Eigentümer das Häkchen bei Geschützte Dateien für diese Anfrage erlauben. Die Änderung zeigt dann, welche geschützten Dateien sie berührt hat, und nur der Eigentümer kann sie genehmigen, nachdem er Ja, die Änderungen an geschützten Dateien bereitstellen angekreuzt hat. Ein Entwickler, der nichts ankreuzt, erhält keinen Zugriff auf geschützte Dateien.

.env-Dateien, private Schlüssel und auth.json gehören zu einer strengeren Stufe: Sie werden nie gelesen, nie geändert, sind nie Teil eines Diffs, und niemand kann das ausschalten.

Beim ersten Kontakt mit Ihrem Server erfasst aiKit, was der Server als Version 1, Vor aiKit ausführt, sodass sich sogar die erste Bereitstellung von aiKit zurückrollen lässt. Danach ist jede Bereitstellung eine nummerierte Version: Änderung (eine genehmigte Änderung; ihr Name öffnet diese Änderung), Erneut bereitstellen oder Zurückrollen, mit ihrem Commit, wer es ausgeführt hat, ihrem Status (Live, Früher, Live, aber Seiten fehlerhaft, Bereitstellung fehlgeschlagen), wie viele Seiten geantwortet haben, und dem Bereitstellungsprotokoll. aiKit behält die letzten 5.

Neuesten Code bereitstellen stellt das Neueste auf dem Branch genau jetzt bereit, nach einer Bestätigung, etwa wenn jemand eine Korrektur direkt übertragen hat.

Auf diese Version zurückrollen erstellt bei einer früheren Version einen neuen Commit, dessen Dateien genau denen dieser Version entsprechen, überträgt ihn und stellt ihn auf normalem Weg bereit, danach werden die Seiten geprüft. Der Verlauf wird nie umgeschrieben, daher lässt sich auch das Zurückrollen selbst zurückrollen.

Jede Anfrage mit ihrer Nummer, der Anfrage, wer sie angefordert hat, wer sie genehmigt oder verworfen hat, wann, und wo sie steht. Drücken Sie auf eine Zeile, um diese Änderung mit ihren Prüfungen und ihrem Diff zu öffnen; die Adresse erhält ?change=<id>, sodass Sie den Link mit Ihrem Team teilen können.