Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Акції GitLab впали на 38%. Компанія змушена підняти ціну на преміум-підписку

Акції GitLab, яка має українське коріння, впали на 38%. Це сталося після того, як компанія дала прогноз щодо річного доходу, який не виправдав очікувань інвесторів, повідомляє CNBC.

Незважаючи на перевищення очікувань аналітиків із зростанням доходу на 58% (порівняно з аналогічним періодом минулого року), прогнози GitLab на перший квартал і 2024 фінансовий рік виявилися нижчими, ніж очікувалося.

Також Gitlab повідомила, що у квітні вартість її преміум-сервісу зросте до $29 на місяць (зараз — $19).


Нагадаємо, GitLab — компанія-постачальник ПЗ для управління вихідним кодом, заснована у 2011 році українцями Дмитром Запорожцем і Валерієм Сизовим. Вона стала «єдинорогом» й була оцінена у мільярд доларів ще у 2018 році.

У 2021 році компанія вийшла на IPO та дебютувала на Nasdaq зі зростанням на 69%, але ейфорія навколо цього моменту швидко вщухла, оскільки її акції впали на 48% у 2022 році через суворий економічний клімат у технологічній галузі.

Станом на січень 2022 року штат GitLab налічував понад 1630 співробітників, усі вони працювали віддалено, тому в лютому 2023 року GitLab довелося звільнити 7% (або 130) працівників. За останні шість місяців акції компанії впали більш ніж ніж 27%.

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось1
До обраногоВ обраному0
LinkedIn

Схожі статті




11 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Я втратив розуміння, чим Gitlab буде кращою за конкурентів, які товстіші у рази і мають супутні сервіси. Atlassian має цілий стек (по більшости — закінчене невиліковне лайно, але піпл хаває, особливо менеджери всіх сортів). Github підтримується Microsoft-ом. Що таке є у Gitlab, крім цін?
Можливість поставити у себе? Таких багато.
CI в тому ж флаконі? У них свій CI? Jenkins pipelines не працюють?
Git вебморда? (Єдина з нормальною функціональністю, яку бачив поки — Gerrit. Gitlab, Github, Bitbucket це засоби для приниження Git до розподіленого CVS.)
Що ще у них таке, що має сенс користуватись?

Ну, дійсно, там нема нічого такого щоб «кидаємо усе і переходимо на Гітлаб». Але у цілому достатньо працездатна штука, зрозуміла, добре документована. Підтримка, ком’юніті, прогресує. Тому великих проблем не бачу. І таке в індустрії скрізь, є небагато речей функціонал яких не перекривался б функціоналом конкурентів.

PS. Atlassian — 100%. Воно задовбало у смерть, мігруємо, що найменше, з Bamboo+Bitbucket.

Ми користуємось як self hosted git сервер, де зручно керувати користувачами + CI. А ... ну і docker registry там ще корисний для образів, які CI білдить.

Доречі ... щодо «git-вебморда» ... частково так ... але базового функціоналу достатньо ... ніхто в нас в команді не мержить і не ребейсить через веб.

Альтернативи толком я не знаю.
— Github — НЕ self hosted.
— Jenkins+Gerrit? Це точно простіше і краще ніж Gitlab?

ніхто в нас в команді не мержить і не ребейсить через веб.

А ревʼю через що проводите?
Що я маю на увазі: ось наприклад тут. Червоний и зелений — зміні в цьому коміті, блакитний і жовтий — в базі. Patchset 19 (щось складне і бурхливе коїлось), але можна легко подивитись і зрозуміти кожний крок обговорення і змін по ньому. Це дає роботу вже як з Git, а не як з розподіленим CVS:) Там де нема аналогів — в комітах страшенний бруд, ізолювати причину змін, особливо через кілька років, часто неможливо. Я не те щоб багато бачив Gitlab, але в ньому такого не знайшов — навіть без виділення бази порівняти дві версії одного PR складно.

Jenkins+Gerrit? Це точно простіше і краще ніж Gitlab?

Не простіше. Але значно гнучкіше. Що до «краще», задайте оцінки виміру.

А ревʼю через що проводите?

Якщо чесно, я не впевнений, що до кінця зрозумів ваш приклад...
Давайте так:
1. В gitlab є можливість порівнювати будь-які два коміти. Наприклад: gitlab.com/...​aight=false&view=parallel
2. Також можна коментувати зміни.
3. Для merge request-ів там також є інструменти. Наприклад, таке: gitlab.com/...​b/-/merge_requests/114997 (правда, багато смачних речей тут лише в платній версії)

Але, власне, для маніпуляцій з деревом, ми частіше користуємось локальними UI: TortoiseGit, SmartGit.

Якщо я вірно розумію, то у вашому прикладі ви порівнюєте два патчі, при цьому застосовані до різних комітів. Якщо чесно, ніколи не виникало бажання побачити саме таке порівняння. В яких випадках це вам стає в нагоді? Якось звиклось працювати в термінах «merge-ення гілок», а не «застосування патчів».

порівняти дві версії одного PR складно

Я вірно розумію, що у вашому прикладі є дві гілки з різними предками з main-ом, які роблять однакову задачу і ви намагаєтесь обрати яку з них мержити в main?
Це цікаво :) ... я, напевно, б гялнув два diff-и: по одному на кожну гілку між гілкою і її парентом з main.

Не простіше. Але значно гнучкіше.

Насправді, не виключено ... мені складно об’єктивно порівняти, так як з gitlab ми працюєм понад 7 років, а про jenkins та gerrit лиш доводилось бачити збоку.

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

Є реалізація задачі, яка складається з ланцюжку комітів, наприклад: A) рефакторінг, B) додавання бібліотечної функції, C) додавання цільової реалізації. Може, передними ще X) видалення непотрібного коду.
На ревʼю подана версія 1 (patchset 1 у термінах Gerrit). Отримані зауваження. Виправлені версії кожного з комітів запропоновано знову. Це буде patchset 2 для кожного коміта.
Щоб ревʼюєр не переглядав знову все ще він вже бачив — бо інакше око замилиться майже одразу — спочатку запитується порівняння patchset 1 з patchset 2, потім — вже для швидкого перегляду, чи не зламана загальна ідея — base з patchset 2.
І ось для комітів 2 і 3 вже конче потрібно мати можливість розрізняти два джерела різниці між ними — в самих комітах і в їх батьках.
Тобто, переглядаючи різницю B2-B1, треба від неї відділити A2-A1. Для С2-С1 — відділити (B2-B1) (повна, що включає в себе A2-A1). Ця різниця показується блакитним і жовтим. І тільки те, що залишилось — тобто (C2-C1)-(B2-B1) — як власне різницю (червоним і зеленим).

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

І ось цього я більше ніде не бачив.

Якось звиклось працювати в термінах «merge-ення гілок», а не «застосування патчів».

Одне іншому не протирічить. Гілка — ок, гілка. Але без сміття типу «ой я ще тут два місця забув де міняти», і при тому, якщо треба, як послідовність чистих комітів (за squash всього в єдину брудну купу — виганяти з професії).

Я вірно розумію, що у вашому прикладі є дві гілки з різними предками з main-ом, які роблять однакову задачу і ви намагаєтесь обрати яку з них мержити в main?

Ні, завжди мержиться тільки остання ревізія. Див. вище.

1. В gitlab є можливість порівнювати будь-які два коміти.

Але різницю в батьках воно ж не відділить?

Але, власне, для маніпуляцій з деревом, ми частіше користуємось локальними UI: TortoiseGit, SmartGit.

Ми теж. Але ж на ревʼю з них не віддаси.

Цікавий workflow ... я вірно зрозумів, що коли відбувається merge, то в кінці він виглядає як merge чистих комітів main0->A -> B -> C->main1 (з вашого прикладу)?

Так як ми зараз працюєм, це виглядало б як main0->A1->B1->C1->A2->B2->C2->ABC3->main1.
Тобто, якщо коміт зроблений, то лише в дуууже рідкісних випадках ми його переробляєм (зазвичай лише на етапах, поки коміт лежить локально). Всі виправлення йдуть в наступних комітах поверх попередніх.

В такому випадку, немає проблеми хронологічно дивитись на зміни під час review (можна глянути main0 vs ABC3, а можна і С1 vs A2, наприклад). В нас не появляється «наступної версії коміта A», а просто наступна зміна.

В кінці, звісно, ми не маєм гарної історії ... але за ціль це не ставиться.

Можливо, для великого публічного open source наш підхід є не дуже добре. І тут гарна історія може мати більшу цінність.

Але для закритих проектів це працює дуже не погано.

Цікавий workflow ... я вірно зрозумів, що коли відбувається merge, то в кінці він виглядає як merge чистих комітів main0->A -> B -> C->main1 (з вашого прикладу)?

Да.

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

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

Але для закритих проектів це працює дуже не погано.

Ми і в закритому так робили на попередніх роботах. Корисно, коли підіймаєш «а чим саме його зламали 10 років тому?»

Ви розповіли про цікавий підхід. Сьогодні вдалося дізнатись щось нове :)

Корисно, коли підіймаєш «а чим саме його зламали 10 років тому?»

Щодо цього ... якщо в репозиторії не повний хаос, то з тим піходом, що описував я, проблем з трекінгом «коли і що зламали» особливо немає.

З тих випадків, коли треба було щось знайти більше зустрічався з іншою проблемою. Якщо відбувається великий рефакторинг, де переносяться/переназиваються файли і при цьому міняються в структурі ... в цих випадках git не розуміє, що то move/rename і вважає, що там add/remove... і історія обривається на таких рефакторингах.

в цих випадках git не розуміє, що то move/rename і вважає, що там add/remove... і історія обривається на таких рефакторингах.

Є таке. Жалкую, що в Git не ввели можливість довільних метаданих, в яких можна було б додавати такі подробиці, і щось на зразок «алгебри патчів» з Darcs.

Скажимо так, філософія Gerrit відрізняється від Gitlab/Github і в цьому його перевага. Gerrit набагато краще піходить для командної роботи над проектами із багатьма репозитаріями і на проектах, де код-ревью — не фікція.

Підписатись на коментарі