Комментарии 57
Но вот как трекер — довольно убог. Поиск по тикетам работает криво, непонятно что где ищется, и ещё в этой версии 8.9 навигацию переделали так, что без 100 грамм не разберёшься.
Попытался настроить нотификацию, при создании новых юзер — бесполезно: в документации написано одно, в программе — другое.
Да похоже, что у них у самих всё настроено криво, потому что в их SaaS спамят нещадно.
Как 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, или что там у вас в вашей операционке ;)
Вопрос можно ли както настроить отображение субмодулей в списке файлов.
Очень удобно это сделанно на github. субмодуль просто показывается как папка в общем списке. в gitlab субмодули находятся после всех файлов, что неудобно.
Спасибо за фидбэк! С 5 версии — это круто!
Создал issue про сабмодули: https://gitlab.com/gitlab-org/gitlab-ce/issues/19721
Если я что-то упустил, допишите там в комментариях плз.
Упс, вот правильный линк: https://gitlab.com/gitlab-org/gitlab-ce/issues/19727
Не холивара ради, а вот чисто со своей колокольни и с опытом использования того же 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, сегодняшнее :) уж очень умилило.
это, если что, 12 коммитов, к каждому был указан ID задачи. собрать и сгруппировать — не судьба, видимо.
(да, мне лень заводить тикет по продукту, который мне уже не интересен, поэтому картинка тут, а не на gitlab.com)
Спасибо за репорт, я создал: https://gitlab.com/gitlab-org/gitlab-ce/issues/20479
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
Второй список статусов часто встречается для описания процесса (workflow) управления задачами.
Для управления большим количеством задач и исполнителей важна иерархия задач. Для управления разработкой нескольких продуктов множеством команд аналитиков, разработчиков, тестировщиков одними задачами не обойтись — нужны типы объектов управления со своей иерархией и своим workflow. Для этого и нужны отдельные продукты Jira, RedMine, SBM.
Реализация таких сложных сущностей и отношений в GitLab может получиться слишком громоздкой. Где грань?
Проще говоря, не нужно создавать систему управления проектов, но неплохо бы создать нормальный, а не легковесный треккер задач.
В догонку. Не знаю насколько это подойдет к вашему процессу, но на следующий релиз запланирован встроенный в ГитЛаб issue board:
Возможно это закроет некоторые из ваших нужд. А вообще есть подозрение, что для вашего процесса вам нужен чуть более сложный инструмент, чем GitLab issues, что и предложил aionin. Я, например, сомневаюсь что появится трэкинг времени в ГитЛабе.
Ну или подумать над упрощением процесса. Большинство описанных вами статусов будут по сути дублировать определенные состояния в системе:
- new — тикет создан, но ни на кого не навешан
- research — тикет на кого то навешан, но не создан MR
- development — создан MR с пометкой [WIP]
- testing — MR перевешан на тестировщика, из названия MR убран [WIP]
- acceptance — MR перевешан на code reviewer-а
- closed — MR смержен, тикет закрыт
И неплохой коробочный вариант в worksection.
Идея комбайна (code version, таск, ci,...) — очень правильная, но если это какой-то конкретный комбайн это будет не удобно. Нужна кастомизация и настраиваемый процесс. Кто-то работает по часам, а кто-то аджайл. Нужны предустановки, либо возможность настроить свой процесс.
А так очень хороший продукт, приятно смотреть, как развивается.
(настройка билдов правкой yml-файликов — это красноглазие 90lvl)
В Jenkins 2 тоже добавили Jenkinsfile
Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
Буду рад, если получится помочь. По-порядку:
Тяжеловесность — известная проблема. Знаем про нее и активно работаем над этим
Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.
Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.
Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.
- Спам — это проблема. Но пока возможность пожаловаться на юзера решает проблему — спам аккаунты закрываются в течение дня-двух. Альтернатива — считать всех пользователей по умолчанию спамерами, и просить вводить капчу. Надеюсь до этого не дойдет. А спамеры как-то прямо вас тревожили на GitLab.com?
У меня стоит Gitlab CE
*Нотификации*:
— Я хочу открыть регистрацию, чтоб люди могли приходить и писать feature requests. Но боюсь спама. Поэтому я хотел, чтобы мне приходили нотификации, когда создаётся новый пользователь. И вот тут
http://docs.gitlab.com/ce/workflow/notifications.html
написано, что вроде бы есть такой `event`: «New user created»
Но найти это у себя в Гитлабе я при всём старании не смог.
Верните старую менюшку, пожалуйста!
Так, чота отвык я от Хабра. Сейчас буду разбираться как тут все работает заново
Вот сейчас у меня 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 и руками запускать деплой, когда надо:
Да здравствуют фразы: «Отдай каталог/файл!», «Да я быстро», «Ой, я забыл блокировку снять» и т.д.
Гит изначально был придуман, чтобы избежать данной проблемы. Зачем вводить эту сомнительную фичу?
Спасибо за фидбэк! На самом деле то что боковая панель стала бесполезной — это отлично. Значит цель редизайна достигнута. Все что должно быть под рукой переехало наверх.
Вот пост автора ГитЛаба про редизайн: https://about.gitlab.com/2016/06/06/navigation-redesign/
Да, это вполне вероятный сценарий, было бы круто уметь такое предотвращать. Создал тикет: 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 есть, я правда сам не пробовал ее. Можете рассказать что в ней не хватает?
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 человек
- Jenkins через https://github.com/jenkinsci/gitlab-plugin. В последних версиях его наконец допилили, работает вполне пристойно. Поддерживает все фичи вроде merge when build succeeded и т.п.
- С Redmine все хуже, есть только поддержка ссылок на Issues через соотв. Service у проекта в GitLab
Так что надеялся на улучшение качества продукта :) и тут такой подарок!!!
Чтобы обойти эту проблему, мы добавили возможность ручной блокировки файлов в GitLab.
Ура, теперь опция «не трогай, я редактирую» доступна и в CVS
Gitlab — отличный продукт, однако мне интересно, есть ли в планах следующие фичи?
- синтаксис поиска как на Github
- возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)
- возможность быстрой смены пользователя
Я не слышал про такое в планах, но возможность добавлять SSH-ключи для групп звучит интересно.
Насчет поиска и смены пользователя — можете рассказать про ваши сценарии использования?
Зачем вам нужно менять пользователя вообще? И для чего вам бы пригодился такой поиск?
Новая версия GitLab 8.9