GitHub vs GitLab. Обираємо сервіс під потреби проєкту
Розробники в певний момент стають перед вибором, який сервіс для системи контролю версій обрати. І навіть найдосвідченіші найчастіше вагаються: GitHub чи GitLab? У цій статті ми — Костянтин Харченко, Chief Technical Architect, розробник із
Важливість сервісів для спільної розробки та керування процесом створення програмного забезпечення невпинно зростає протягом останніх 20 років. Завдяки швидкісному інтернету розвинулася ціла галузь — аутсорс-розробка ПЗ. Потенціал онлайн-засобів створення програмних продуктів і сервісів ще досі не розкрито повністю, а особливу роль у цьому процесі відіграють системи керування версіями програмного коду і відповідні сервіси для командної роботи.
Трохи історії
До появи відомої системи Git, яку створив Лінус Торвальдс, розробники користувалися CVS, SVN та іншими засобами керування версіями. Але основною проблемою тут була однорівнева система коміту. У разі помилки неможливо було виправити її без втручання в репозиторій. Лінус Торвальдс для розробки ядра Linux написав власну систему керування версіями з дворівневою системою запису інформації до репозиторію. Тобто спочатку ми робимо git commit, перевіряємо, чи все гаразд у локальному репозиторії, і далі можемо зробити git push у віддалений репозиторій, де зміни бачитимуть всі учасники проєкту.
Git — це суто система керування версіями. Часто для спільної розробки програмного забезпечення необхідно мати вебсервіс для узгоджених дій з кодом проєкту, відстеження змін та організації взаємодії. Тому на базі Git з’явився вебсервіс GitHub, куди було додано можливість управління завданнями та Wiki для кожного проєкту. А трохи згодом — GitLab, який зайняв свою нішу завдяки більш розвиненим функціям і можливості виконувати CI/CD. Основне завдання GitHub та GitLab — сприяти взаємодії розробників у проєктах.
Система керування версіями та інтегрована система керування задачами дуже важливі під час розробки та підтримки програмного забезпечення та сервісів, тому що вимоги до інформаційних систем постійно змінюються та з’являються нові. Іноді непросто оцінити складність розробки програми, і навіть замовник часто не володіє всією необхідною інформацією для чіткого формулювання вимог до продукту на початку роботи.
Деякі розробники вважають, що для малих проєктів система керування версіями та проєктом не потрібна. Це начебто зайве. Але коли доходить до підтримки реального продукту для користувачів, відсутність репозиторію коду та системи керування версіями може мати вкрай негативні наслідки. У репозиторії має бути все — абсолютно повна інформація щодо проєкту. І будь-який рух у проєктному керуванні повинен бути записаний у системі, а не на папері. Навіть коли ви робите простенький вебсайт на HTML, все одно записуйте все до репозиторію. Досвід доводить, як це корисно.
Систему GitLab створював наш український інженер Дмитро Запорожець. Ще 2011 року він зрозумів важливість комунікації в проєкті на рівні системи керування розробкою коду та системи керування задачами.
Із самого початку проєкт GitLab можна було встановити на власних серверах або в інстансах у хмарних системах, продукт мав ліцензію MIT. Далі, 2013 року, його розділили на Community Edition та Enterprise Edition зі збереженням вільної ліцензії MIT з відкритим кодом. Зараз систему використовують понад 100 000 організацій, включно з IBM та Alibaba, NASA, CERN.
Детально розглянемо обидві системи та оцінимо застосування GitHub та GitLab для проєктів різних категорій.
Огляд сервісів
Порівняємо GitHub і GitLab за різними параметрами та варіантами використання.
Business Perspective
Основні переваги GitHub з погляду бізнес-керівників полягають у великій кількості доступних користувачів у системі. Також чимало опенсорс-проєктів розміщується саме тут. Наявність безкоштовних командних приватних репозиторіїв часто стає головним фактором вибору GitHub.
Однак GitLab дає кращі технічні можливості, має підтримку Financial Services Regulatory Compliance, PCI, HIPPA тощо. З погляду розміщення пропрієтарної інформації, персональних даних, іншої чутливої інформації, безперечно, перевага на боці GitLab, тому що систему можна встановити на власних серверах.
Continuous Integration
Побутує думка, що GitLab має значно більші можливості з Continuous Integration порівняно з GitHub: це built-in CI, можливість керувати великою кількістю складних проєктів і команд за допомогою механізму підгруп, переглядати програму перед об’єднанням, щоб зменшити дефекти та скоротити час розробки.
Останнім часом GitHub значно поліпшив свою систему CI, яка має назву GitHub Actions. Маючи доступ безпосередньо до репозиторію та метаданих сервісу Actions, можна точно налаштувати процес CI аж до таких маленьких зручностей, як можливість відправити посилання на Pull Request у Slack повідомленні для подальшого проведення Code Review. Конфігурація відбувається за допомогою YAML-файлів, доступний marketplace готових екшенів для інтеграції у проєкт (більшість з них наразі безкоштовні). Звичайно, система ще нова й недавно вийшла з фази бета-тестування, але її гнучкість дає змогу виправити всі недоліки самостійно.
Continuous Delivery
GitLab має шаблон Auto DevOps, який забезпечує заздалегідь визначену конфігурацію CI/CD. Це дає змогу користувачам автоматично визначати, створювати, тестувати, розгортати та контролювати прикладні програми. Завдяки Auto DevOps можна використовувати найкращі практики та інструменти CI/CD, а отже, значно спростити налаштування та виконання досконалого та сучасного життєвого циклу розробки програмного забезпечення. Серед засобів відзначу Auto Build, Auto Test, Auto Code Quality, Auto Dependency Scanning, Auto Review Apps, Auto Deploy, Auto Monitoring. Є ще багато інших корисних можливостей у перформанс-тестуванні та скануванні безпеки.
Ліцензії та вартість
У рамках безкоштовного сервісу в системі GitHub наразі є змога підтримувати необмежену кількість відкритих репозиторіїв та учасників проєкту. Крім того, недавно стало безплатним використання 2000 Actions minutes/month, а також 500MB of GitHub Packages storage. Наступний рівень тарифів GitHub починається вже з $4 per user/month та $21 per user/month.
На безкоштовному GitLab, крім базових необмежених функцій, як у GitHub, можна застосовувати всі стейджі циклу DevOps, створювати власну Continuous Integration, Production Environment і мати ресурс 2000 хвилин на CI/CD. На момент написання статті GitLab повідомив про зниження кількості хвилин до 400. Але за $10 в місяць буде доступно 1000 хвилин, починаючи з 1 жовтня
Також GitLab пропонує передплату за $19 на місяць «срібного» плану та за $99 на місяць — «золотого». Відповідно, у цих планах посилюється підтримка з технічних питань від компанії та розширюються можливості та потужності в CI/CD та DevOps, можливості керування великою кількістю проєктів.
Підтримка користувачів
Обидві системи надають підтримку на всіх рівнях безкоштовних і платних сервісів. Але якщо безпосередньо порівнювати послуги, то у разі безкоштовного варіанту краще віддати перевагу GitHub, оскільки він має майже в 40 разів більше ком’юніті, ніж GitLab.
У платних сервісах GitLab дасть кращі можливості на рівні корпоративних акаунтів і забезпечить, що дуже важливо, коротший час відповіді на запитання, до 30 хвилин у найбільшому пріоритеті в GitLab (порівняно з 8 годинами в підтримці GitHub).
Якість Version Control & Collaboration
З погляду керування задачами у проєкті (issue management) GitLab допоможе вимірювати та відстежувати повний життєвий цикл розробки — від планування до розгортання. Найбільш важливими є такі засоби, як Time Tracking, Burndown Charts, Issue Due Dates, функція переміщення задачі в інший проєкт.
Також у системі контролю версій GitLab є змога робити імпорт та експорт з інших систем керування (GitHub, Bitbucket, Google Code, FogBugz, Gitea) або з будь-якого доступного Git URL. Окрім цього, існує підтримка різних видів репозиторіїв: Mono Repos, Conan (C++), Go, Composer (PHP), PyPI (Python), RPM та Debian (Linux). А ось GitHub краще підтримуватиме Visual Studio від Microsoft, тому що саме ця компанія зараз володіє сервісом GitHub.
Security Roadmap
План з безпеки компанія GitLab почала публікувати ще з 2018 року. Це суттєво підвищило безпеку продукту і дозволило розробникам виявляти та виправляти системні проблеми на найбільш ранніх етапах проєктування та кодування. Оскільки код продукту GitLab є відкритим, це дає можливість більш ніж 3000 розробникам системи поліпшувати її безпеку та цілісність, відразу аналізувати проблеми на різних рівнях.
GitHub теж приєднався до цієї ідеї та опублікував свій роадмап з безпеки у червні 2020 року. GitHub хоч і не є системою з відкритим програмним кодом, але останнім часом зробив більше як 200 фіч у напрямку сек’юрності.
Continuous Integration & Delivery
Важливою частиною процесу розробки є CI/CD, і це розуміють розробники як хмарних систем, так і веб-сервісів для спільної розробки програмного забезпечення. Ці вимоги зумовлені необхідністю дуже швидко постачати нове програмне забезпечення користувачам і підвищити надійність деплойменту на продакшн-сервери та інстанси.
GitHub Actions
Пропонує широкі можливості безперервної інтеграції та доставки програмного забезпечення зі своїх репозиторіїв. У системі можна створити контейнер, розгорнути веб-службу або автоматизувати надсилання повідомлення-привітання для нових користувачів, що долучаються до проєктів з відкритим кодом. Щоб виконати такі дії, GitHub пропонує Actions. GitHub Actions — окремі завдання, які можна поєднувати для створення обчислювальної задачі та налаштування воркфлоу. Є змога створювати власні сценарії або використовувати та налаштовувати Actions, якими користується спільнота GitHub.
Це допомагає пришвидшити оновлення версій, правильно поширювати програмне забезпечення та виконувати вирішення залежностей через наявний GITHUB_TOKEN. А основна перевага Actions — це можливість запускати сценарій на будь-яку подію в проєкті у GitHub.
GitHub Enterprise можна встановити у хмарі AWS, що дає можливість використовувати інтегровану платформу для неперервної інтеграції (CI), а також нелінійний воркфлоу для співпраці, детального моніторингу та аудиту програмних рішень для адміністраторів систем.
GitLab CI/CD
GitLab з погляду CI/CD надає дуже широкі можливості зі створення сценаріїв і інтеграції з репозиторіями проєкту. Щойно у гілці з’являється новий коміт, система CI/CD запускає конвеєр неперервної інтеграції та неперервної доставки. Водночас є змога запускати послідовні та паралельні сценарії. Також система надає додаткові сервіси, наприклад, для перевірки якості коду GitLab Code Quality, Browser Performance Testing для тестування швидкості браузера, Load Performance Testing для проведення навантажувальних тестів. Крім того, це можливість виконувати розширене тестування для Container Scanning, Dependency Scanning та деплою на продакшн програмного забезпечення у кластери Kubernetes за допомогою Auto Deploy.
Пропозиція безперервної інтеграції від GitLab, партнера з передових технологій AWS Partners Network (APN) з компетенцією AWS DevOps, забезпечує широкий набір функцій для автоматизації. Використання сервісу в хмарі Amazon полегшує включення нового коду у ваше програмне забезпечення та допомагає у розгортанні нової версії програмного забезпечення.
Розгортання GitLab
На серверах і в хмарних сервісах
Оскільки проєкт GitLab спочатку створювали для власного використання, то можливість розгортання GitLab на своїх серверах була опцією за замовчуванням. Щира подяка авторам і власникам продукту, що вони дозволяють користуватися GitLab як у хмарному варіанті (аналогічно до GitHub), так і завантажити все необхідне та встановити цей вебсервіс у себе.
Чому виникає таке завдання? Тому що певні організації, як-от банки, об’єкти критичної інфраструктури, медичні установи, бувають обмежені у використанні публічних хмарних сервісів, але мають потребу підтримувати велику кількість користувачів і мають розвинену приватну хмару.
З погляду ресурсів для встановлення системи рекомендують мати хоча б 4GB of RAM. З власного досвіду додамо, що краще використовувати SSD. Тобто вимоги для роботи системи невисокі.
Процедура встановлення GitLab на сервері цілком стандартна. Розглянемо на прикладі Ubuntu. По-перше, робимо apt-get update, як зазвичай. Потім докинемо ще кілька тулзів, необхідних для роботи, зокрема curl, openssh-server, ca-certificates, tzdata. Далі додамо до системи postfix, це буде потрібно для електронних листів і сповіщення користувачів. Потім завантажуємо файл скрипту для GitLab за допомогою curl. І запускаємо команду apt-get на встановлення системи GitLab. Ось ви вже маєте GitLab у себе на сервері — далі переходимо за вебадресою серверу і виконуємо всі необхідні налаштування.
Процедура інсталяції під інші системи може дещо відрізнятися, але ідея буде та сама. Для встановлення використовується інсталятор, що відповідає операційній системі сервера. А ком’юніті-дистрибутиви GitLab вже доступні для FreeBSD, Puppet, IBM Bluemix, OpenNebula тощо.
Але найдосконаліший (абсолютний) метод встановлення GitLab на власних потужностях — це компіляція із сирцевих кодів. Весь код GitLab ви можете завантажити й запустити на компіляцію, а потім встановити на свій сервер.
У такому разі ви маєте повний доступ до необхідної конфігурації системи й можете налаштовувати її під свої потреби. Детально процес налаштування із сирцевих кодів дивіться тут. Переваги такого рішення полягають і в тому, що можна встановити stable-версію з усіма новими фічами.
До речі, дуже зручно, що встановлення із сирцевих кодів можна зробити з пакунків Omnibus package installation для deb/rpm. Це допоможе уникнути багатьох проблем під час компіляції та налаштування на будь-якій системі Linux — Ubuntu, Debian, Centos і навіть Raspberry Pi.
Далі робимо клон з репозиторію GitLab і починаємо конфігурування системи. При цьому необхідно забезпечити secrets file через YAML. Завдяки стандартизації підтримки GNU Make на різноманітних платформах можлива компіляція системи майже усюди.
Окремо треба згадати про можливість інсталяції GitLab через Helm для Kubernetes, нативний для хмарних систем. Це допомагає уникнути зайвих рухів щодо конфігурації в Kubernetes і полегшує роботу адміністраторів і девопсів.
У хмарних системах GitLab можливо встановити для Amazon Web Services, Google Cloud Platform, Microsoft Azure та інших хмарних систем, де підтримується Linux.
У Docker-контейнерах
Найкращим варіантом є встановлення GitLab у власному контейнері (у GitHub така можливість відсутня). GitLab надає офіційний зліпок (docker image) для встановлення системи у контейнері з усіма перевагами такого рішення, а саме:
- можливість універсально оперувати багатьма системами GitLab для великих компаній;
- змога переналаштовувати GitLab на інших серверах без суттєвих дій в адмініструванні, зі збереженням усіх налаштувань для користувачів;
- при правильних налаштуваннях підвищити безпеку системи;
- у разі відмови обладнання швидко піднімати систему на інших потужностях;
- за потреби швидко переходити у хмарну систему або переносити GitLab між різними хмарними системами.
Розробники GitLab пішли ще далі й підготували два варіанти docker image для встановлення у версії Community Edition та у версії Enterprise Edition. Docker поки не підтримується повністю на Windows, і можуть виникати певні проблеми, наприклад, з volume permissions.
GitLab-контейнер використовує host mounted volumes для збереження постійних даних. Можливо, існують і кращі способи вирішення цього завдання. Наприклад, для Linux є варіант встановити шлях до домашньої теки GitLab за допомогою змінної $GITLAB_HOME. Тоді зможемо зберігати окремо дані, окремо лог-файли й окремо конфігураційні файли GitLab.
І саме тут виникає питання: а чи не краще було б іти шляхом встановлення і конфігурації бази даних? З одного боку, це дещо ускладнює налаштування системи, а з іншого — полегшує адміністрування, тому що база даних тоді зберігає всю необхідну інформацію. Можливо, таке рішення було ухвалене з огляду на швидкість роботи з файловою системою, щоб не навантажувати потужності серверів.
Встановити GitLab у Docker можна за одним з трьох способів: через Docker Engine (найбільш популярний варіант), через Docker Compose (за допомогою конфігураційного файлу YAML, де задати додаткові налаштування) і Docker swarm mode (через систему кластеризації Docker Engines, цей варіант підходить для високонавантажених застосувань).
Встановити GitLab у контейнері просто. Перевага Docker полягає в тому, що оновлення та резервні копії GitLab можна виконувати за допомогою засобів контейнеризації буквально в один рядок. Головне — це стандартизація з Docker. Усе буде працювати всюди, де є підтримка контейнеризації (і в хмарних системах також).
Можливо, є певні зауваження, що контейнер буде уповільнювати роботу GitLab. Але прогрес не стоїть на місці й з кожним днем удосконалюються як програмні засоби, щоб зменшити додаткові витрати на пам’ять і ресурси процесорного часу, так і апаратна частина. Тим часом хмарні системи за менші гроші пропонують усе більше й більше потужностей. Ознайомитися з публікаціями на цю тему можна, наприклад, тут.
Щоб прискорити роботу контейнера і виконати необхідні налаштування, можна застосувати Docker Compose чи встановлювати з Docker Images. Але справжні герої-адміни роблять це власноруч у своєму контейнері, щоб тоді відповідним чином масштабувати.
А от через Docker Compose вже можна більш детально налаштувати інсталяцію в контейнері, зважаючи на вимоги проєкту. Для цього передусім треба встановити Docker Compose (в найпростішому варіанті «завантажив-встановив»). Далі беремо файл docker-compose.yml і налаштовуємо у ньому конфігурацію, необхідну для розгортання контейнера.
Відтак в один командний рядок запускаємо всю цю конфігурацію в роботу docker-compose up -d. Але те, що дозволяє конфігурувати YAML-файл, може полегшити роботу з новими вимогами від користувачів у майбутньому. А ми впевнені, що треба залишати можливість додавання нових конфігурацій для розвитку проєкту.
Досвід реальних проєктів
З багаторічного досвіду роботи з різноманітними замовниками скажемо, що і GitHub, і GitLab виконують поставлені завдання і часто використовуються. Під час розбору варіантів розв’язання проблем неперервної інтеграції та неперервної доставки програмного забезпечення встановили, що краще, коли CI/CD інтегрований з базою коду. Тоді ми зберігаємо налаштування процесів розгортання у репозиторії проєкту. А це — значна перевага.
Експериментально з’ясували, що краще процедури деплойменту записувати в хмару, як це реалізовано, наприклад, у GitLab, тому що система більш стабільно працює і в разі форс-мажору можна швидко звернутися до підтримки та оперативно вирішити всі питання.
Було кілька клієнтів, які вже мали репозиторій і CI/CD у GitLab, і ми успішно дописали їм нові фічі, все працювало, як задумали спочатку. Невисокий поріг входження у систему CI/CD від GitLab і її стандартизованість дозволяє швидко розібратися, що там виконується, і додати необхідні дії, які просить реалізувати замовник.
Також популярним є використання платного приватного репозиторію для клієнтів, що полегшує роботу розподіленим по світу командам. Навіть під час розробки стандартних інформаційних вебсайтів весь контент розміщується у приватному репозиторії GitHub і деплоїться на хостинг.
Трапився випадок з окремим клієнтом, коли вирішили розгорнути вебсайт у Європі замість США в AWS-хмарі. Розрахували технічні можливості, розгорнули новий інстанс і зробили деплой контенту з репозиторію GitHub. Для цього замовника таке рішення дало швидкий і якісний результат, тож не довелось робити трансфер інстансу за допомогою засобів Amazon.
Клієнти, що зосереджені на інтелектуальній власності над кодом, часто віддають перевагу GitLab з умовою, що він буде розміщений на їхніх серверах. До того ж у комплекті йде запит на організацію доступу через VPN. Недоліком таких рішень є залежність від клієнта або розробників з його боку в питаннях конфігурації фіч або оновлення версії системи.
Проте є клієнти, зазвичай із США, що прагнуть мінімізувати свою відповідальність (наприклад, за обробку персональних даних користувачів) і довіряють корпораціям. Для них найкращим рішенням є GitHub, де не потрібно турбуватися про інфраструктуру й можна легко контролювати доступ і рівень адміністративних прав для акаунтів розробників.
Підсумок
Якщо порівнювати з початком ери аутсорсингу в Україні, а це кінець
Резюмуючи розглянуті аспекти та досвід роботи з GitHub та GitLab маємо наступні висновки:
- GitHub добре підходить для проєктів з відкритим кодом. Це корисно для створення власного іміджу розробника або компанії. Завдяки великій кількості користувачів проєкт бачить велика аудиторія.
- GitHub є ідеальним для комерційних проєктів, коли плануєте користуватися винятково функціями системи керування версіями.
- GitLab гарно працює для проєктів, де хочуть побудувати якісний CI/CD на боці хмарної системи.
- GitLab є абсолютним рішенням, коли систему спільної розробки та систему контролю версій необхідно встановити на власних серверах (для організацій з обмеженим доступом до публічних хмарних систем, для обробки персональних даних, для підвищення рівня безпеки системи тощо).
- GitLab можна розгорнути у Docker-контейнерах, коли є необхідність керувати великою кількістю систем спільної розробки на корпоративному рівні й можна використовувати Kubernetes для полегшення супроводу.
Слід зауважити, що існують і альтернативи зазначеним рішенням, наприклад, система BitBucket. Це розвинена платформа для спільної розробки програмного забезпечення. Її теж застосовують, це підтверджено досвідом роботи у відкритих і закритих комерційних проєктах. Головною рисою системи BitBucket є зручність та інтуїтивний інтерфейс користування.
Обидві системи — і GitHub, і GitLab — пропонують назвичайно розвинені та комплексні рішення. Але кожен конкретний проєкт потребує певних налаштувань системи керування версіями та керування проєктами, тому можете обирати між функціоналом двох платформ і оцінити переваги, які важливі саме для ваших завдань.
