Collega il tuo codice: modifica, controlla, approva, pubblica e ripristina una base di codice reale

Assegna un nome al progetto, poi incolla l'indirizzo del repository (dal pulsante verde Code di GitHub) e il branch da cui viene eseguito il sito, di solito main. Scegli come aiKit vi accede. Token GitHub: un token a grana fine che crei su GitHub solo per questo repository, con Contents impostato su Read and write; va con un indirizzo https://. Chiave di deploy: una coppia di chiavi creata solo per questo repository, di cui aggiungi la parte pubblica in Settings, Deploy keys del repository, con Allow write access selezionato; va con un indirizzo git@. Repository pubblico: solo lettura, quindi le modifiche approvate non possono essere salvate; usalo solo per dare un'occhiata.

Incolli tu il token o la chiave. Viene memorizzato in forma cifrata sul motore di aiKit e non viene mai più mostrato, a nessuno. La pagina mostra solo un'impronta. Collega il repository copia il codice sul motore e riconosce che tipo di progetto è (Laravel, JavaScript o file statici). Nel repository non cambia nulla.

Puoi collegare anche un progetto che hai già: nella sua scheda Hosting, il proprietario vede Collega il tuo codice.

Il tuo server: il sito resta esattamente dov'è. Inserisci l'indirizzo del server, la porta SSH (di solito 22), l'accesso che aiKit usa (i passaggi di configurazione ne creano uno chiamato aikit), la cartella del sito (per un sito Laravel Forge, /home/forge/tuo-sito.com), il comando di pubblicazione che il sito già usa (di solito bash scripts/deploy.sh) e le pagine che devono rispondere dopo ogni pubblicazione, un indirizzo completo per riga. Incolla la chiave privata dell'accesso al server (creata nel passo 1 della configurazione). Salva e verifica la connessione.

La prima volta che aiKit raggiunge il server, mostra l'impronta del server e chiede È questo il tuo server? Confrontala con quella stampata dal server nel passo 6 della configurazione. Premi solo Corrisponde. Collega quando sono identiche. Da quel momento, un server diverso a quell'indirizzo viene rifiutato. Quando il controllo ha successo, la pagina indica quale versione il server sta eseguendo in questo momento.

Hosting di aiKit: aiKit compila e serve il codice da sola, con un indirizzo gratuito per iniziare. Ideale per siti e front end.

Nella sezione Configurazione del server la pagina elenca otto passaggi da copiare e incollare, già compilati con i tuoi valori; ciascuno ha un pulsante Copia. I passi 1 e 8 vengono eseguiti sul tuo computer, i passi da 2 a 7 sul server con un utente che ha sudo.

Cosa creano: un accesso senza password e senza shell (passo 2). La sua unica chiave è vincolata a un piccolo script di controllo (passi 3 e 5) che accetta esattamente due comandi: status (quale versione è in esecuzione e se il sito è in manutenzione) e deploy di un commit preciso. Il deploy viene eseguito con l'utente del sito tramite un'unica regola sudo, verifica che il branch su GitHub punti esattamente a quel commit, quindi esegue il tuo script di deploy esistente senza modifiche. Il passo 4 imposta i permessi della cartella in modo che l'accesso raggiunga solo la cartella del sito: non gli altri siti nella stessa cartella home, e mai .env. Il passo 7 verifica tutto e indica cosa dovresti vedere per ogni riga, e il passo 8 verifica l'accesso dal tuo computer prima che tu incolli la sua chiave in aiKit.

Se un server ospita anche altre attività, questo è il punto: l'accesso di aiKit può pubblicare solo questo sito e nient'altro. Il codice del sito viene comunque eseguito con l'utente del sito, esattamente come quando pubblichi tu da GitHub, ed è per questo che ogni modifica viene verificata e i file a rischio sono protetti.

Quattro riquadri in alto. Repository: il repository, il branch, il commit più recente e il tipo di progetto. Eseguito su: il tuo server (con l'accesso e l'ultima risposta) oppure l'hosting di aiKit. Versione live: la versione in esecuzione sul sito, chi l'ha creata e quando. Pagine: quante delle pagine che devono rispondere hanno risposto all'ultimo controllo; Controlla ora le visita di nuovo, e le pagine che non hanno risposto sono elencate sotto con ciò che hanno restituito.

Sotto i riquadri: Richiedi una modifica (o la modifica attualmente aperta), Versioni, Registro delle modifiche, File protetti e, per il proprietario, Connessione.

Scrivi cosa deve cambiare, indicando la pagina e ciò che vuoi vedere, poi premi Apporta la modifica. La scheda diventa Modifica #1 con l'avanzamento in tempo reale: recupero dell'ultimo codice, i file che l'AI legge e modifica, quindi ogni controllo. L'AI modifica solo i file; non esegue comandi. Per ogni progetto è aperta una modifica alla volta, e ogni richiesta conta nel limite AI del progetto.

Al termine vedi: la richiesta e chi l'ha fatta; cosa dice l'AI di aver fatto; i controlli, ciascuno con un segno di spunta o una croce e il relativo output; i pulsanti Anteprima per le pagine controllate; i file con Aggiunto, Modificato o Rimosso e un distintivo Protetto dove applicabile; e le differenze, file per file, verde per le righe aggiunte e rosso per quelle rimosse. Quelle differenze sono esattamente ciò che verrà salvato e pubblicato.

Approva e pubblica (proprietari e sviluppatori) salva la modifica nel branch con un messaggio che indica chi l'ha chiesta e chi l'ha approvata, la invia (mai forzata: se qualcuno ha inviato nel frattempo, la modifica viene contrassegnata come Non aggiornata e non viene pubblicato nulla), la pubblica e controlla le pagine. Scarta elimina la modifica dopo una conferma; non è stato pubblicato nulla. I revisori possono leggere tutto ma non possono premere nessuno dei due pulsanti.

Dopo il superamento dei controlli è un'impostazione in Connessione, Controlli e revisione. Attendi approvazione è l'opzione predefinita. Pubblica automaticamente pubblica da sola una modifica solo quando tutti i controlli sono superati e nessun file protetto è stato modificato; in tutti gli altri casi la modifica resta in attesa.

Per un progetto Laravel i controlli sono: ogni file PHP modificato viene analizzato (php -l); ogni vista Blade viene compilata (php artisan view:cache); il front end viene compilato (npm run build); e l'app viene avviata in una prova con un database SQLite temporaneo, migrato e popolato dal repository, dove ogni pagina indicata in Pagine della prova deve rispondere 200. Vengono eseguiti sul motore di aiKit, mai sul tuo server e mai sul tuo database live. Il file .env del progetto non viene mai copiato né letto; la prova usa impostazioni temporanee.

Un controllo non superato blocca Approva. Solo il proprietario può spuntare Pubblica anche se i controlli non sono riusciti, per un controllo fallito per un motivo che non influisce sul sito live.

Anteprima apre l'app modificata dalla prova in una nuova scheda, con dati di prova e moduli disattivati. Si chiude 15 minuti dopo l'ultimo utilizzo e termina quando la modifica viene approvata o scartata.

L'IA non modifica i file protetti. L'elenco inizia con: migrazioni già eseguite sul sito live (ogni migrazione nella release live, poiché ogni pubblicazione le esegue), nuove migrazioni (modificherebbero il database live alla pubblicazione successiva), lo script di pubblicazione e i file delle dipendenze (composer.json, composer.lock, package.json, package-lock.json). Ogni voce indica il motivo. Il proprietario aggiunge un file o una cartella (config/** significa tutto ciò che si trova in config) con un motivo, rimuove voci e preme Salva file protetti.

Per modificare intenzionalmente un file protetto, il proprietario spunta Consenti file protetti per questa richiesta. La modifica mostra poi quali file protetti ha toccato, e solo il proprietario può approvarla, dopo aver spuntato Sì, pubblica le modifiche ai file protetti. Uno sviluppatore che non spunta nulla non ottiene alcun accesso ai file protetti.

I file .env, le chiavi private e auth.json rientrano in un livello più rigido: non vengono mai letti, mai modificati, mai inclusi in un diff, e nessuno può disattivare questa protezione.

La prima volta che aiKit raggiunge il tuo server, registra ciò che il server esegue come release 1, Prima di aiKit, così anche la prima pubblicazione di aiKit può essere ripristinata. Da quel momento ogni pubblicazione è una release numerata: Modifica (una modifica approvata; il suo nome apre quella modifica), Ripubblica o Ripristino, con il commit, chi l'ha eseguita, lo stato (Live, Precedente, Live ma pagine in errore, Pubblicazione non riuscita), quante pagine hanno risposto e il registro della pubblicazione. aiKit conserva le ultime 5.

Pubblica l'ultimo codice pubblica la versione più recente presente ora nel branch, dopo una conferma, ad esempio quando qualcuno ha inviato direttamente una correzione.

Ripristina a questa, su una release precedente, crea un nuovo commit i cui file sono esattamente quelli di quella release, lo invia e lo pubblica nel modo normale, poi controlla le pagine. La cronologia non viene mai riscritta, quindi anche il ripristino stesso può essere annullato.

Ogni richiesta con il suo numero, la richiesta, chi l'ha chiesta, chi l'ha approvata o scartata, quando e a che punto si trova. Premi una riga per aprire quella modifica con i suoi controlli e il diff; l'indirizzo riceve ?change=<id>, così puoi condividere il link con il tuo team.