Palyginti vėlai priėjau prie nuotolinės kūrimo aplinkos (taip pat žinomos kaip debesų kūrimo aplinkos) temos. Pagrindinė priežastis – daugiau nei šešerius metus nedirbu kūrimo komandoje. Tačiau dabar dirbu „Loft Labs“ ir turime nuotolinės kūrimo aplinkos produktą:   . Aš norėjau suprasti mūsų vertės pasiūlymą, kai dirbsiu   ir valdysiu   . „DevPod“ FOSDEM DevPod stendą  Problema  Kaip buvęs kūrėjas, puikiai prisimenu kiekvieno kūrėjo kūrimo aplinkos nustatymo skausmą. Mano karjeros pradžioje architektas turėjo skausmingai konfigūruoti mano kūrimo mašiną, todėl ji buvo panaši į jo sąranką. Vėliau ne kartą tą patį dariau savo komandos nariams. Galimų neatitikimų, turinčių įtakos plėtrai, mastas yra beveik begalinis: operacinė sistema, žinoma, SDK versija   skonis,   , Java Eclipse Temurin vs SapMachine, git kabliukai ir tt Tai buvo prakaitas, triūsas ir kraujas kiekvienam projektui. ir pvz.  Bėgant metams pamačiau keletą įdomių kūrimo aplinkų atkūrimo būdų. Iš pradžių jie kilo iš VM, vėliau iš konteinerių. Manau, kad „Vagrant“ buvo pirmoji priemonė, kuri patraukė mano dėmesį: 2012 m. dalyvavau pokalbyje, kuriame pranešėjas minėjo, kad jį naudojo mašinoms nustatyti prieš treniruotes.  Bėgant metams programų architektūros labai pasikeitė, tapo sudėtingesnės ir sudėtingesnės. Prieš daugelį metų buvo tikimybė, kad vienintelė infrastruktūros priklausomybė buvo SQL duomenų bazė. JVM ekosistemoje mums pasisekė, kad turime JDBC – API, kuri veiktų visose SQL duomenų bazėse. Viskas, ką jums reikėjo padaryti, tai parašyti standartinį SQL, ir jūs galite konfigūruoti duomenų bazės egzempliorių vykdymo metu. Naudojant įterptąsias duomenų bazes, tokias kaip   ir   , nereikėjo kiekvienam kūrėjui skirto Oracle egzemplioriaus. Apache Derby H2  Laikai pasikeitė. Neretai programoms reikia SQL duomenų bazės, NoSQL duomenų bazės, Kafka klasterio ir kelių papildomų taikomųjų programų paslaugų. Tokias programas kuriančios organizacijos jau naudoja tam tikras su konteineriais susijusias technologijas,   , „Docker“ arba „Kubernetes“, kad galėtų valdyti šį sudėtingumą. pvz.  Tačiau tai neišsprendžia pradinės problemos: kaip suderinti IDE, jo papildinius, SDK (-us), git kabliukus ir visa kita? Tikriausiai tai atspėjote iš pavadinimo „Nuotolinės kūrimo aplinkos“.  Vystymo konteineriai  Įžangoje minėjau, kad RDE vadinamos debesų kūrimo aplinkomis. Pagrindinė RDE idėja yra saugoti viską, ką galite, debesyje ir bendrinti su visais kūrėjais. Be to, norite, kad jie veiktų su labiausiai paplitusiais debesies tiekėjais ir dažniausiai naudojamomis IDE. Kai atsiranda toks poreikis, laikas pramonės veikėjams susiburti prie standarto. „Microsoft“ sukūrė „Development Container“ standartą savo „VS Code Remove“ kūrimo papildiniui būtent šiuo tikslu.  Kūrimo konteineris (arba sutrumpintai dev konteineris) leidžia naudoti konteinerį kaip visų funkcijų kūrimo aplinką. Jis gali būti naudojamas programai paleisti, atskirti įrankius, bibliotekas ar vykdymo laikus, reikalingus darbui su kodų baze, ir padėti nuolatiniam integravimui ir testavimui. Dev konteinerius galima paleisti vietoje arba nuotoliniu būdu, privačiame arba viešajame debesyje, naudojant įvairius pagalbinius įrankius ir redaktorius.  Kūrimo sudėtinio rodinio specifikacija siekia rasti būdų, kaip praturtinti esamus formatus bendrais specifiniais kūrimo parametrais, įrankiais ir konfigūracija, kartu suteikiant supaprastintą, nesuderintą vieno konteinerio parinktį, kad juos būtų galima naudoti kaip kodavimo aplinkas arba nuolatiniam integravimui ir testavimui. Be pagrindinių specifikacijos metaduomenų, specifikacijos kūrėjams taip pat leidžia greitai bendrinti ir pakartotinai naudoti sudėtinio rodinio sąrankos veiksmus naudojant funkcijas ir šablonus.  –  Kas yra kūrimo konteineriai?  Konfigūracijos failas yra   . Schemos nuorodą galite rasti   . VS Code, Visual Studio ir IntelliJ produktai gali panaudoti   failą. Teikėjo pusėje tai palaiko „GitHub Codespaces“, „CodeSandbox“ ir „DevPod“. devcontainer.json čia devcontainer.json  Pristatome „DevPod“.    yra sprendimas, kuriame naudojamas   . Jis įgyvendina tris pagrindines savybes: „DevPod“ devcontainer.json  Atviras šaltinis: nėra pardavėjo užrakto. 100% nemokamas ir atviras šaltinis, sukurtas kūrėjų kūrėjams.  Tik klientas: nereikia serverio sąrankos. Norėdami pradėti, atsisiųskite darbalaukio programą arba CLI.  Be nuomonės: kartojama kūrimo aplinka bet kokiai infrastruktūrai, bet kokiai IDE ir bet kuriai programavimo kalbai.  „DevPod“ sukurtas taip, kad būtų patogus ir nesudėtingas, todėl juo naudotis būtų lengva. Nusprendžiau parašyti šį įrašą, nes likau sužavėta produktu ir susitvarkyti savo mintis.  Pirmasis žingsnis yra įdiegti patį „DevPod“. Aš naudoju „Mac“; yra Homebrew receptas.   brew install devpod  Įdiegę galite jį paleisti iš CLI arba GUI. Iš pradžių renkuosi GUI, kad būtų lengviau suprasti galimas parinktis.   „DevPod“ siūlo teikėjams: vietas, kur paleisti konteinerius. Numatytasis yra Docker. Galite pridėti papildomų teikėjų, įskaitant „Cloud Providers“ ir „Kubernetes“ grupes.   Šiam įrašui pasiliksiu „Docker“ – naudoju „OrbStack“. Dabar apie mėsą. Eikime į darbo sričių meniu elementą. Jei jau sukūrėte darbo sritis, jos turėtų būti rodomos čia. Kadangi tai mūsų pirmasis apsilankymas, mes jį sukursime. Spustelėkite mygtuką btn: [Sukurti darbo sritį]. Pabandykime vieną iš greitos pradžios pavyzdžių,   Rust. Mano pasirinktas IDE yra IntelliJ IDEA, bet jūs galite pasirinkti savo. Pasirinkę vaizdą, IDE ir teikėją, spustelėkite Kurti darbo sritį.  ty  Šiuo metu „DevPod“ atsisiųs vaizdą ir atidarys projektą, kuris veikia „IntelliJ“ „OrbStack“.   Nuo šiol galime su džiaugsmu pradėti dirbti su savo Rust projektu, būdami tikri, kad kiekvienas komandos narys naudoja tą pačią Rust versiją.  Atminkite, kad pirmą kartą naudojant šią sąranką, „DevPod“ taip pat atsisiųs „JetBrains“ klientą. Tačiau tai yra vienkartinis atsisiuntimo delsimas.   Tas pats pasakytina apie, pavyzdžiui, Git išankstinio įsipareigojimo kabliukus. Jei norite kurti kitoje IDE, pasirinkite jį paleidimo metu ir viskas. Baigę dienos darbus, konteinerį sustabdykite. Jei naudojate debesį, sutaupysite pinigų. Kitą dieną atnaujinkite konteinerį ir tęskite darbą.  Išvada  „DevPod“ yra puikus įrankis aplink jūsų įrankių juostą, leidžiantis jūsų kūrimo komandai (-ėms) be vargo dalytis ta pačia įrenginio konfigūracija. Šiame įvadiniame tinklaraščio įraše parodžiau nedidelę dalį to, ką galite padaryti. Raginu jus panaudoti jos galią, jei susiduriate su nevienalyte vystymosi aplinka.   Norėdami eiti toliau:   Vystymo konteineriai   „DevPod“ – atvirojo kodo „Dev-Environments-As-Code“.   Gitpod vs Codespaces vs Coder vs DevPod: 2024 m. palyginimas

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Šis garso įrašas sukurtas originalia istorijos kalba!

Nuotolinis kūrimas paprastas naudojant „DevPod“ – nemokamas atvirojo kodo įrankis

About Author

KOMENTARAI

PABAIGTI ŽYMES

ŠIS STRAIPSNIS BUVO PRISTATYMAS

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps