Процес розробки на Gitlab. Частина 1.

Peter Ovchinnikov
Nov 7 · 4 min read

Тут в мене є трохи про Gitlab для побудови процесу розробки.
В чому фішка?

Загалом Gitlab складається з 3 частин:

  1. Git repository
  2. Continuous integration
  3. Issue tracker

Але є в нього ще одна річ. Це те, що всі ті 3 штуки повністю інтегровані одна в одну. Ось, як це виглядає.

Continuous Review.

Перша штука, яка значно полегшує життя — gitlab поєднує issue, branch та merge request. Ось так можна зробити branch і merge request для вашої issue прям з веб-інтерфейсу в один клік:

Ось створений merge request:

Серед переваг треба зазначити:

  1. Gitlab пропагує створення merge requests одразу як ви починаєте працювати над issue, а не в кінці, як в github. Це надає змогу мені, як тімліду бачити зміни і вести дискусію і ревьювити код, направляючи розробника в потрібне русло починаючи з першого коміту, замість того, щоб в кінці витрачати тривалий час на ревью та переписування цілої фічі. Так званий Continious Review
  2. Gitlab створює ім’я для бранчі, що зберігає name convension серед усіх учасників процесу.

Merge restrictions policy.

Загалом, Gitlab не дозволяє мержити бранч, якщо:

  1. не пройшов ci пайплайн
  2. є незарезолвлені дискусії
  3. не достатньо аппрувів

Тепер по черзі:

  • Якщо не пройшов ci пайплайн — то варіантів немає. Тількі розбиратися що пішло не так і фіксити.
  • Якщо є незарезолвлені дискусії — то є можливість зробити issue для кожної з них. Таким чином, жоден комент не може бути проігнорованим. Він або виправляється тут і на місті, або потім, в рамках нової issue.
  • А ось це просто офігенна штука. Gitlab дозволяє створити approve policy, в якому ви можете вибрати скільки апрувів і від яких ролей ви маєте отримати щоб змержити бранчу.

Це можуть бути QA і TL (або просто Dev). TL (або Dev) — то зрозуміло. А з QA цікавіше. Ми зробили так щоб на останньому кроці QA автоматично отримував білд і мав змогу протестити зміни (будь то бага чи фіча) ще до того, як це буде змержено в master.

Прикол в тому, що кожен новий коміт змушує збирати апруви заново, ще не дає можливості зробити щось не прозоро.

forza-demo не вимогає аппрувів, бо якось тупо їх отримувати від себе ж. Але така фича існоє, і на реальних проектах я нею користуюсь:

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

ПС. Звістно, всю цю процедуру можно обійти змерживши бранч напряму. Але, тоді, хто ж вам лікарь?

Commit restrictions policy

gitlab надає можливість вказати ще й push policies. Наприклад, шаблони для Commit Message.

Цим regex’ом я вимагаю для будь-якого коміта вказувати номер issue до якого він робиться. Це, як мінімум стимулює робити issue до того, як писати код.

Висновок

Gitlab не зробив нічого насправді революційного.

Він, всього-на-всього, зібрав основні (навіть не всі) best development practices в одному місці, що дозволяє не просто керувати кодом, а керувати ще і процесом розробки, беручи не себе контроль за його виконанням усіма стейкхолдерами.

Простота налаштування якісно виділяє його серед конкурентів, таких як BitBucket та github, та робить дуже зручним інструментом для стартапів на початку іх існування.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade