Projekto perkėlimas iš Codex į Hermes serveryje
MarkdownSaugyklos perkėlimas į serverį darbui su Hermes: išsaugoti pakeitimai, priklausomybės, paslaptys, darbinis aplankas ir patikros prieš tęsiant kūrimą.
Skaityti visą straipsnį
Jei reikia pagalbos naudojantis paslauga, žr. Ailoot dokumentaciją.
Pagrindinė mintis
Norėdami tęsti darbą su projektu, sukurtu naudojant Codex, perkelkite pačią saugyklą ir atkurkite jos aplinką. Taikant šį būdą, nereikia atskiro veiksmo „importuoti projektą iš agento“. Pirmiausia patikrinkite išsaugotus failus ir priklausomybes, tada Hermes atidarykite tinkamą aplanką. Šiame vadove daroma prielaida, kad serveris ir Hermes jau paruošti, o jūs turite prieigą prie saugyklos.
Ką paruošti prieš perkeliant
Saugykla yra projekto aplankas su Git pakeitimų istorija. Darbinėje kopijoje yra jūsų redaguojami failai. Šiuo atveju reikia perkelti šią kopiją į serverį ir tęsti kūrimą. Kol kas nereikia padaryti programos prieinamos lankytojams.
Jei agentas dar neįdiegtas serveryje, pradėkite nuo Hermes Agent diegimo VPS. Čia jums reikės veikiančio Hermes diegimo, serverio terminalo ir Git. Reikia nuotolinės saugyklos, kurią serveris gali pasiekti; jei tokios dar neturite, pirmiausia ją sukurkite ir išsaugokite joje projektą be paslapčių. Jei saugykla privati, iš anksto nustatykite skaitymo prieigą iš savo paskyros; nedėkite prieigos rakto į saugyklos URL ar agentui skirtą pranešimą.
Perkeldami projektą, pristabdykite lygiagrečius jo pakeitimus. Šaltinio kompiuteryje atidarykite terminalą pačiame projekto aplanke ir vykdykite:
git status --short --branch
git status --short --ignored
Pirmoji komanda parodo šaką ir failų būseną. M reiškia pakeitimą, o ?? – failą, kurio Git dar neseka. Antrojoje komandoje ignoruojami failai pažymėti !!. Įprasta švari būsena neįrodo, kad už Git ribų neturite reikalingų failų.
Išsaugokite reikiamus pakeitimus atskirame commit ir įprastu būdu nusiųskite tinkamą šaką į nuotolinę saugyklą. Prieš siųsdami patikrinkite commit turinį: jame neturi būti raktų, slaptažodžių ar tikrų naudotojų duomenų. Jei nežinote, kuriuos pakeitimus išsaugoti, pirmiausia paprašykite Codex juos išvardyti ir paaiškinti jų paskirtį, nieko neištrinant ir nesiunčiant į saugyklą.
| Projekto dalis | Ką patikrinti prieš perkeliant |
|---|---|
| Pirminiai failai ir Git istorija | Reikalingi pakeitimai išsaugoti ir pasiekiami pasirinktoje nuotolinės saugyklos šakoje |
| README ir agento instrukcijos | Paleidimo veiksmai, patikros ir apribojimai dokumentuoti; instrukcijos atnaujintos |
| Priklausomybių failai | Išsaugoti priklausomybių aprašai ir projekte naudojamas versijas fiksuojantis lockfile |
| Paslaptys | Yra atskiras saugus būdas jas nustatyti serveryje; jų reikšmės nėra Git saugykloje ir nesiunčiamos per pokalbį |
| Duomenų bazė ir įkelti failai | Žinote, kur gauti leidžiamus bandomuosius duomenis ir kaip juos atkurti pagal projekto instrukcijas |
Nemanykite, kad klonuojant saugyklą bus perkelta išorinė duomenų bazė, ignoruojamo aplanko turinys ar jūsų pokalbiai su Codex. Pokalbių istorija, prenumeratos, profiliai ir pačių agentų nustatymai nėra šio perkėlimo būdo dalis.
Nukopijuokite tinkamą šaką į serverį
Pirmiausia šaltinio kompiuteryje išsaugokite šios komandos išvestį:
git status --porcelain=v2 --branch
Eilutėje # branch.oid rodomas dabartinis commit, o eilutėje # branch.head – šaka. Commit yra išsaugota projekto versija. Įprastame projekte, kuriame yra ankstesnių commit, tai leidžia palyginti šaltinio kopiją su nauja kopija; šis palyginimas nepatikrina neišsaugotų pakeitimų.
Serveryje eikite į katalogą, kuriame saugosite projektus. Klonuokite saugyklą į naują aplanką. Toliau pateiktame šablone REPOSITORY_URL pakeiskite saugyklos URL, BRANCH_NAME – išsaugotos ir nusiųstos šakos pavadinimu, o my-project – norimu naujo aplanko pavadinimu:
git clone --branch BRANCH_NAME REPOSITORY_URL my-project
cd my-project
git status --porcelain=v2 --branch
Tai šablonas, o ne paruoštas kopijuoti URL. git clone sukuria aplanką ir pasirinktos šakos darbinę kopiją. Jei paskirties aplankas jau yra, jis turi būti tuščias: neištrinkite jo turinio norėdami pakartoti komandą; pasirinkite naują pavadinimą.
Palyginkite # branch.oid abiejose kopijose. Jei reikšmės skiriasi, nepradėkite taisyti kodo serveryje: patikrinkite pasirinktą šaką, nusiųstus commit ir tai, ar nebuvo atlikta lygiagrečių pakeitimų. Jei būsenos išvestyje rodomi pakeisti failai, išnagrinėkite juos atskirai. Nenaudokite valymo ar priverstinio atkūrimo tam, kad „suvienodintumėte“ kopijas.
Saugykloms su Git submoduliais – įdėtinėmis saugyklomis – taip pat reikia gauti jų turinį. git clone turi parinktį --recurse-submodules; naudokite ją, jei projekte iš tiesų yra submodulių ir patikrinote jų URL. Projektams su kitais išoriniais ištekliais gali reikėti papildomos README aprašytos procedūros.
Atkurkite priklausomybes pagal projekto taisykles
Pirmiausia perskaitykite README ir projekto konfigūracijos failus. Išsiaiškinkite, kokios vykdymo aplinkos versijos reikia ir kokia paketų tvarkyklė naudojama priklausomybėms įdiegti. Nepakeiskite įprasto projekto įrankio npm vien dėl to, kad jis paminėtas toliau pateiktame pavyzdyje.
Hipotetinis Node.js ir npm pavyzdys: saugykloje yra suderinti package.json ir package-lock.json failai, o serveryje įdiegta projektui tinkama Node.js versija. Tokiu atveju vykdykite šią komandą projekto aplanke:
npm ci
Pagal npm ci dokumentaciją, ši komanda įdiegia viso projekto priklausomybes iš lockfile, neperrašydama package.json ar package-lock.json. Jei jų turinys nesuderintas, diegimas nepavyksta. Prieš diegiant ištrinamas bet kuris esamas node_modules aplankas.
Jei lockfile sukurtas naudojant priklausomybių medį veikiančias parinktis, pavyzdžiui, --legacy-peer-deps, npm ci reikia tų pačių parinkčių. Patikrinkite šaltinio projekto instrukcijas ir nustatymus. Neištrinkite lockfile ir neatnaujinkite visų priklausomybių norėdami paslėpti pirmąją perkėlimo klaidą.
Prieš diegdami patikrinkite savo projekto diegimo ir paleidimo komandas. Vykdykite jas atskiroje darbinėje kopijoje, neturinčioje prieigos prie gamybinių duomenų, o visas reikalingas aplinkos reikšmes nustatykite ne pokalbyje ir ne Git. Jei įmanoma, projektui patikrinti naudokite bandomuosius prisijungimo duomenis su ribotomis teisėmis. Jei projektas priklauso nuo duomenų bazės ar failų, pirmiausia pagal projekto instrukcijas atkurkite leidžiamą bandomųjų duomenų rinkinį; tie patys pirminiai failai šių duomenų nepakeičia.
Įdiegę vykdykite README nurodytas esamas patikras: testus ir surinkimą, jei jie pateikti. Komandų pavadinimai priklauso nuo projekto. Sėkmingas priklausomybių diegimas dar nereiškia, kad programa veikia.
Atidarykite darbinę kopiją Hermes aplinkoje
Serverio terminale eikite į naujos kopijos šakninį katalogą ir paleiskite jau įdiegtą agentą:
cd /absolute/path/to/my-project
hermes
Čia /absolute/path/to/my-project yra vietaženklis, reiškiantis visą kelią iki jūsų projekto. Hermes paleidimo ekrane patikrinkite darbinį katalogą ir aplinką, kurioje vykdomos terminalo komandos. Šis paleidimo būdas skirtas Hermes vietinei serverio terminalo aplinkai. Jei sukonfigūruotas SSH arba Docker, agentas gali vykdyti komandas kitoje aplinkoje; pirmiausia patvirtinkite, koks projekto kelias ten pasiekiamas.
Paprašykite agento jo terminalo įrankiu patvirtinti tikrąjį darbinį aplanką, tada perskaityti README ir projekto instrukcijas. Aplanko pavadinimo pranešime nelaikykite pakankamu patvirtinimu.
Toliau nurodyta tvarka pateikta prisegtoje dokumentacijos versijoje ir gali skirtis nuo jūsų įdiegtos Hermes versijos. Patikrinkite dabartines instrukcijas savo sesijoje. Hermes palaiko AGENTS.md, tačiau tai, ar skaito šį failą, priklauso nuo konteksto failų prioritetų. Pagal oficialią Hermes dokumentaciją, pasirenkamas vienas instrukcijų failo tipas tokia tvarka: .hermes.md, tada AGENTS.override.md, AGENTS.md, CLAUDE.md ir .cursorrules. Prieš pradėdami darbą patikrinkite, ar nėra seno .hermes.md arba asmeninio AGENTS.override.md; nemanykite, kad agentas būtinai taikys kartu su juo esantį AGENTS.md.
Pasirinktose instrukcijose palikite projekto paskirtį, patikrų komandas ir pakeitimų apribojimus. Nepaverskite jų pokalbių archyvu. Jei reikia perkelti ir pačių agentų nustatymus, tai atskiras procesas; jo apimtis paaiškinta migravimo iš Claude Code į Codex vadove.
Skirkite agentui vieną užduotį ir patikrinkite rezultatą
Pradėkite nuo projekto skaitymo nieko nekeičiant. Pavyzdžiui:
We are working with an existing project in the folder I specified.
Confirm the actual working directory using the terminal tool.
Read the README and the current project instructions.
Do not open files containing secrets or print environment values.
List the check commands and the prerequisites for running them.
For now, do not change or install anything, or push to the repository.
Tada susitarkite dėl vienos nedidelės užduoties, pavyzdžiui, ištaisyti tekstą sąsajoje. Nurodykite keistinus failus arba sritį ir uždrauskite atsitiktinius priklausomybių atnaujinimus. Jei norite eksperimentą atskirti nuo pagrindinės kopijos, pirmiausia sužinokite apie atskirą Git worktree darbinę kopiją.
Priimkite rezultatą atsižvelgdami į failų pakeitimus ir pakartotines projekto patikras. Prieš eksperimentą, kuris gali nepavykti, išsaugokite šaltinio kopiją ir atkūrimo tašką; neprašykite agento iš karto atkurti visų pakeitimų. Jei patikra nepavyksta, palyginkite klaidą su šaltinio kopija: tai padeda atskirti perkėlimo problemą nuo trūkumo, kuris buvo jau anksčiau.
Perkėlimą galima laikyti užbaigtu, kai yra reikiama pirminių failų versija, atkurta aplinka, reikalingi duomenys pasiekiami saugioje bandomojoje aplinkoje, patikros sėkmingos, o Hermes veikia būtent šiame aplanke. Programos paskelbimas lankytojams yra atskiras kitas etapas ir nėra šios patikros dalis.
Susipažinkite su Ailoot.
Išsamiau
Klausimai ir atsakymai
Ar saugyklos klonavimas perkelia visą darbo aplinką?
Ne. Git klonavimas neperkelia ignoruojamų failų, išorinių duomenų bazių, įkeltų duomenų, paslapčių ar agento pokalbių istorijos. Reikalingas priklausomybes ir leidžiamus bandomuosius duomenis atkurkite atskirai pagal projekto instrukcijas.
Ką palyginti prieš redaguojant serverio kopiją?
Išsaugotą šaką ir įrašo identifikatorių palyginkite su pradine kopija, peržiūrėkite neįrašytus pakeitimus ir paprašykite Hermes patikrinti tikrąjį darbo katalogą. Tada būtent toje kopijoje paleiskite esamas projekto patikras.