Do you really need your test environment? [ukr]

Всім привіт, друзі! Радий, що ви завітали на конференцію fwdays і радий бути одним із спікерів у цей онлайн-день. Перед тим, як почати, було послідовно привітатись. Мене звати Влад Кампов, я люблю музику і біг. Настільки, що десь років шість тому я зі своєю групою записав музичний альбом, а минулого року пробіг Берлінський марафон – тобто 42 кілометри. Також я ціную меми настільки, що у мене є свій канал в Телеграмі, який так і називається – "Меми, які мені сподобались". Я також є одним із ведучих подкасту ЖПТ, який є на Ютубі і інших подкаст-платформах, де ми обговорюємо все, що стосується IT і теми навколо.

Також я люблю працювати. Наразі я Senior UI-інженер у компанії Netflix, а до цього займав роль front-end engineering manager у компанії VIX. До цього працював десь. Тут я маю підкреслити, що теми моєї доповіді ніяким чином не стосуються розробок моєї поточної чи попередніх компаній, з якими я працював, чи з якими я мав відносини. Сьогодні я обговорюю тільки загальні інженерні концепти. Також всі думки є моїми власними і не репрезентують позицію моєї поточної чи минулих компаній або роботодавців.

Також тут буде ще багато англіцизмів, але я спочатку зроблю це. Сподіваюся, що все буде нормально. Сьогодні я би хотів поговорити з вами про оточення або середовища у веб-розробці. Давайте почнемо з такого. Як часто вам доводилося чути, «Хм, а воно працює у мене на машині?» Мені здається, що сьогодні вже це можна переформулювати на «Хм, а воно працює на стейджингу?» Таким чином, сьогодні я хочу поговорити про організацію середовищ і проблеми, які з цим пов'язані. Звісно, кожна компанія по-своєму маніпулює процесом розміщення своїх продуктів у вебі, процесом CI/CD, розробки і деплою. Але найбільш поширеним в індустрії є наступний підхід: чотири середовища – локальне, тестове, стейджинг і продакшн.

Локальне – це код, що запускається на вашому комп'ютері. Тут все зрозуміло – це середовище для розробки, де ми вносимо зміни і робимо все, що можемо уявити. Потім ми пушимо зміни в репозиторій контролю версій, такий як GitHub, Bitbucket, GitLab або інший. Слід сказати, що деякі великі ентерпрайз-компанії іноді використовують або окремі віртуальні машини, або віддалене підключення до фізичного комп'ютера в офісі. Але це трапляється не часто і, фактично, представляє собою таке саме локальне середовище, як на вашому комп'ютері.

Тестове – це середовище, в яке потрапляють зміни з основної гілки контролю версій, коли вони готові до тестування. Тут тестувальники, дизайнери, продакт-менеджери або ви як розробник проводите мануальне або автоматичне тестування. Слід відзначити, що часто тут використовуються нереальні дані з різних причин, таких як економія місця або відсутність потреби використовувати реальні дані розробникам. Це, до речі, часто призводить до проблем у майбутньому.

Стейджинг – це місце, куди потрапляє версія, яка є кандидатом для розгортання в продакшн. Тобто тоді, коли ми готові ритуально розмістити нашу нову версію продукту для всіх користувачів. Тут проводяться останні мануальні і автоматичні тестування, і після цього ми просто натискатимемо зелену кнопку для деплою в продакшн. Тут вже все частіше використовуються реальні дані, тобто база даних синхронізується з продакшном.

Продакшн – це версія продукту, яка вже доступна всім користувачам і використовує реальну базу даних, реальні дані, реальні візуальні сценарії і так далі. Розібравшись з термінологією, пропоную розібратись, як найчастіше в індустрії відбувається процес розробки і деплойменту. Як код або наші зміни попадають з одного інверементу в інший.

З локальним все зрозуміло. Ми стягуємо репозиторій з умовного bitbucket GitHub чи Gitlab з ремову системи контролю версій від основної гілки, що зазвичай це може бути девелоп або, не знаю, мейн в деяких компаніях. Ми робимо нову гілку і коли зміни готові, ми пушимо це на ремову системи контролю версій, тобто відкриваємо пул реквест на те, щоб змержити ці зміни назад в основну гілку – в девелоп. Зазвичай в індустрії прийнято запускати тести або репозиторів, будь-які інші перевірки типу лінтингу на кожен пул реквест, на кожну зміну, яка має бути змержена в основну гілку. І деколи на деяких пул реквестах ви можете побачити таке явище як deployment preview, тобто окремо задеплоєну версію вашого продукту, яка скоріш за все користується якимись тестовими даними.

Як код опиняється на тест-енвероменті? Є також різні підходи, але найбільш тривіальним – це коли ми нашу development brunch мерджимо в test brunch, або просто залишаємо тег з новою версією на одному з комітів development brunch, і потім мануально або автоматично розміщуємо нову, тобто останню версію десь в конфігурації, що і деплоїть нам test event. Питання, що ж далі із staging-ом і з production-ом? Насправді так само. Процес дуже схожий на те, як це відбувається із test event, тобто ми тегаємо або мерджимо це в спеціальну brunch, і різниця тільки в різних назвах гілок або тегах. Трошки складніше, коли нам треба доставити hotfix у production, але сьогодні ми не про це говоримо.

Поверхнево – це все. Але в чому все ж таки цинус? Чому я вам все це розповідаю? З моєї точки зору, такий стандартний підхід, він занадто обережний і насправді створює більше проблем, ніж врішує і сповільнює процес розробки. Збільшується час, за який нові теги, або виправлені помилок можуть зупинитись на продакшені від моменту розробки. Такий метод заставляє нас багато думати перед кожним релізом і робити з цього якийсь такий ритуал. Хоча насправді реліз для кожного розробника має бути щось настільки повседенне, як просто ранкова кава.

Чи ви вважаєте, що дійсно код має настоятись перед тим, як юзери його побачать? Основні чинники, що заважають ефективності цього сетапу – це, по-перше, велика ціна, що нам треба мейнтейнити кожен з енвайроментів, і насправді ціна на те, що наші зміни і фікси просто довше дістаються продакшену від моменту розробки. Це неконсистентність даних через те, що дуже часто на test event, наприклад, ми використовуємо або давно синхронізовану продакшн-базу даних, або анонімізовані дані, або просто якісь mock-дані, і ваш код, попавши в продакшн, може не спрацювати так, як він працює у test event. Дуже часто так. Дуже часто це саме через ті самі причини.

False positive-тести, тому що на реальних даних тести можуть не пройти. Насправді все, що на продакшн. За кожен енвайронмент нам треба платити, його мейнтейнити, його підтримувати в актуальному стані, синхронізувати дані, ранити на кожному з них тести. І це просто створює набагато більше проблем, які можливо можна було б вирішити. Власне, про альтернативний підхід організації, середовищ і розробки я і хочу сьогодні поговорити. Як можна розроблювати тільки використовуючи продакшн-енвайромент?

І як можуть fisher-togles та АБ-тести спростити нам життя настільки, що у нас навіть не буде потреби використовувати інші середовища? Тема насправді доволі складна. Я вже відчуваю, що у мене буде дуже багато запитань, на які я маю знайти відповіді, але у мене тут всього 30 хвилин. Тому давайте я спробую структурувати цю доповідь так, щоб хоча б поверхнево пройтись по всім важливим пунктам і розкрити цю тему. Розпочнемо з fisher-togles, також відомих як flier flags. Що таке fisher-togles ? Це інструмент, який дозволяє сховати або показати певну фічу на будь-якому середовищі. Їх часто використовують як на фронтенді, так і на бекенді. Сьогодні давайте зосередимося на фронтенді і розглянемо невеликий приклад.

Уявімо, що частина нашого продукту - це проста репрезентація даних, які надходять з бекенду у форматі JSON. Бізнес вимагає підвищити привабливість певного посилання, наприклад, на подкаст з GPT, і ми хочемо вплинути на його click-through-rate (CTR). Для цього ми співпрацювали з дизайнером та менеджером, щоб знайти найкращий спосіб показати це посилання та збільшити кількість кліків. Припустимо, ви успішно завершили розробку і вдалося імплементувати цю карточку. Без використання fisher-togles вам доведеться чекати на апрув від різних осіб, перш ніж ви зможете реалізувати та показувати зміни на інших середовищах. Але є шлях, яким ми можемо спростити цей процес.

Якщо ми використовуємо fisher-togles, можемо легко контролювати, коли функціональність повинна бути видимою або прихованою. Наприклад, ми можемо використовувати fisher-togles для визначення, чи повинна бути видимою нова функція чи залишити стару. Це дозволяє нам реалізувати зміни один раз і, якщо щось піде не так, просто змінити конфігурацію, а не робити редеплой. Такий підхід зекономить час і уникне непередбачених проблем у продакшені. Також важливо мати окремий domain-сервер, який відповідає за ці fisher-togles та інші конфігурації. Це дозволяє нам незалежно деплоїти цей сервер, окремо від основних середовищ, що робить управління fisher-togles більш гнучким та надійним. Таким чином, використання фічер-тоглів може значно полегшити розробку та управління функціональністю на різних середовищах.

На цю тему є багато книжок, презентацій і статей, тому я дуже рекомендую вам просто гуглити це, використовуючи ключові слова "fisher-togles" або "flier flags". Ви знайдете щось, що резонує з вами, і можливо навіть спробуєте це на своєму проєкті. А ми перейдемо далі, щоб поговорити про те, що таке АБ-тести. АБ-тести, якщо говорити простими словами, це fisher-togles на стероїдах. Дуже часто вони використовуються в маркетингових компаніях для вимірювання впливу якої-небудь фічі, коли вона з'являється на продакшені, на маркетингові та бізнес-метрики.

У випадку АБ-тестів підхід до fisher-togles змінюється в тому випадку, якщо наше значення "True" або "False" не є статичним, але представляє собою резолюцію того, до якої аудиторії відноситься конкретний користувач. Наприклад, чи є наш користувач учасником курсу, або чи проживає наш користувач в Бразилії. Таким чином, умови АБ-тестів можуть враховувати різний контекст, такий як мова на комп'ютері чи браузер користувача. АБ-тести дають можливість визначити, коли функціональність має бути видимою або прихованою на основі різних умов, таких як локація, мова, браузер, випадковий вибір аудиторії тощо. Наприклад, можемо показувати новий дизайн інформаційних карток на сайті залежно від локації чи інших умов.

Щоб зробити це ще зручніше, використовуються статичні overrides. Вони дозволяють переписувати конфігурацію в рантаймі, прямо на продакшені. Це може бути корисно, наприклад, для зміни значень фічер-тоглів чи АБ-тестів прямо в посиланні без необхідності редагування конфігурації в базі даних чи на доменному сервері. Усе це дозволяє вам поєднувати різні правила та умови, щоб визначити, коли функціональність повинна бути включена чи виключена. Такий підхід дозволяє гнучко керувати функціональністю в різних середовищах та в реальному часі.

Маючи таку можливість, ви також можете виявити, чи ви використовуєте який-небудь Chrome extension, який взаємодіє з доменним сервером. Завдяки цій функції ви можете просто натискати на клік, змінювати URL і перезавантажувати сторінку для зручного використання статичних оверайдів і ще швидше ділитися посиланнями. Отже, тут все просто, чи не так? Ми вставили значення в URL, нове значення нашого фічеру або AБ тесту, і можемо переглядати трошки іншу версію продукту, якщо потрапляємо в цю аудиторію. А що, якщо ми підемо трошки далі? Що, якщо ми зможемо використовувати статичні overrides не лише для фічерів або AБ тестів, але і для статичних вандлів, тобто для частин нашого JavaScript коду, який приходить з URL. Таким чином, ми зможемо переглядати, як наша нова або навіть локальна версія запускається в контексті всього продакшену, не зважаючи на те, що ми її ще не задеплоїли.

Але як це буде працювати, набагато легше уявити в концепції мікрофронтендів, тому давайте поговоримо про мікрофронтенди. Мікрофронтенди - це мікросервісний підхід для побудови інтерфейсів. Простими словами, це коли на одній сторінці працюють декілька окремо ізольованих аплікацій, які не залежать одна від одної і деплоюються окремо. Загалом цей концепт дозволяє використовувати на одній сторінці React, Vue, Angular і все, що ви можете замонтувати в окремий div елемент на сторінці. Проте, люди зазвичай віддають перевагу використанню одного фреймворку або бібліотеки, щоб уникнути розбіжностей і повторного використання деяких частин коду.

Наприклад, ви можете використовувати свої бандли React, і одна версія React буде використовуватися для всіх бандлів на сторінці. І саме через це небажано використовувати мікрофронтенди у вигляді iFrame, оскільки тоді вам доведеться включити всі залежності прямо в вашу аплікацію, і ви не досягнете необхідної ефективності. Так ви досягнете ізоляції, але можливо, крім цього, ви можете йти далі і просто дістати цей iFrame.

Але чому це важливо в контексті нашої теми? У зазначених умовах, коли існують різні мікрофронтенди, я можу подивитися, як нова версія одного мікрофронтенду веде себе в контексті інших, не змінюючи версії інших. І таким чином я можу подивитися, чи нічого не ламається, якщо все ж таки є взаємозв'язок між мікрофронтендами і різними фічами. З урахуванням того, що бандл ми так чи інакше завантажуємо, ми можемо спробувати просто підмінити його посилання за допомогою статичних оберегів. Давайте тепер спробуємо об'єднати все це. Мікрофронтенди дають нам можливість ізолювати окремі частини аплікації як в розробці, так і в деплої. Кожен мікрофронтенд повинен мати свою версію і окремий CI/CD, хоча фундаментальні конфігурації можуть базуватися на спільних або бути просто однаковими. fisher-togles, дозволять нам контролювати, яка версія нової фічі або продукту буде показана юзеру. І якщо треба, ми зможемо rollback, тобто відкатуватись в нових рішеннях. Також AБ тести дають нам можливість показувати фічі не просто включаючи чи виключаючи, а в залежності від того, де знаходиться юзер, якою мовою він говорить і в яку аудиторію він підпадає.

Статичні override дають нам можливість подивитись на версію продукту, будучи в іншій аудиторії, в іншому продакшені і підмінити бандл. Таким чином через статичні override ми можемо навіть реалізувати deployment preview. Тобто, в принципі, нам не треба вже 1M. Більше того, навіщо нам стейджинг, якщо ми можемо просто подивитись на те, як нова фіча буде виглядати вже на продакшені, якщо ми просто включимо фічер того вже на реальних даних. І чому б нам прям там не запускати тести.

Зібравши всі ці факти докупи, а можливо, нам взагалі треба тільки продакшн, давайте поговоримо, які проблеми можуть бути, якщо використовувати тільки один environment. По-перше, доступ до продакшн-даних. Так, деякі компанії дуже критично відносяться до того, що юзери мають доступ до продакшн-даних. І цю проблему можливо можна вирішити використовуючи тестові дані прямо впроді, тобто створюючи якийсь тестові entity прямо в продакшн-базі даних, які, можливо, будуть доступні вам тільки, якщо у вас є певні permissions. Що, якщо ми положимо прод? Тут нам допоможуть gradual rollout, або автоматичний fallback для якогось FHA, або все ж таки, якийсь такий кібернетичний load balancer, який буде автоматично хостити дві версії нашого доменного сервісу, якщо ми вже говоримо про backend. Можливо, є ще проблема security. Деякі дуже розумні юзери можуть зрозуміти, що ми можемо використовувати статичні override і спробувати отримати доступ до якихось нових FHA раніше до релізу. Це деколи зовсім не критично, деколи це критично дуже, коли особливо компанія трейдиться на великих біржах. Це можна вирішити використовуючи ті самі permissions, або кодувавши конфігураційний файл з featured-оглами, який приходить нам з backend.

Ну і насправді може бути ще й більше мінусів, тому ви будь ласка, приносьте всі свої думки на Q&A сесію, ми з вами обов'язково поговоримо. Бо якщо ви вже дивитесь це в записі, то залишайте це в коментарях. Буде дуже цікаво. В чому ж плюси? По-перше, це просто неймовірна економія на інфраструктурі. У нас залишається тільки один environment, тому можна сказати, що в три рази менше ми витрачаємо на умовний AWS. По-друге, це робота з реальними даними в реальному оточенні, з якими вже взаємодіє юзер. Тобто ви відразу можете зрозуміти, як ваша нова фіча, нова репрезентація даних, буде працювати з реальними даними на продакшені.

І ми прибираємо фактор false positive тестів, тому що всі наші тести будуть запускатись уже в контексті продакшн енверонменту. І окрім того, мануальні тести, тобто всі наші product managers і дизайнери зможуть подивитись на те, як ми імплементували фічу, і їм не треба буде три рази перевіряти на кожному з енверонментів, чи все окей. По-третє, якщо ми почнемо все деплоїти одразу, як тільки воно з'явилося в основній гілці, у нас буде тільки продакшн, у нас прибираються ритуали деплоєменту раз в два тижні, чи раз в місяць. Тобто все одразу опиняється в продакшені і не накопичується, і відпадає проблема gradual rollback, якщо вона дуже потрібна.

Більше того, ми можемо використовувати fisher-togles або АБ-тести для того, щоб сховати якусь нову фічу, яка поламана. Отже, фікси ви хочете задеплоїти якомога швидше, скоріше за все, а нові фічі, можна сховати під якимось if-ом, щоб вони почекали до того, коли все буде готово, щоб юзер їх побачив. І в кінці кінців ви зможете всім розповідати про те, що ви мерджуєте прямо в мастер, і прямо з головної гілки через декілька хвилин ваші зміни бачать 2 мільйони юзерів, чи скільки юзерів у вас є на продукту. Ну хіба не круто?

Але це все доволі поверхнево. Давайте подивимось на демо, як можливо буде виглядати розробка вашого продукту, якщо ви імплементуєте або тести, або fisher-togles, static override і deployment прямо в production. Я створив не величкий репозиторій, який працює на yarn workspace, тому, будь ласка, використовуйте yarn, ви можете побачити yarn log в корні цього файлу. Всі пекеджі в цьому workspace лежать в packages, і, звичайно, перед тим як працювати з цим репозиторієм, будь ласка, запустіть yarn install. У мене продукт вже запущений, тобто я вже запустив yarn start, але перед цим давайте подивимось на те, як виглядає структура папки. У нас є 5 пекеджів, один сервер, який я сюди запхнув просто для того, щоб він перевикористовував один і той самий, одні й ці самі node-модулі, і три мікрофронтенди, які об'єднані одним рутом, тобто в руці живе конфігурація, це два окремих мікрофронтенди. Один хедер, перший мікро фронтенд, який буде відображатись у нас ліворуч, це буде невеличкий просто список, таймлайн, як готуватися до презентації, і другий мікро фронтенд, це безпосередньо наші картки, з якими ми вже взаємодіяли презентації, які я вже показував.

Все це знаходиться на localhost 9000, або ви можете, якщо ви бачите вже задеплоєну версію, в кінці кінців я вам дам qr-код на цій репозиторії, воно все задеплоєне за цим посиланням. Так виглядає зараз наш продукт, і якщо ми використаємо static override, тобто додамо query параметр з json URL, ми одразу побачимо нову версію продукту. Як це виглядає? Як я вже казав, у нас з контексту підгрижаються fisher-togles, і використовується просте значення isNewCardAvailable у вигляді if для того, щоб показати нову або стару версію. Якби нам захотілося ще показати якусь нову фічу, скажімо, якби нам захотілося показати якусь нову фічу, то я би спочатку пішов редагувати конфігурацію фічер тоглів. В цьому проєкті у мене нема бази даних, тому я використовую просту відповідь за API у вигляді JSON. Тобто вона ніяк не конфігурується статично, але всі, я думаю, розуміють, що для цього можна створити окремий UI з окремою базою даних і зробити це все простіше. І сюди я просто додам новий фічер тогл. Знаючи, що цей сервер автоматично оновиться, я піду одразу в свій компонент з другим мікрофронтендом і я знаю, що я одразу можу використати цей фічер тогл тут, що насправді було б класніше використовувати якимось генерованим типом або YANAM, але знову ж таки це тестовий проєкт, ми просто використовуємо це так. Тож подивіться, як воно може працювати.

І використовуємо цей fisher-togles у вигляді змінної. Цю змінну ми використовуємо для того, щоб показати нову картинку. І це нехай просто буде якийсь імедж з посиланням, яке ми візьмемо звідси. Використаємо це посилання тут, напишемо якийсь Alt і подивимось на те, що зараз звичайно локально недоступна нам ця нова фіча через те, що fisher-togles вимкнений. Але якщо ми візьмемо назву цього fisher-togles і створимо з цього об'єкт, зробимо з цього encode json stringify і те, що в нас вийшло, ми банально вставимо в URL значення overrides, ми можемо побачити гориллу. Звичайно, що стара фіча сховалась, бо ми прибрали fisher-togles.

Давайте подивимось тепер, як виглядає процес пушу цих змін. І, мабуть, деплайменту. Я повертаюсь в репозиторії. Я хочу переконатися, що ця фіча буде закомічена і буде закомічена в окремій бранчі. Я це запушу. Благо, gidhub мені відразу дає посилання на створення, по реквесту. І я його створюю. Завдяки тому, що я використовую версію для цієї тестової версії продукту, відразу у мене з'являється можливість deployment preview. Але, через те, що це монорепозиторій і мікрофронтенди, то мені не треба deployment preview у тривіальному його вигляду. Тобто, якщо я натисну на якесь посилання, яке мені дасть версель, то, скоріш за все, воно не відобразиться в тому вигляді, який мені треба. Мені доведеться використати продакшн-версію самого рута нашого мікрофронтенду, там, де живе конфігурація всіх мікрофронтендів. І тут я буду підмінювати посилання на новий бандл окремого мікрофронтенду вже з новим FeatureToggle.

Для цього, поки воно доплоється, я почну створювати ось цей об'єкт. Я вже сказав, що можна в теорії зробити якийсь більш зручний спосіб, ніж робити це мануально, але поки це буде мануально. І, повернувшись до pull request, то я можу подивитися, що нова версія нашого бандлу задеплоєна за конкретним посиланням, яке я і скопіюю. Але вона лежить не в руці, а вона лежить в comp of mfe2.js Ось тут. Вставляю це посилання сюди, знову роблю json stringify і значення цього всього посилання я просто копіюю і вставляю сюди в overrides. І бачимо нашу зміну разом з включеним fisher-togles. Тобто, якщо ми підемо в url і її виключимо, то її не буде, але ми все ще будемо отримувати останню версію.

Якщо ми повернемось в pull request, я можу просто змерджити це. Воно зупиниться в main і одразу польється на production. Тобто, зараз ми зможемо прибрати оцей override бандла і воно буде на production. Але поки воно це робить, я повернусь на свій локальний environment. Стягну зміни і спробую запустити тільки один workspace, тільки перший microfrontend. Для того, щоб показати, що насправді ми можемо розроблювати в контексті production environment, тільки використовуючи локальний бандл.

Повернувшись назад на production, я знову ж таки хочу змінити бандл, але в цей раз це буде MFE1. І в цей раз я поставлю посилання на локальний сервер. Копіювавши те, що у нас вийшло, я використаю це значення в search параметрі override. І тепер я можу переконатись, що MFE1 використовується з локального environment. Тобто, якщо я поміняю процес готування з Andrew Mania на щось, або захочу додати ще один, то ці зміни одразу з'являться на production, використовуючи наш локальний бандл. Ну хіба це не круто? Мені здається, що такий сетап пришвидшує просто в рази розробку, deployment і момент того, як наші зміни з локального environment з'являються в production.

Повертаючись до презентації, я маю сказати, що готуючи цю доповідь, я впевнений, що я не затронув всі можливі аспекти цієї проблеми. Можливо, там більше плюсів, а також і мінусів. Тому я буду радий, якщо ви залишите ваші коментарі і задасте запитання. Але варто сказати, що я бачив деякі компанії, які використовують подібний підхід. Одна з них представлена на українському ринку. І це компанія vix.com. Також я створив цей тестовий проект на Github. Він доступний для того, щоб показати дуже поверхнево і на простому прикладі, як це може бути використано. Тому, будь ласка, бавтесь з ним. Ось вам посилання. Ви можете його знайти на моєму бенто. Залишайте там ваші коментарі у issue, або, знову ж таки, буду радий вашим запитанням після цієї доповіді.

Я буду щиро радий будь-яким вашим коментарям або фідбеку, адже саме так ми знайдемо істину і зрозуміємо, чи такий сетап підходить. Але варто сказати, що there is no silver bullet. Нема ідеального підходу, який вирішить всі питання. Впевнений, що є компанії, яким не підійде таке. Також на моє бенто, окрім посилання на цей Github проект, ви можете знайти посилання на подкаст ЖПТ. І все ж таки, послухайте про те, як ми з моїм другим колегою Владом Сидоренко розсуждаємо різні теми навколо IT. Хочу вам подякувати за те, що ви разом зі мною занурились в цю доволі непросту тему, чи можна все ж таки залишити тільки Production Environment. І я сподіваюсь, що це надихне вас на експерименти і, можливо, такий сетап підійде саме вашому проекту. Дуже вам дякую, друзі. Ще раз, мене звати Влад Кампов. Переходьте на бенто. І побачимось, як це буде.