Мен Remote Development Environments (булуттуу өнүктүрүү чөйрөлөрү деп да белгилүү) темасына салыштырмалуу кеч келдим. Негизги себеби, мен алты жылдан ашык иштеп жаткан командада иштебейм. Бирок, мен азыр Loft лабораториясында иштеп жатам жана бизде Remote Development Environment продукту бар:   . Мен   иштеткен   боло тургандыктан, мен биздин баалуулук сунушубузду түшүнгүм келди. DevPod DevPod стенди FOSDEMде  Проблема  Мурунку иштеп чыгуучу катары мен ар бир иштеп чыгуучунун өнүгүү чөйрөсүн түзүү азабын даана эстейм. Менин карьерамдын башында архитектор менин иштеп чыгуучу машинамды катуу конфигурациялашы керек болчу, ошондуктан ал анын орнотуусуна окшош болчу. Кийинчерээк мен өзүмдүн командамдын мүчөлөрүнө да ушундай кылдым. Өнүктүрүү процессине таасир этүүчү мүмкүн болгон карама-каршылыктардын масштабы дээрлик чексиз: Операция системасы, албетте, SDKлардын версиясы   даамы,   , Java's Eclipse Temurin vs SapMachine, git hooks ж.б. Бул ар бир долбоордо тер, эмгек жана кан болгон. жана мисалы  Көп жылдар бою мен өнүктүрүү чөйрөсүн кайра чыгаруу үчүн кызыктуу ыкмаларды көрдүм. Башында алар VMлерден, андан кийин контейнерлерден келип чыккан. Менимче, Вагрант менин көңүлүмдү бурган биринчи инструмент болду: мен 2012-жылы баяндамага катышканмын, анда спикер аны машыгуудан мурун машиналарды орнотуу үчүн колдонгонун айткан.  Колдонмонун архитектурасы жылдар бою кыйла өнүгүп, татаал жана татаал болуп калды. Бир нече жыл мурун, бир гана инфраструктуралык көз карандылык SQL маалымат базасы болгон. JVM экосистемасында биз JDBC, бардык SQL маалымат базаларында иштей турган API болгонубуз үчүн бактылуу болдук. Болгону стандарттуу SQL жазууну талап кылсаңыз, анда маалымат базасынын инстанциясын аткаруу убагында конфигурациялай аласыз.   жана   сыяктуу камтылган маалымат базалары менен ар бир иштеп чыгуучу үчүн атайын Oracle инстанциясы керек болгон эмес. Apache Derby H2  Заман өзгөрдү. Колдонмолор үчүн SQL маалымат базасы, NoSQL маалымат базасы, Кафка кластери жана бир нече кошумча колдонмо кызматтары керек болушу сейрек эмес. Мындай колдонмолорду иштеп чыккан уюмдар бул татаалдыкты башкаруу үчүн контейнерге байланыштуу кээ бир технологияларды,   , Docker же Kubernetes колдонуп жатышат. мисалы  Бирок, бул баштапкы маселени чечпейт: IDE, анын плагиндери, SDK(лар), гит илгичтери жана башка нерселерди кантип тегиздөө керек? Сиз аны Remote Development Environments деген аталыштан ойлосоңуз керек.  Өнүктүрүү контейнерлери  Кириш сөздө мен RDEлер булутту өнүктүрүү чөйрөлөрү деп аталарын айттым. RDEлердин негизги идеясы - булутта мүмкүн болгон нерселердин баарын сактоо жана аны бардык иштеп чыгуучулар менен бөлүшүү. Мындан тышкары, сиз алардын эң кеңири таралган Cloud провайдерлери жана эң көп колдонулган IDEлери аркылуу иштешин каалайсыз. Мындай муктаждык пайда болгондо, тармактын актерлору бир стандарттын айланасына чогула турган учур келди. Microsoft ушул максатта VS Code Remove иштеп чыгуу плагини үчүн Өнүгүү Контейнеринин стандартын демилгелеген.  Өнүктүрүү контейнери (же кыскача иштеп чыгуучу контейнер) контейнерди толук өзгөчөлөнгөн өнүктүрүү чөйрөсү катары колдонууга мүмкүндүк берет. Ал тиркемени иштетүү, коддук база менен иштөө үчүн зарыл болгон куралдарды, китепканаларды же иштөө убакыттарын бөлүү үчүн жана үзгүлтүксүз интеграцияга жана тестирлөөгө жардам берүү үчүн колдонулушу мүмкүн. Иштеп чыгуучу контейнерлерди жергиликтүү же алыстан, жеке же коомдук булутта, ар кандай колдоочу куралдарда жана редакторлордо иштетсе болот.  Иштеп чыгуу контейнеринин спецификациясы учурдагы форматтарды жалпы иштеп чыгуунун атайын жөндөөлөрү, куралдары жана конфигурациялары менен байытуунун жолдорун табууга умтулат, ошол эле учурда жөнөкөйлөштүрүлгөн, уюштурулбаган жалгыз контейнер опциясын камсыз кылуу - аларды коддоо чөйрөсү катары же үзгүлтүксүз интеграциялоо жана тестирлөө үчүн колдонсо болот. Спецификациянын негизги метадайындарынан тышкары, спецификация иштеп чыгуучуларга Функциялар жана Калыптар аркылуу контейнерди орнотуу кадамдарын тез бөлүшүүгө жана кайра колдонууга мүмкүнчүлүк берет.  --  Өнүгүү контейнерлери деген эмне?  Конфигурация файлы   болуп саналат. Схема шилтемесин   таба аласыз. VS Code, Visual Studio жана IntelliJ өнүмдөрү   файлын колдоно алышат. Провайдер тараптан GitHub Codespaces, CodeSandbox жана DevPod аны колдойт. devcontainer.json бул жерден devcontainer.json  DevPod менен тааныштыруу    —   рычагын колдонгон чечим. Ал үч негизги касиетти ишке ашырат: DevPod devcontainer.json  Ачык булак: сатуучунун кулпусу жок. Иштеп чыгуучулар үчүн иштеп чыгуучулар тарабынан курулган 100% акысыз жана ачык булак.  Кардар гана: Сервер тарапта орнотуунун кереги жок. Баштоо үчүн иш такта колдонмосун же CLI жүктөп алыңыз.  Пикирсиз: Каалаган инфра, каалаган IDE жана каалаган программалоо тили үчүн кайталануучу иштеп чыгуучу чөйрө.  DevPod колдонууга ыңгайлуу жана жөнөкөй болуп иштелип чыккан, аны колдонуу оңой. Мен бул постту жазууну чечтим, анткени бул продукт мага таасирленип, ойлорумду иретке келтирүү үчүн.  Биринчи кадам DevPod өзүн орнотуу болуп саналат. I'm on Mac; Homebrew рецепти бар.   brew install devpod  Орнотулгандан кийин, сиз аны CLI же GUIден иштете аласыз. Мен колдо болгон варианттарды түшүнүүгө жардам берүү үчүн, башында GUI'лерди жактырам.   DevPod провайдерлерге: контейнерлерди иштете турган жерлерди сунуштайт. Демейки Докер болуп саналат. Кошумча провайдерлерди, анын ичинде Cloud Провайдерлерин жана Kubernetes кластерлерин кошо аласыз.   Бул пост үчүн мен Dockerди сактап калам — мен OrbStack колдонуп жатам. Эми этке. Жумуш мейкиндиктеринин меню пунктуна баралы. Эгер сизде мурунтан эле жумушчу мейкиндиктери түзүлгөн болсо, алар бул жерде пайда болушу керек. Бул биздин биринчи иш сапарыбыз болгондуктан, биз аны түзөбүз. btn:[Жумуш мейкиндигин түзүү] баскычын басыңыз. Келгиле, тез баштоо мисалдарынын бирин,   , Rust, аракет кылалы. Менин тандоом IDE - IntelliJ IDEA, бирок сиз өзүңүздүкүн тандай аласыз. Сүрөттү, IDEди жана камсыздоочуну тандагандан кийин, Иш мейкиндигин түзүү баскычын чыкылдатыңыз.  б.а.  Бул учурда, DevPod сүрөттү жүктөп алып, IntelliJ ичинде OrbStackде иштеп жаткан долбоорду ачат.   Мындан ары, биз ар бир команда мүчөсү бир эле Rust версиясын колдонот деп ишенип, Rust долбоорубуздун үстүндө иштей баштайбыз.  Бул жөндөөнү биринчи жолу колдонгонуңузда, DevPod JetBrains кардарын да жүктөп алаарын эске алыңыз. Бирок бул бир жолку жүктөө кечигүү.   Мисалы, Git алдын ала жасалган илгичтерге да тиешелүү. Эгер сиз башка IDE ичинде иштеп чыгууну кааласаңыз, аны ишке киргизүү убагында тандаңыз, ошондо сиз жакшысыз. Күнүмдүк жумушуңуз бүткөндөн кийин, контейнерди токтотуңуз. Эгер сиз булутта иштеп жатсаңыз, анда ал акчаны үнөмдөйт. Эртеси күнү контейнерди кайра иштетип, жумушуңузду улантыңыз.  Корутунду  DevPod - бул сиздин инструмент куруңуздун айланасындагы жакшы курал, ал иштеп чыгуучу топ(лор)уңузга бир эле машина конфигурациясын эч кыйынчылыксыз бөлүшүүгө мүмкүндүк берет. Бул киришүү блогунда мен сиз кыла ала турган нерселердин бир аз бөлүгүн көрсөттүм. Мен сизге гетерогендүү өнүгүү чөйрөсүнө туш болсоңуз, анын күчүн колдонууга чакырам.   Андан ары баруу үчүн:   Өнүктүрүү контейнерлери   DevPod - Open Source Dev-Environments-As-Code   Gitpod менен Codespaces менен Кодер менен DevPod: 2024 салыштыруу

Read all my posts!

Read My Stories

Follow @nicolas_frankel on Twitter

Бул аудио окуянын түпнуска тилинде даярдалган!

Алыстан иштеп чыгуу DevPod менен жөнөкөйлөштүрүлгөн - Акысыз, ачык булактуу курал

About Author

КОММЕНТАРИЙ

ТАГИП АЛУУ

БУЛ МАКАЛА БЕРИЛГЕН

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps