Що таке GitLab і як почати з ним працювати
Автор: Редакція Domeny.ForSale Опубліковано
Коротко: GitLab — платформа для зберігання коду, спільної роботи над змінами й автоматизації тестування та розгортання застосунків. Вона використовує Git — систему, що зберігає історію змін у файлах, — і доповнює його інструментами для організації роботи та контролю якості. Можна користуватися сервісом GitLab.com або розгорнути GitLab у власній інфраструктурі.
Для чого потрібен GitLab і чим він відрізняється від Git?
Git дає змогу відстежувати, хто й коли змінив файли, порівнювати їхні версії та відновлювати попередній стан проєкту. Він працює й локально на комп’ютері, без облікового запису в будь-якому сервісі. Натомість GitLab — це платформа, яка надає спільний робочий простір для користувачів Git.
Основою проєкту є репозиторій — сукупність файлів разом з історією їхніх змін. GitLab дає змогу переглядати репозиторій у браузері, керувати доступом і обговорювати запропоновані виправлення. Крім коду, у ньому можна зберігати документацію, конфігурацію сервера чи текстові файли вебсайту.
GitLab — не редактор коду й не система керування вмістом на кшталт WordPress. Розробник зазвичай пише код у своєму редакторі, а потім надсилає зміни до репозиторію. Платформа допомагає перевірити їх і доставити до середовища, у якому працює застосунок.
Як відбувається спільна робота над змінами?
Робота в GitLabie не обов’язково передбачає безпосередню зміну основної версії проєкту. Учасник команди створює гілку — окрему лінію розвитку коду — і зберігає в ній зміни як коміти, тобто набори змін з описом. Так можна підготувати нову функцію, не впливаючи одразу на версію, якою користуються інші.
Готову пропозицію подають у merge request — запиті на злиття змін із вибраною гілкою. Інші учасники можуть порівняти код, залишити коментарі та вказати, що потрібно виправити. Після виконання узгоджених умов зміни зливають із гілкою. Необхідні схвалення та правила доступу залежать від налаштувань і доступних функцій.
Наприклад, агенція вдосконалює контактну форму на сайті клієнта. Розробник готує зміну в окремій гілці, інший учасник перевіряє обробку помилок, а автоматичний тест перевіряє правильність надсилання даних. Лише після перевірки команда зливає виправлення з основною версією та впроваджує його на сайті.
Для повідомлень про помилки й планування завдань використовують issues — записи з описом, обговоренням і зазначенням відповідальної особи. Зв’язок такого запису з merge request допомагає з’ясувати не лише те, що змінили, а й чому.
Що дає автоматизація CI/CD?
CI/CD означає безперервну інтеграцію та безперервну доставку або розгортання змін. Безперервна інтеграція передбачає часте об’єднання результатів роботи команди й автоматичну перевірку коду. Доставка готує програмне забезпечення до випуску, а розгортання може додатково автоматично публікувати його в цільовому середовищі.
У GitLabie такі дії зазвичай описують у файлі .gitlab-ci.yml, розміщеному в репозиторії. Вони утворюють pipeline, тобто конвеєр із завдань, які виконуються за визначеними правилами. Завдання запускає runner — програма, що виконує команди на призначеній їй інфраструктурі.
Простий конвеєр для вебсайту може:
- Перевірити синтаксис і форматування коду.
- Запустити тести.
- Зібрати файли, готові до публікації.
- Надіслати їх на тестовий сервер, а після ручного схвалення — також на робочий.
Саме лише розміщення проєкту в GitLabie не запускає повноцінного процесу розгортання. Потрібно налаштувати завдання, забезпечити доступність runner і надати необхідні права доступу. Паролі та ключі доступу не слід записувати в коді: для цього використовують належно захищені змінні CI/CD або систему керування секретами. Автоматичні тести виявляють лише ті проблеми, на перевірку яких вони розраховані, тож зелений результат не гарантує відсутності помилок.
GitLab.com чи власна інсталяція?
GitLab.com — сервіс, який підтримує постачальник. Вам не потрібно встановлювати платформу, оновлювати її чи адмініструвати її сервер. Проте ви й надалі відповідаєте за налаштування проєкту, облікові записи користувачів, права доступу та захист даних для входу й доступу.
Власна інсталяція, що має назву GitLab Self-Managed, дає більше контролю над інфраструктурою та місцем зберігання даних. Водночас вона потребує оновлень, моніторингу, резервного копіювання й захисту системи. Розгортання на сервері компанії не означає автоматично вищого рівня безпеки.
Для невеликої команди без адміністратора практичнішим варіантом для початку зазвичай є сервіс, розміщений у постачальника. Власна інсталяція може бути доцільною за особливих вимог до мережі, інтеграцій або даних. Перед вибором перевірте в офіційній документації та переліку тарифів GitLaba актуальні обмеження обсягу сховища, правила оплати завдань CI/CD і доступність потрібних функцій у відповідному плані.
GitLab і GitHub: відмінності та перші кроки
GitLab і GitHub — різні платформи, що використовують Git. Обидві дають змогу зберігати репозиторії, переглядати зміни, опрацьовувати повідомлення про помилки й завдання та автоматизувати роботу. У GitHubie відповідником merge request є pull request, а для автоматизації використовують, зокрема, GitHub Actions.
Обирати платформу варто з огляду на потрібні інтеграції, права доступу, вартість автоматизації та досвід команди. Перенести сам репозиторій Git буває відносно просто, але міграція повідомлень і завдань, обговорень та налаштувань розгортання потребує окремої підготовки.
Для початку створіть приватний проєкт із файлом README, що описує його призначення. Потім підготуйте невелику зміну в окремій гілці та відкрийте merge request. Така проба допоможе ознайомитися з основним робочим процесом, перш ніж додавати автоматизацію й доступ до серверів.
Читайте також
