Es salīdzinoši vēlu nonāku pie tēmas par attālās izstrādes vidi (pazīstamas arī kā mākoņa izstrādes vides). Galvenais iemesls ir tas, ka es neesmu strādājis izstrādes komandā vairāk nekā sešus gadus. Tomēr tagad es strādāju Loft Labs, un mums ir attālās izstrādes vides produkts: DevPod . Es vēlējos izprast mūsu piedāvāto vērtību, jo būšu FOSDEM un vadīšu DevPod stendu .
Kā bijušais izstrādātājs es spilgti atceros katra izstrādātāja izstrādes vides iestatīšanas sāpes. Manas karjeras sākumā arhitektam bija sāpīgi jākonfigurē mana izstrādes mašīna, tāpēc tā bija līdzīga viņa iestatījumam. Vēlāk es atkārtoti darīju to pašu saviem komandas locekļiem. Iespējamo neatbilstību apjoms, kas ietekmē attīstību, ir praktiski bezgalīgs: operētājsistēma, protams, SDK versija un garša, piemēram , Java Eclipse Temurin pret SapMachine, git āķi utt. Tas bija sviedri, darbs un asinis katrā projektā.
Gadu gaitā es redzēju dažas interesantas pieejas izstrādes vides reproducēšanai. Sākumā tie radās no virtuālajām mašīnām, pēc tam no konteineriem. Manuprāt, Vagrant bija pirmais rīks, kas pievērsa manu uzmanību: 2012. gadā es piedalījos sarunā, kurā runātājs minēja, ka viņš to izmantojis, lai uzstādītu mašīnas pirms treniņiem.
Lietojumprogrammu arhitektūras gadu gaitā ir ievērojami attīstījušās, kļūstot sarežģītākas un izsmalcinātākas. Pirms gadiem pastāvēja iespēja, ka vienīgā infrastruktūras atkarība bija SQL datu bāze. JVM ekosistēmā mums paveicās ar JDBC — API, kas darbotos visās SQL datu bāzēs. Viss, kas jums jādara, bija rakstīt standarta SQL, un jūs varētu konfigurēt datu bāzes gadījumu izpildes laikā. Izmantojot iegultās datubāzes, piemēram, Apache Derby un H2 , katram izstrādātājam nebija nepieciešams īpašs Oracle gadījums.
Laiki ir mainījušies. Nav nekas neparasts, ka lietotnēm ir nepieciešama SQL datubāze, NoSQL datu bāze, Kafka klasteris un daži papildu lietojumprogrammu pakalpojumi. Organizācijas, kas izstrādā šādas lietotnes, jau izmanto dažas ar konteineriem saistītas tehnoloģijas, piemēram , Docker vai Kubernetes, lai pārvaldītu šo sarežģītību.
Tomēr tas neatrisina sākotnējo problēmu: kā saskaņot IDE, tā spraudņus, SDK(-us), git āķus un visu pārējo? Jūs droši vien to uzminējāt no nosaukuma - Attālās izstrādes vides.
Ievadā es minēju, ka RDE sauc par mākoņa izstrādes vidēm. RDE galvenā ideja ir visu iespējamo glabāt mākonī un kopīgot to ar visiem izstrādātājiem. Turklāt jūs vēlaties, lai tie darbotos ar visizplatītākajiem mākoņa pakalpojumu sniedzējiem un visbiežāk izmantotajiem IDE. Kad parādās šāda vajadzība, ir pienācis laiks nozares dalībniekiem pulcēties pie standarta. Microsoft ieviesa izstrādes konteinera standartu savam VS Code Remove izstrādes spraudnim tieši šim nolūkam.
Izstrādes konteiners (vai saīsināti izstrādātāja konteiners) ļauj izmantot konteineru kā pilnvērtīgu izstrādes vidi. To var izmantot, lai palaistu lietojumprogrammu, atdalītu rīkus, bibliotēkas vai izpildlaikus, kas nepieciešami darbam ar kodu bāzi, un lai palīdzētu nepārtrauktai integrācijai un testēšanai. Izstrādātāju konteinerus var palaist lokāli vai attālināti, privātā vai publiskā mākonī, dažādos atbalsta rīkos un redaktoros.
Izstrādes konteinera specifikācijas mērķis ir atrast veidus, kā bagātināt esošos formātus ar kopīgiem izstrādes specifiskiem iestatījumiem, rīkiem un konfigurāciju, vienlaikus nodrošinot vienkāršotu, neorganizētu viena konteinera opciju, lai tos varētu izmantot kā kodēšanas vidi vai nepārtrauktai integrācijai un testēšanai. Papildus specifikācijas galvenajiem metadatiem, specifikācija arī ļauj izstrādātājiem ātri koplietot un atkārtoti izmantot konteinera iestatīšanas darbības, izmantojot līdzekļus un veidnes.
Konfigurācijas fails ir devcontainer.json
. Shēmas atsauci varat atrast šeit . VS Code, Visual Studio un IntelliJ produkti var izmantot failu devcontainer.json
. Pakalpojumu sniedzēja pusē to atbalsta GitHub Codespaces, CodeSandbox un DevPod.
DevPod ir risinājums, kas izmanto devcontainer.json
. Tas īsteno trīs galvenās īpašības:
DevPod ir izstrādāts tā, lai tas būtu lietotājam draudzīgs un vienkāršs, tādēļ tā lietošana ir vienkārša. Es nolēmu uzrakstīt šo ziņu, jo produkts mani pārsteidza un lai sakārtotu savas domas.
Pirmais solis ir pašas DevPod instalēšana. Es izmantoju Mac; tur ir Homebrew recepte.
brew install devpod
Pēc instalēšanas varat to palaist no CLI vai GUI. Sākumā es dodu priekšroku GUI, lai palīdzētu izprast pieejamās iespējas.
DevPod piedāvā pakalpojumu sniedzējiem: vietas, kur palaist konteinerus. Noklusējums ir Docker. Varat pievienot papildu pakalpojumu sniedzējus, tostarp mākoņa pakalpojumu sniedzējus un Kubernetes klasterus.
Šai ziņai es paturēšu Docker — es izmantoju OrbStack. Tagad par gaļu. Dosimies uz darbvietu izvēlnes vienumu. Ja esat jau izveidojis darbvietas, tām vajadzētu parādīties šeit. Tā kā šī ir mūsu pirmā vizīte, mēs to izveidosim. Noklikšķiniet uz pogas btn:[Izveidot darbvietu]. Izmēģināsim vienu no ātrās darbības piemēriem, ti , Rust. Mana izvēlētā IDE ir IntelliJ IDEA, taču jūs varat izvēlēties savu. Kad esat atlasījis attēlu, IDE un nodrošinātāju, noklikšķiniet uz Izveidot darbvietu.
Šajā brīdī DevPod lejupielādēs attēlu un atvērs projektu, kas darbojas OrbStack programmā IntelliJ.
No šī brīža mēs varam laimīgi sākt darbu pie mūsu Rust projekta, pārliecībā, ka katrs komandas dalībnieks izmanto vienu un to pašu Rust versiju.
Ņemiet vērā, ka pirmo reizi izmantojot šo iestatījumu, DevPod lejupielādēs arī JetBrains klientu. Tomēr tā ir vienreizēja lejupielādes aizkave.
Tas pats attiecas, piemēram, uz Git pirmsapstiprināšanas āķiem. Ja vēlaties izstrādāt citu IDE, atlasiet to palaišanas laikā, un viss ir kārtībā. Kad esat pabeidzis dienas darbu, apturiet konteineru. Ja strādājat mākonī, tas ietaupa naudu. Nākamajā dienā atsāciet konteineru un turpiniet darbu.
DevPod ir jauks rīks, kas atrodas jūsu rīku joslā, kas ļauj jūsu izstrādes komandai(-ām) bez problēmām koplietot vienu un to pašu iekārtas konfigurāciju. Šajā ievada emuāra ierakstā es parādīju nelielu daļu no tā, ko jūs varat darīt. Es aicinu jūs izmantot tās spēku, ja saskaraties ar neviendabīgu attīstības vidi.
Lai dotos tālāk: