Как стать автором
Обновить

Комментарии 57

Как морда для GIT — Гитлаб очень неплох, хотя и несколько тяжеловесен.

Но вот как трекер — довольно убог. Поиск по тикетам работает криво, непонятно что где ищется, и ещё в этой версии 8.9 навигацию переделали так, что без 100 грамм не разберёшься.

Попытался настроить нотификацию, при создании новых юзер — бесполезно: в документации написано одно, в программе — другое.
Да похоже, что у них у самих всё настроено криво, потому что в их SaaS спамят нещадно.
Вообще странный комбайн. Git+трекер+ci. Причём каждый из компонентов (ну, кроме разве что обвязки гита — оно вполне неплохо) проигрывает самостоятельным продуктам в соответствующих категориях.
Как CI-сервер — ужасно неудобен (настройка билдов правкой yml-файликов — это красноглазие 90lvl).
Трекер — коряв и ограничен.
Git, вроде, ещё туда-сюда, но как полезешь в его api, чтоб снаружи привязаться — неожиданные «удивлялки» на каждом шагу.
Интеграция со сторонними компонентами — на уровне каких-то полухромых скриптиков и иногда работающих плагинов.
В общем, на мой взгляд, разве что для мелких красноглазых команд, которые хотят всё в одном месте чисто от лени.

1) Могу пояснить за комбайн :)
Я поначалу как пришел в ГитЛаб, тоже недоумевал, почему в 2016 году, когда все пилят большие монолитные приложения на отдельные сервисы, ГитЛаб поступает ровно наоборот :)
Идея именно в том, чтобы весь процесс разработки можно было вести не выходя из ГитЛаба. В идеале:


  • В чате обсудили фичу
  • Из этого же на лету создали issue
  • Поставили в план в issue board
  • Прямо в браузере закодили чего-нибудь с помощью встроенной IDE, если не охота чекаутить на локальную машину
  • Тесты прогнались в CI
  • Провели Code review в Merge Request-e
  • Задеплоили из того же CI
  • Задокументировали чего надо в Wiki

Это то направление, куда движется продукт. Подробнее здесь. Надеюсь теперь этот комбайн начал обретать некоторый смысл для вас


2) За счет того что CI встроен в ГитЛаб, не нужно бегать между двумя сервисами, все в одном интерфейсе, и стало возможным запилить фичу "Merge when build succeed" — т.е. не нужно бегать и проверять а прошел ли билд, чтобы смержить его руками. Поставил галку — и иди занимайся следующей фичей.


3) Насчет CI и yml-файлов. А по-другому — это как? Я просто сам рубист, и у нас так все жизнь везде было, и это кажется очень естественным способом конфигурить. Опять же, version control для самого конфига — это же добро, не так ли?


Мне вчера попалась презентация про GitLab CI (ее автор никак не связан с ГитЛабом) — и там в общем прямо противоположное мнение. Посмотрите.


4) Расскажите пожалуйста, чего не хватает в трекере, и в чем корявости? По-моему за последние несколько релизов его не слабо так прокачали: Due date, веса для меток, возможность создавать скрытые iussues.


5) Интеграция со сторонними компонентами не сопоставима, конечно, с тем же ГитХабом. Но и компания сама пока поменьше. Плюс, если можно встроить что-то в сам продукт, то приоритет будет отдаваться этому, нежели чем созданию интерфейсов для интеграции. Это как раз следствие философии компании.


6)


В общем, на мой взгляд, разве что для мелких красноглазых команд, которые хотят всё в одном месте чисто от лени.

Ммм, так, да не так. Большинство денег компании приносят большие компании. Для них возможность одним инструментом закрыть кучу проблема — большое благо.
Плюс им гораздо проще платить за одну тулзу, чем разбираться с ценовой политикой и политикой лицензирования десятка продуктов. Плюс потом их все еще отдельно устанавливать и интегрировать между собой.


ГитЛаб же ставится тупо с помощью apt-get install, или что там у вас в вашей операционке ;)

Спасибо за Гитлаб. Используем у себя в компании. Пользуемся гдето с 5 версии. И если чесно редизайны каждый год немного достали))

Вопрос можно ли както настроить отображение субмодулей в списке файлов.
Очень удобно это сделанно на github. субмодуль просто показывается как папка в общем списке. в gitlab субмодули находятся после всех файлов, что неудобно.

Спасибо за фидбэк! С 5 версии — это круто!


Создал issue про сабмодули: https://gitlab.com/gitlab-org/gitlab-ce/issues/19721
Если я что-то упустил, допишите там в комментариях плз.

Не холивара ради, а вот чисто со своей колокольни и с опытом использования того же gitlab.


1) На КАЖДОМ шаге есть гораздо более гибкий инструмент. Большие компании обречены (по идее) упираться в куций функционал GitLab и


  • Строить свои бизнес-процессы вокруг GitLab (подстраиваясь под продукт, который как-бы должен удовлетворять их нужды)
  • Выносить часть функционала в другие приложения и в этом месте получать полный букет несовместимостей.

Под несовместимостями я имею виду почти полное отсутствие поддержки GitLab со стороны других продуктов (это, мол, ещё кто такие?), вялую/обрывочную поддержку этих продуктов средстванми самого GitLab (оно и ясно — за всеми не угнаться) и мутный/нелогичный API, на который завязываться сам одуреешь.


2) Эта "убер-киллер-фича" есть где угодно. Да хоть в Bitbucket том же. В TeamCity есть automerge емнип.


3) А у нас в разработке ruby вообще нигде рядом не валялся и лезть ещё и в эту фигню ради CI ну вообще ни разу не логично. Когда разработчик ещё и сам себе CI/CD строит — это неразумное использование ресурса этого самого разработчика.


4) А если сравнить с кастомным workflow в Jira, хотя бы?
В общем-то все наши потуги с GitLab закончились именно по причине слишком кривой и муторной интеграции с уже имеющейся и работающей JIRA. Вернее, интеграция заканчивается на парсинге JIRA IssueID и замене их на ссылку. Вот и вся интеграция.


5) Самое смешное в этой интеграции — это gitlab rest api. Он так старается копировать GitHub API, но при этом местами отличается. Т.е. всё, что делается под GitHub, могло бы работать и с GitLab, если бы не "там слово другое, тут те же статусы называются иначе" и т.п.


ps: Личная обида: мой pull-request на Commit status publisher для TeamCity с поддержкой GitLab провисел у них месяца два, после чего был закрыт со словами "мы это, так и быть, запилим в 10й версии, а вы со своим TeamCity 9 сидите как хотите".
Со стороны Atlassian Confluence/Jira в сторону GitLab всё вообще ужасно.
Для меня это некий общий показатель отношения к продукту, так что о какой-то интеграции можно даже не заикаться. Он не нужен и не интересен никому, кроме вас самих. А вы не спешите дружить с другими системами именно из-за идеологии "у нас свой комбайн".

Я разрабатываю на джаве и у нас тоже ямлы всюду… Думал уже стандарт для конфигурирования де факто…

Спасибо за ваше мнение. Я думаю что продукты нужны всякие.
И видимо ГитЛаб просто не подходит для ваших нужд и вашего процесса разработки.


C Jira трекер ГитЛаба сравнивать не надо. Это очевидно продукты в совершенно разной весовой категории. Если уж сравнивать, то с ГитХабом.
P.S. я надеюсь что ГитЛабовский трекер никогда не превратится в Jira. Это было бы печально.


Вы кстати какую версию интегрировали с Jira? В Community edition полная поддержка Jira появилась только в 8.3: http://docs.gitlab.com/ce/project_services/jira.html


ГитЛаб — сравнительно молодой продукт, и было бы странно расчитывать на такую же его поддержку как и ГитХаба. Но это плавно меняется, кстати говоря. Ваш пример — тому подтверждение. +Картинка с google trends:


Если мне не изменяет память, то 8.4, 8.5, 8.6, а потом забили окончательно. сейчас часть проектов доживает в 8.6.5 (чисто как обёртка над гит), но вся разработка оттуда вынесена уже к чертям, чтоб больше не пинать этот труп.


Да я не спорю. Совершенно стандартная ситуация с комбайнами и выделенными решениями. Либо ты подстраиваешься под комбайн, либо подстраиваешь всё сам под себя.

Вдогонку про "интеграцию" с JIRA, сегодняшнее :) уж очень умилило.
image


это, если что, 12 коммитов, к каждому был указан ID задачи. собрать и сгруппировать — не судьба, видимо.
(да, мне лень заводить тикет по продукту, который мне уже не интересен, поэтому картинка тут, а не на gitlab.com)

3) Вы так и не ответили на вопрос "А чем конфигурить то"?


У Jenkins Jenkinsfle на groovy, у travic тоже yml.


У остальных в основном просто скрипты.

Расскажите пожалуйста, чего не хватает в трекере

Нет (или не нашёл) возможности создавать вложенные задачи хотя бы на одном уровне. Нет (или не нашёл) возможности настраивать воркфлоу задачи, как-то отслеживать прогресс её исполнения.

Не, можно, конечно, в дескрипшене создать список подзадач и отмечать там их исполнение, и метками манипулировать, отмечая статус задачи, но не удобно, а потому никто этим не занимается.

Да, обычно в описании просто создается список задач: https://gitlab.com/gitlab-org/gitlab-ce/issues/14838
Мне нравится идея для задач, где в описании есть такие списки, показывать процент выполненного на основе проставленных галочек. Запилю feature request, если этого еще нет в планах.


А какие у вас статусы у задач и для чего вы их используете? Интересно какой у вас процесс разработки.

Да, приходится так эмулировать отсутствующую функциональность, но:

— связь просто на уровень встречных гиперссылок, создаваемых вручную. То есть создаёшь одну задачу, потом вторую, а потом проставляешь в них ссылки друг на друга. Никакой поддержки со стороны системы нет. И неудобно, и можно просто забыть, и ошибиться.

— в общем списке задачи всё равно вываливаются на одном уровне, что не позволяет хотя бы приблизительно оценить количество глобальных задач в работе

— нет оценки требуемого времени, дью дейт — не совсем-то, особенно для вложенных задач. Не у всех процесс разработки привязан к дедлайнам или вехам, есть ASAP. Часто ситуация, когда разработчик даёт оценку нужного ему времени, задаче назначают приоритет (в идеале точечно), когда более приоритетные задачи кончаются, разработчик приступает к задаче, если вдруг приходит более приоритетная, то он текущую откладывает, фиксируя (в идеале полуавтоматом) уже потраченное время, а потом возвращается. Так же автоматом фиксирует время при закрытии. Ну и если видит, что задача оказалась сложнее, то корректирует эстимейт (как вариант просит менеджера это сделать).

Глобальных статусов немного:
— new
— research
— development
— testing
— acceptance
— closed
но на почти каждый хотелось бы подстатусы:
todo
in progress
suspend
rejected

Первый список статусов вполне узнаваем. Но не задач, а требований или user-story, кому как нравится.
Второй список статусов часто встречается для описания процесса (workflow) управления задачами.
Для управления большим количеством задач и исполнителей важна иерархия задач. Для управления разработкой нескольких продуктов множеством команд аналитиков, разработчиков, тестировщиков одними задачами не обойтись — нужны типы объектов управления со своей иерархией и своим workflow. Для этого и нужны отдельные продукты Jira, RedMine, SBM.
Реализация таких сложных сущностей и отношений в GitLab может получиться слишком громоздкой. Где грань?

Ну, как по мне, не нужно создавать новые типы объектов, но можно добавить поля и UI к ним для связи существующих issue и/или todo между собой и возможность создавать произвольные статусы а не только open/closed todo/done

Проще говоря, не нужно создавать систему управления проектов, но неплохо бы создать нормальный, а не легковесный треккер задач.

В догонку. Не знаю насколько это подойдет к вашему процессу, но на следующий релиз запланирован встроенный в ГитЛаб issue board:


Возможно это закроет некоторые из ваших нужд. А вообще есть подозрение, что для вашего процесса вам нужен чуть более сложный инструмент, чем GitLab issues, что и предложил aionin. Я, например, сомневаюсь что появится трэкинг времени в ГитЛабе.


Ну или подумать над упрощением процесса. Большинство описанных вами статусов будут по сути дублировать определенные состояния в системе:


  • new — тикет создан, но ни на кого не навешан
  • research — тикет на кого то навешан, но не создан MR
  • development — создан MR с пометкой [WIP]
  • testing — MR перевешан на тестировщика, из названия MR убран [WIP]
  • acceptance — MR перевешан на code reviewer-а
  • closed — MR смержен, тикет закрыт
Следующий, это уже 8.11? Обязательно попробуем. Спасибо
Практически идеальный, на мой взляд, треккер в Redmine — тем, что очень гибко настраивается и интегрируется со всем, чем угодно (git, jenkins, даже с IDE) и расширяется плагинами.
И неплохой коробочный вариант в worksection.

Идея комбайна (code version, таск, ci,...) — очень правильная, но если это какой-то конкретный комбайн это будет не удобно. Нужна кастомизация и настраиваемый процесс. Кто-то работает по часам, а кто-то аджайл. Нужны предустановки, либо возможность настроить свой процесс.

А так очень хороший продукт, приятно смотреть, как развивается.
Да, поэтому приходится прикручивать redmine. Очень хочется что бы когда-нибудь появилась возможность разбивать на подзадачи.

Насчет прогресса — понял, что это уже реализовано:



Сам тикет здесь

Но ведь в travis также все делается через yml файл настроек, в гитлабе очень грамотно сделана поддержка билдов на докере — можно все запустить локально, а сам файл yml оставить на уровне команд для запуска.
(настройка билдов правкой yml-файликов — это красноглазие 90lvl)

В Jenkins 2 тоже добавили Jenkinsfile

Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
Буду рад, если получится помочь. По-порядку:


  1. Тяжеловесность — известная проблема. Знаем про нее и активно работаем над этим


  2. Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.


  3. Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.


  4. Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.


  5. Спам — это проблема. Но пока возможность пожаловаться на юзера решает проблему — спам аккаунты закрываются в течение дня-двух. Альтернатива — считать всех пользователей по умолчанию спамерами, и просить вводить капчу. Надеюсь до этого не дойдет. А спамеры как-то прямо вас тревожили на GitLab.com?
Ну в первую очередь — спасибо за Гитлаб. При всех недостатках — да, это лучшее, что я вижу по совокупности функциональности.

У меня стоит Gitlab CE

*Нотификации*:
— Я хочу открыть регистрацию, чтоб люди могли приходить и писать feature requests. Но боюсь спама. Поэтому я хотел, чтобы мне приходили нотификации, когда создаётся новый пользователь. И вот тут
http://docs.gitlab.com/ce/workflow/notifications.html
написано, что вроде бы есть такой `event`: «New user created»
Но найти это у себя в Гитлабе я при всём старании не смог.

Верните старую менюшку, пожалуйста!

Так, чота отвык я от Хабра. Сейчас буду разбираться как тут все работает заново

Кстати, не подскажете, какой общий подход к тому, чтобы CI настроить так, чтобы job могла деплоиться в одну из нескольких ENVs по выбору?

Вот сейчас у меня Jenkins, и я сделал там LISTBOX, из которого я выбираю DEV, STAGING,… и запускаю job. А в Гитлабе накиких LISTBOX добавлять вроде бы нельзя. Получается, что перед каждый запуском надо редактировать job variables? Или есть какой-то более прямой путь?

Можно прописать чтобы в staging деплоились все ветки кроме master. А в production — только master. Это делается с помощью опций only и except. Кусок конфига:


`
staging:
  stage: deploy
  script:
  - deploy somehow --staging
  except:
  - master
  environment: staging

production:
  stage: deploy
  script:
  - deploy somehow --production
  only:
  - master
  environment: production
`

Полный пример


Плюс в последнем релизе появилась возможность в конфиге можно указать when: manual и руками запускать деплой, когда надо:

> Блокировка файла не позволяет никому, кроме Вас, изменять определенный файл или целый каталог.

Да здравствуют фразы: «Отдай каталог/файл!», «Да я быстро», «Ой, я забыл блокировку снять» и т.д.
Гит изначально был придуман, чтобы избежать данной проблемы. Зачем вводить эту сомнительную фичу?

В переводе пропустили пример про Game assets, объясняющий зачем нужна эта фича. Я вернул этот блок в статью.
Эта штука важна для разработчиков игр, и тех, кому приходится держать в репозиториях бинарные файлы.

Использую Gitlab CE как на работе, так и для своих проектов. Продукт очень качественный. Не знаю за что ругают Gitlab CI, как по мне так он идеален. И то что runner'ы можно на нескольких серверах быстро развернуть, и артефакты теперь можно хранить заданный промежуток времени, и зависимости указывать, и конфиг удобный. Единственное что напрягает в новой версии — навигация. Реально стало не понятно и не удобно. Боковая панель стала для меня бесполезной.

Спасибо за фидбэк! На самом деле то что боковая панель стала бесполезной — это отлично. Значит цель редизайна достигнута. Все что должно быть под рукой переехало наверх.


Вот пост автора ГитЛаба про редизайн: https://about.gitlab.com/2016/06/06/navigation-redesign/

Единственный недочет с которым мы столкнулись используя gitlab ci, что он запускает все задачи на каждый push например может произойти такая ситуация: делаем пуш — прошли тесты — начался деплой, в это время пришел еще один пуш и начался параллельно второй деплой. нету возможности встать в очередь и приходиться реализовать самому блокировку от паралельных деплоев.

Да, это вполне вероятный сценарий, было бы круто уметь такое предотвращать. Создал тикет: https://gitlab.com/gitlab-org/gitlab-ce/issues/20481

1) Хочется интеграции с Jenkins, ибо Gitlab CI — недоделка.
2) Как Git, работает нормально, нареканий нет. Кроме идиотского "merge when builds", которое пришлоссь отрубать из-за Gitlab CI.
3) Понятно, то никто не пользуется Issues, вам бы взять Redmine и JIRA хотя бы проинтегрировать, было бы СЧАСТЬЕ.

1) Привет. А расскажи, чего по твоему не хватает в GitLab CI? Я сейчас как раз работаю над статьей про него.


2) Что не так с "merge when builds"? Я правильно понял что вы не пользуетесь CI, и эта фича как-то мешала вам?


3) Я думаю что "никто" — это все таки преувеличение. Понятно что если у вас уже есть issue трэкер, которым вы пользуетесь годами, переезжать на новый — трудозатратная процедура. Насколько я знаю, интеграция с Jira есть, я правда сам не пробовал ее. Можете рассказать что в ней не хватает?

У меня были пара проблем с gitlab-ci

1) При интенсивном выводе в stdout очень сильно тормозил браузер при просмотре лога работы тестов
2) При использовании кеширования (cache в gitlab-ci.yml) и одновременном запуске двух билдов похоже, что для второго билда кеш не используется (соответственно выкачивается всё что можно из интернета)

Создал issue на (2):https://gitlab.com/gitlab-org/gitlab-ce/issues/20477
Мне кажется я тоже подобное замечал. Спрошу у ребят из команды CI сегодня про это.


По (1) — маловато информации для создания issue имхо. Вот бы чуть побольше деталей: какие команды выполнялись, может пример лога, или ссылка, если проект публичный.

Выяснил что чтобы работало (2), нужно настроить sharing между раннерами с помощью S3-based кэша

Используем GitLab + Redmine + Jenkins на команду ~10 человек


  1. Jenkins через https://github.com/jenkinsci/gitlab-plugin. В последних версиях его наконец допилили, работает вполне пристойно. Поддерживает все фичи вроде merge when build succeeded и т.п.
  2. С Redmine все хуже, есть только поддержка ссылок на Issues через соотв. Service у проекта в GitLab
А мы вот наоборот, потихоньку, мигрируем с jenkins на gitlab-ci. Основные причины — конфиг CI лежит в вместе с проектом, тестируем в контейнерах, для некоторых проектов свои контейнеры (например ffmpeg собранный с определенными ключами) и баджи с результатом билда в merge request-ах. С jenkins не получилось толком интегрировать gitlab ce (видимо для качественной интеграции нужен gitlab ee).

Для jenkins можно попробовать Jenkinsfile

Сделали из Git subversion. Молодцы какие. Хорошо, что я застрял где-то на 7ой версии гитлаба без всяких CI, чатов, треккеров, блокировок файлов, которые не нужны мне, а выкинуть их нельзя.
Так можно ж не пользоваться? Я тоже думаю поставить GitLAB, и проинтегрировать с RedMine и Jenkins (а может и MediaWiki)

Чата встроенного нет, не переживайте :) Блокировка — это вообще отдельная опция для EE.


СI и issue tracker можно отключить в настройках проекта:


Кстати я занимался GitLab и GitLab CI фулл тайм.
Так что надеялся на улучшение качества продукта :) и тут такой подарок!!!
Чтобы обойти эту проблему, мы добавили возможность ручной блокировки файлов в GitLab.

Ура, теперь опция «не трогай, я редактирую» доступна и в CVS
Может хочется странного, но хочется иметь «кнопку» для выпуска релиза — merge ветки в develop в master с интерфейса gitlab (с возможностью задать теги, комментарии). Сейчас релизы делаем или через merge request (develop -> master) в gitlab или вручную объединяем ветки и пушим в мастер.

Gitlab — отличный продукт, однако мне интересно, есть ли в планах следующие фичи?


  • синтаксис поиска как на Github
  • возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)
  • возможность быстрой смены пользователя
+100500 за «возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)». Просто ужас как не хватает, особенно когда проект состоит из множества мелких модулей находящихся в одной группе.
А что мешает просто пользователя добавить в группу? Или я что-то непонял вашу задачу.
Речь про deploy keys в данном случае. Они только для проектов добавляются и, чтоб тот же npm или composer могли тянуть себе модули при деплое приложения, приходится в каждый модуль-проект добавлять ключи прод и стейдж серверов.
Кстати, страничка добавления deploy keys стала дюже не удобная. Раньше это было что-то вроде двух-оконного менеджера, где слева добавленные в проект ключи, а справа те, которые можно добавить. А сейчас все в одном списке-куче, просто добавленные вверху списка. И чтоб добавить еще один ключ, мне несколько раз скроллить приходится и выискивать его.

Я не слышал про такое в планах, но возможность добавлять SSH-ключи для групп звучит интересно.


Насчет поиска и смены пользователя — можете рассказать про ваши сценарии использования?
Зачем вам нужно менять пользователя вообще? И для чего вам бы пригодился такой поиск?

Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.