Трохи розмовний пост. Але без нього не зможу продовжувати. І трохи практики по роботі з gitlab

TL; DR

Front, back - два різні проекти

bandheart.com
|-- front
|   |-- app #core(gate) app
|   |-- service1
|   |-- serviceN
|   |-- infrustructure
|       |-- some_docker_image_1
|       |-- some_docker_image_N
|       |-- some_ansible_playbook
|       ..... 
|   |-- third-party
|       |-- some_package_1
|       |-- some_package_N
|-- back
|   |-- app # core (gate) app
|   |-- service1
|   |-- serviceN
|   |-- infrustructure
|       |-- some_docker_image_1
|       |-- some_docker_image_N
|       |-- some_ansible_playbook
|       ..... 
|   |-- third-party
|       |-- some_package_1
|       |-- some_package_N

Перший коміт - чистий тільки створений проєкт

main -гілка за замовчуванням, змирись і будь політ коректний завжди (в коді максимально)

Ніхто і ніколи не пушить в main. Блокуємо таку можливість!

Моноліт, з можливістю виносити мікросервіси - вибір для цього проєкту. Не для твого !

Front і Back - окремо

Back окремо. Front окремо. Тут дві основні причини

1. Це дасть змогу наймати та працювати окремо з back-end розробниками, і з front-end. Full stack дорогі та не завжди доступні, особливо на обраних кимось там технологіях.
2. По друге. Це навчить особисто тебе і команду мислити саме поняттями клієнт сервер. Web front - клієнт. Android app - ще клієнт, IOS app - ще клієнт. Віджет проєкту на іншому сайті - клієнт, користувач вашого публічного api - клієнт. Окремо винесений сервіс - клієнт. Наголошую на цьому не просто так. Багатенько розробників не розуміють навіщо версійність в api. Ставлять v1 як мантру, і круто якщо ставлять.

Звісно в цього підходу є проблеми. Laravel не просто так продає все в коробці. І той самий WordPress не просто так став популярним. Комунікація frontend з backend (і навпаки) дуже складний процес., і з цим розумінням треба жити. Пришвидшити це може або дуже ідеальне планування якимось технічним менеджером який шарить всюди або ж full stack розробниками. Другий варіант не спрацює додай ми нативні прилажухи, наприклад. Інша проблема це деплой, особливо на ранніх стадіях коли й версію API міняти не хочеться, і наче клієнтів яким це треба - не має, а зміни одразу потребують і front і back. Але все ж таки вважаю що плюсів в розділенні більше.

Моноліт чи мікросервіс ?

Коротка відповідь, для цього конкретного проєкту - "Моноліт АЛЕ". Відповідь довга. Мікросервіси мають сенс якщо ви розумієте навіщо вони в проєкті, наприклад ви знаєте навантаження, ви маєте велику команду і має сенс ізолювати всіх по сервісах тощо.

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

Доходило до безумства, умовний проєкт про продаж ковбаси на локальному ринку Португалії (вигадана історія, на реальних подіях), з 2-х розробників мала півтора десятка мікросервісів які фізично не витягувались цими розробниками. Мікросервіс списку продуктів викликав мікросервіс кошик, який викликав, мікросервіс замовлень який потребував сервіс листів і т.д.. І я розумію навіщо це було команді розробників, вони отримали свій досвід, набили всі необхідні шишки й виросли як спеціалісти. Питання навіщо це власнику проєкту ? Думаю відповідь ви знаєте - щоб у вакансіях на мідла писати обов'язки ідеальні знання мікросервісної архітектури... бо ті два розробники давно звалили, а грошей на "архітекторів" нема.

Але повертаємось до моноліта. Додаємо до нього АЛЕ, яке полягає в готовності виділити ту чи іншу функціональність проєкту в окремий сервіс. Для цього обов'язково модульність, чітка схема взаємодії між модулями, і розуміння що не все буде легко, але все можливо. По всьому цьому я пройдусь в наступних відео. Поки що тримаємо в голові що у випадку необхідності за адекватний час, зможемо винести окремий функціонал в окремий сервіс. І насправді в сучасних проєктах, багато рішень вже в сервісах, про це трохи поговоримо у відео з докеризацією.

Щодо мікро фронтенду. По-перше, у мене нема досвіду, по друге не вважаю що адекватними ресурсами можна якісно керувати зоопарком з фронтендів. І в моємо випадку це не дасть користі як проєкт, так і користувачам.

Для протоколу, я бачу потенціал в мікрофронтенді, але було б круто якби за цю ідею взялись власники браузерних движків.

Gitlab та структура проєкту

Використовую у своїх проєктах gitlab, і вам раджу. Дуже крута інфраструктурна тема, розвивається, дозволяє розгорнути self-hosted версію. Функціонал DevOps просто неймовірний.

В gitlab багато функціонала побудована на групах проєкт. Це прям важливо. Тому

1. Створюю групу з назвою проєкту. Тут все просто, нейм і приватна нічого зайвого.
2. Створюю підгрупу back (така ж буде для front). Тут саме підгрупа, а не проєкт. Тому що в середині буде багато всього, від інфраструктурних штуки, типу docker images, до локальних forks open source libs, з правками які необхідні вам. Така ж група буде для фронту. Це допоможе легко керувати доступи команди до проєктів, налаштовувати CI CD, додавати глобальні змінні тощо. Це не очевидно одразу, але повірте за таку структуру ще подякуєте.
3. Створюю проєкт, називаю просто App. Тут і буде наш laravel (або Nuxt) проєкт. Прибираємо галочки з initial Readme, та static security тестами.

Перший коміт. Master або Main

Далі йдемо по інструкції в самому Gitlab.

Тут акцентую на деяких моментах

1. Будь ласка, додавайте інформацію про себе до гіту. Це часто забувають соло розробники і після них залишається каша в історії

git config --global user.name "John Doe"
git config --global user.email johndoe@example.com

2. Основна вітка зараз main. Змиріться і використовуйте її. Це когось ображало, когось хто може бути твоїм інвестором. І також порада тут. В гіті та в коді не має бути нічого образливого, жодних жартів, жодних жаргонізмів. Тексти комітів, назва функцій, змінних, все це буде колись доступне. Згадайте як CD Projekt RED маркувало все пов'язане з Китаєм, або коміти розробників twich. Це все скандали на які уходять ресурси. Загалом поважаємо всіх хто відстоює свої права. Навіть на назву гілки. Бо ті хто їх не відстоюють лізуть в нашу країну і дохнуть.
3. Перший коміт - голий, чистий фреймворк, без правок. Все інше - код, код потребує review, з кодом повинна бути знайома команда. І особиста порада. Перший коміт робиш ти як lead, tech lead, архітект чи які там звання на себе взяв. Знаю що дуже хочеться це делегувати, бо роботи на 30 секунд, але повір середньо статистичний джун без питання полізе в код, бо на його віндовс 98 щось не запустилось, щось змінить і зробить ініціал коміт. А ти про це дізнаєшся через рік, проклявши фреймворк, документацію, мову програмування і себе, бо все це обрав.

Ніхто не пушить в Main

Setting -> Repository -> Protected branches - Allowed to push and merge set No One

Ніхто ніколи не пушить в main гілку (і в stage) без мерж реквесту. Навіть ТИ! Навіть я. Команда має право провести ревью, навіть вже після хотфікс мержу!

Gitlab secure feature

Документація

Gitlab має готові пресети (темплейти) зі статичними код аналізаторами, пошуку вразливостей тощо. І пропонував їх увімкнути при створенні проєкту. Одразу скажу вони круті, роблять багато корисного за вас. Звісно підрубайте АЛЕ якщо у вас Ultimate версія. Для звичайних смертних вони не несуть практичної користі або вимагають диких доробок. Якщо коротко - вразливості воно знаходить, пошук секретів працює, але в безкоштовній або преміальній версії ви цього не побачите. Бо джоби не падають, а просто зберігають репорти в артефактах джоби. В Ultimate версії на мерж реквесті буде зручний інтерфейс що допоможе керувати знахідками сканерів, тому раджу для власників Ultimate. Для тих у кого таких коштів нема, більшість (якщо не всі) ці фічі можна реалізувати власноруч. В майбутніх відео я налаштую деякі з них