Побудова флоу розробки вебпроекту: від соло-розробника до великої команди

Привіт! Мене звати Влад Коба, я TechLead в ІТ-компанії Boosta. Веброзробкою займаюся вже понад 10 років. Я спостерігав, допомагав і вибудовував самостійно процес розробки в командах різного розміру. У цій статті хочу категоризувати свої спостереження щодо оптимальних підходів до веброзробки на різних етапах росту проєкту.

Головне в розробці — надійний фундамент

Пофантазуймо й уявімо себе розробником, який починає роботу над стартап-вебпроектом. Є лише ідея й розуміння, куди рухатись. Здавалось би, починай писати код — а там розберешся. Проте саме на старті можна закласти надійний фундамент, що забезпечить комфортне середовище для безпосередньо розробки. І цим фундаментом, на мою думку, є перевірені часом правила та підходи до простих речей, як-от адекватна локальна розробка, версіонізація коду, налаштований процес постачання коду на прод. Цим, на жаль, багато хто нехтує.

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

Як-то кажуть: «Немає меж у досконалості», можна легко спалити весь бюджет на проєкт, так його і не розпочавши, тому спробуймо знайти оптимальні підходи.

Один розробник

Вхідні дані

• Один сферичний розробник.
• Один вебпроект у вакуумі.
• Бюджет — банка пива, шматок піци.
• Дедлайн — на вчора.

Код

Перше, що варто зробити на старті будь-якого проєкту з розробки — налаштовувати систему версіонізації та створити репозиторій, де можна зберігати код. Обираємо Git як систему версіонування, а GitHub або вітчизняний GitLab як місце, куди код покласти. Ви можете подумати: «Розробник же один, навіщо це все робити, краще не витрачати на це час, а писати код. Швидше напишу — швидше зароблю». Проте це потрібно для контролю над собою й перестраховки. Код, особливо на нестандартних проєктах, має тенденцію швидко змінюватися в ході розробки, тож можна сьогодні зламати щось, і це вилізе боком лише через тиждень.

Git у суті своїй і є цим інструментом, що дає змогу фіксувати код на різних етапах розробки, тож у будь-який момент його можна буде повернути в той чи інший стан. Важливо зберігати код не на локальному пристрої (наприклад, на напівмертвому HDD), а на віддаленому репозиторії, до якого можна отримати доступ будь-де й із будь-чого.

16-17 травня, Київ. Квитки тут!👇

Добре, гіт підключили, репозиторій засетапили. Як тепер із цим працювати?

Далі потрібно закомітити код у ключових етапах розробки. В ідеальному світі — зробити гілки під різні фічі й потім усе злити в master-гілку. Проте розробник у нас один, проєкт один, дедлайни тиснуть, тому можна зрізати кути та працювати лише на master-гілці. Від цього ми не втратимо в якості, зате трохи виграємо в часі.

Локальна розробка

Репозиторій створили, час писати код. Писати-то напишемо, а де його запустити? Сетапимо FTP і закидуємо код одразу на прод? Ні, сетапимо Docker. FTP — легко, швидко й ненадійно: у процесі такої розробки файли можуть недокинутись, перетертись, ви самі можете допустити якісь помилки що з ручною, що з автоматичною синхронізацією.

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

Фух, нарешті вже можна писати код.

Тестування

Молодці, код написали, тепер треба перевірити, чи правильно все працює. Формальне тестування ви й так будете робити в процесі розробки, тест дуже простий — працює чи не працює? Мануально якісно ви самі не протестуєте, а спеціально витрачати на це час недоцільно. Як-то кажуть: «Найкращий інструмент тестування — це замовник». Однак критично важливі частини коду (особливо ті, від яких залежать гроші) все ж варто покрити юніт-тестами для впевненості в завтрашньому дні. У галузі фінтеху взагалі кожен «чих» юніт-тестами покривають, тож не лінуйтеся.

Хостинг і деплой

Код написали, протестували — час світу побачити наш проєкт. А де його розгорнути? Ідеально — на виділеному сервері на DO чи AWS, де ви зможете використати ваші докер-конфігурації, але прибережемо їх на потім. У нас із бюджету лишилося пів банки пива, тому хостинг у нас, найімовірніше, shared.

Здавалося б, де хостити зрозуміло, сетапимо FTP і закидаємо проєкт, так?

Майже, але ні, аргументи ті самі, що й раніше: брак контролю — це прямий шлях до зламаного проєкту й годин дебагу. Краще підключитись через SSH і зпулити код із репозиторію, адже:

• Це швидше, ніж через FTP закидати всі файли з вашого пристрою.
• Це наявність контролю та простота процесу.
• Це дає змогу швидкого відкату. Якщо, наприклад, прод зламався після заливки свіжого коду, не біда — переключаємось на коміт, де проєкт працював стабільно.

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

«Ну яка документація — розробник же один, що він, сам собі її писатиме?»

Так, пишіть документацію, коротко, без фанатизму, хоча б у readme.md. Розписуйте, що, чому, навіщо і як працює. Майбутній ви однозначно подякуєте собі за це, якщо доведеться онбордити в проєкт нового розробника, або просто коли через довгий час повернетесь до проєкту. Крім того, написання документації дає змогу порефлексувати на тему повноти розробки.

Підсумок

Підсумуємо оптимальні методи побудови роботи з вебпроектом, якщо ви соло-розробник:

✅ Оптимально:

• Репозиторій у GitLab/GitHub.
• Git — маємо одну гілку master.
• Docker для локальної розробки.
• Написання юніт-тестів для критичного функціоналу.
• Shared-хостинг і деплой через Git-команди по SSH.
• Мінімальна документація на основні моменти.

💡 Надмірно:

• Обовʼязкове розділення фіч на окремі гілки.
• Повне тестування, написання тест-кейсів, автоматизація тестування.
• Докер на проді, оркестрація.
• Автоматизація деплою, CI/CD.

❌ Шкідливо:

• Розробка без Git.
• Розробка напряму, через FTP-синхронізацію.
• Тримати код проєкту винятково на компʼютері.
• Деплой шляхом прямої заливки на FTP.
• Повна відсутність документації.

Маленька команда

Що ж, чудово, фантазуємо далі. Проєкт потроху стає на ноги, росте обсяг роботи, з’являється потреба в додатковому розробнику. Починається командна робота, а з нею приходять і логічні проблеми: мердж-конфлікти, зламаний функціонал, хаос, вирване волосся. Проте це за умови, що ви не адаптували свою розробку під нові реалії.

Вхідні дані

• Два розробники.
• Один вебпроект.
• Бюджет — ящик пива й кілька коробок піци.
• Дедлайн — на вчора (а буває інакше?).

Код

У нас вже є Git, це чудово, варто лише трошки додати правил. У світі є декілька перевірених часом флоу спільної розробки проєкту в Git, одні з них це GitFlow та Trunk-based. Детальніше можна почитати в посиланнях, але якщо коротко: GitFlow пропонує довгу розробку під окремими гілками й виливання на прод релізами, а Trunk-based пропагує швидку розробку докомпозованими частинами й часте виливання одразу в master. Команда в нас невелика, тож Trunk-based підходить краще, оскільки пропонує більш гнучкий і швидший формат розробки.

(картинки взяті звідси)

Отже, який вигляд матиме флоу наших розробників:

1. З якоюсь періодичністю їм треба збиратись і робити декомпозицію завдань на логічні елементи, які кожен з них може виконати за кілька днів.
2. Одразу варто розділяти зони відповідальності, щоб уникнути необхідності переписувати один одному методи.
3. Коли береться в роботу задача — під неї необхідно створити окрему гілку з master.
4. Далі відбувається магія написання коду.
5. У кінці, після обов’язкового пулу з master і швидкого локального тестування, можна мерджити свою гілку в master.

Швидкий ітеративний підхід, постійна комунікація й розділення зон відповідальності — запорука швидкої та продуктивної командної роботи.

Окремо варто проговорити аспекти фронтенд-розробки. Оскільки тут часто залучені різні збірники й оптимізатори, частина файлів генерується автоматично. Коли розробник працює один, він може зберігати ці файли в репозиторії (але робити цього не варто), і це не викликатиме проблем, адже ти єдиний, хто з цим кодом взаємодіє.

Однак коли людей, які працюють із компонентами фронтенду, декілька, — згенеровані файли в репозиторії це палиця в колесі. Хтось не спулить собі чужі зміни, згенерує нові файли, закомітить їх — і буде біда. На цьому етапі варто переглянути свій .gitignore і включити запуск команд збирання фронтенду у процес деплою на прод.

Локальна розробка

Тут без змін — ви молодці, що ще раніше засетапили Docker, новий розробник одразу узявся до роботи.

Тестування

Професійного тестувальника в команді все ще немає, але потреба стає гострішою. Виділяйте більше часу на перевірку проєкту перед пушем у master, оскільки тепер завдяки колезі можуть зʼявитися сюрпризи. Продовжуйте писати юніт-тести на критичні частини коду.

Хостинг і деплой

Тут уже можна подумати про CI/CD, але ще не критично. Деплой через консоль ще працює. А от що важливо впровадити, так це окремий закритий дев-сервер, щоб мати змогу разом протестувати спільний результат перед виливкою на прод.

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

Коли вас двоє, здається, що про все можна спитати, але такі питання можуть швидко накопичитися на цілий день. Тому варто ще більш прискіпливо прописувати основні речі ще й коментарями в коді, щоб ваш колега міг самостійно та швидко зрозуміти ціль написання того чи іншого шматка коду. Тим паче зараз є код-асистенти, які роблять усе швидко, вам лишається витратити час лише на те, щоб погодитися на пропозицію ШІ.

Підсумок

Підсумуємо оптимальні методи для мінікоманди з двох розробників.

✅ Оптимально:

• Репозиторій у GitLab/GitHub.
• Trunk-based development flow.
• Docker для локальної розробки.
• Написання юніт-тестів для критичного функціоналу.
• Shared-хостинг і деплой через Git команди по SSH.
• Мінімальна документація на основні моменти + більш детальні коментарі в коді.
• Додаткове тестування перед деплоєм.
• Наявність дев-середовища.

💡 Надмірно:

• GitFlow.
• Повне тестування, написання тест-кейсів, автоматизація тестування.
• Докер на проді, оркестрація.
• Автоматизація деплою, CI/CD.

❌ Шкідливо:

• Те, що й раніше.
• Автоматично згенеровані файли в репозиторії.

Велика команда

Окей, наступна ітерація. Проєкт отримав зелене світло й нормальне фінансування. Тепер у вас є справжня IT-команда. Додаються ще кілька розробників, Project Manager і тестувальник. Плани на розробку прописані на рік уперед, на вас чекає світле майбутнє. Або темне, якщо не налаштуєте процеси, тоді все закриється через хаос у розробці й неробочий проєкт.

Вхідні дані

• Чотири розробники, один тестувальник й один Project Manager.
• Один вебпроект.
• Бюджет — справжні гроші (пиво й піца тепер лише щоп’ятниці).
• Дедлайн — згідно з плануванням (диви, а таки буває по-іншому).

Код

Тепер, коли в нас є планування завдяки Project Manager, для більш ефективної роботи у вже великому проєкті варто використати GitFlow. Можна вже не кліпати фічі за пріоритетами, а пакувати їх у релізи. Від цього змінюється й підхід до розробки. Беручи задачу в роботу, ви тепер ставите собі такі питання:

• гілку вам створювати від master, чи від дев-гілки релізу;
• ваше завдання це хот-фікс, баг-фікс чи планова розробка.

Загалом про всі радощі старого-доброго GitFlow детальніше можна почитати тут.

Також зручною практикою в такій великій команді буде або призначати одного з розробників відповідальним за реліз, або вводити роль Tech Lead. Він задасть єдиний вектор розробки, тож усі в команді будуть на одній хвилі. Крім того, Tech Lead робитиме фінальний рев’ю-реліз, щоб у master потрапляв перевірений і красивий код.

Загалом на цьому етапі розвитку команди було б непогано мати регулярну практику код-рев’ю: перехресного, сумісного, покейсового, від більш досвідченого до менш досвідченого — підійде будь-який формат, що працюватиме у вас.

Локальна розробка

Тут все ще є Docker, ви все ще молодці.

Тестування

Нарешті в команді зʼявляється свята людина, що вкаже грішникам на їхні помилки. Робота тестувальника може бути різною, але суть одна — забезпечити мінімізацію потрапляння багів на прод. Не вказати розробнику, які вони погані, а допомогти знайти того жучка, що сховався. Як на мене, саме тестувальник — людина, яка відповідальна за «прийомку» задачі й проєкт у цілому. Тому тестування має бути або повне і якісне, або ніяке, інакше якісь баги однаково проскочать.

А от щоб тестування було ефективним і не займало більше часу, ніж розробка, треба правильно вибудовувати процеси. Ось кілька порад:

1. Ведіть спільну документацію проєкту всією командою (розписуйте, яка фіча за що відповідає, і де її шукати).
2. Прописуйте тест-кейси і їхнє використання для забезпечення методичності тестування.
3. Автоматизуйте тест-кейси, де це можливо.

Хостинг і деплой

На цьому етапі можна розгулятись на повну. Ручний деплой стає згубним, коли в команді вже чотири розробники, а кожне оновлення містить величезну кількість змін. Людину треба прибрати з цього процесу. Тут нам на допомогу приходить Continuous Integration and Continuous Delivery (CI/CD).

І нам треба налаштувати пайплайн, який автоматично братиме оновлену master-гілку й доставлятиме новий код на прод. Ось тут уже Docker обов’язково має бути на проді, це дає змогу збирати та підміняти контейнери з кодом майже безшовно для користувача (звісно, є ще купа різних плюшок). А якщо вам вдасться вибудувати Blue-green deployment — моя вам повага й низький уклін.

У цей пайплайн можна й варто додати автоматизацію тестування, це зменшить навантаження на тестувальника й також додасть у стабільність процесу заливки змін на продакшн.

Не забуваємо і про дев-середовище, яке тепер має бути обов’язковим. Без нього QA просто не зможе впевнитися у працездатності нової гілки. До речі, CI/CD бажано налаштувати й під деплой дева, щоб тестувальник не залежав від зайнятості розробників і самостійно міг по черзі брати різні гілки й розгортати їх для тестування.

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

З великою командою приходить і велика відповідальність — відповідальність не залишати після себе незрозумілу спадщину. Коментарі в коді, документація для користувача, тест-кейси — уся команда має спільно працювати над цим і підтримувати актуальність написаного. Це також дуже важливий та обовʼязковий етап розробки в команді, яким не можна нехтувати.

Підсумок

Отже, що ми маємо для великої команди.

✅ Оптимально:

• Репозиторій у GitLab/GitHub.
• GitFlow.
• Планування фіч.
• Docker для локальної розробки.
• Ведення і застосування тест-кейсів.
• Написання юніт-тестів для критичного функціоналу.
• Ведення документації всією командою.
• Наявність дев-середовища.
• Docker на проді й деві.
• Автоматизація деплою, CI/CD.
• Код-рев’ю.

💡 Надмірно:

• Повне тестування фічі на гілці фічі, на гілці релізу та проду.
• Рев’ю, що блокують код при заливці в гілку фічі.

❌ Шкідливо:

• Нехтування флоу.
• Мікроменеджмент.

Замість висновку

Як бачите, побудова флоу — це неочевидно важливий процес розробки, що напряму впливає на якість/швидкість/вартість постачання проєкту. А ще він повний різноманітних компромісів і зрізання кутів. Я спробував викласти свої думки, спираючись на власний досвід і спостереження. Звісно, це все велика абстракція, але я буду максимально щасливим, якщо ця стаття допоможе якійсь команді розробників побачити зону росту у своєму флоу.

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