С GitLab 8.9 комфортнее работать в больших сложных проектах. Блокировка файлов, назначение приоритетов меткам, гибкие настройки уровня вовлеченности в проект, и возможность запретить объединение веток(merge) до момента, пока билд не выполнится успешно. В GitLab CI теперь можно указывать среды(production, staging, и т.д.) и задавать срок хранения артефактов. Появились шаблоны настроек CI, так что начать им пользоваться теперь еще проще.
Персона месяца(MVP) — Руи Сантос. Он разработал возможность ограничивать обьединение веток до прохождения билда. Спасибо Руи!
С версии 8.8.0 добавилось 1761 коммитов, 1947 файла были изменены. Что конкретно изменилось — смотрите ниже.
Блокировка файлов (опция EE)
Репозиторий Git позволяет хранить не текстовые файлы (бинарные, например), но не может управлять изменениями в них — нельзя сравнить версии файла, нельзя объединить изменения из разных версий файла и т.д. Если допустить редактирование файла одновременно нескольким членам команды, то потом потребуется масса времени на ручное устранение конфликтов версий.
Чтобы обойти эту проблему, мы добавили возможность ручной блокировки файлов в GitLab. Блокировка файла не позволяет никому, кроме Вас, изменять определенный файл или целый каталог. Это также наглядный способ объявить, что Вы работаете над этим файлом.
Пример: Game assets
Вы разрабатываете игру. В разработке уровней игры может быть задействована куча народу. Заблокируйте файл уровня, над которым вы работаете, из интерфейса, кликнув на «Lock»:
Коллеги увидят, что вы работаете над этим файлом. Только вы сможете пушить коммиты, которые изменяют этот файл.
Работа над уровнем закончена? Удаляйте блокировку!
Список всех заблокированных файлов в репозитории найдете в Repository > Locked Files:
Функция блокирования файлов доступна только в редакции Enterprise Edition и на GitLab.com. Мы приветствуем ваши дополнительные предложения для расширения этой функциональности.
Среды и Развертывание в CI
В предыдущей версии GitLab появилось понятие среду развертывания: среда тестирования, среда приемки и среда промышленной эксплуатации. GitLab CI позволяет настроить последовательности развертывания (цепочки переходов между средами), по в рамках которых исполнятся задачи доставки и установки изменений.
В новой версии 8.9 Вы можете добавить дополнительные Среды в конфигурационном файле CI проекта (.gitlab-ci.yml). Это позволит настроить конфигурацию GitLab максимально близко к фактическому окружению проекта и наглядно отслеживать динамику развертывания в этих средах.
Метки с приоритетом
В крупных проектах с сотнями требованиями и тысячами задач уходит масса времени на назначение приоритетов и определение порядка выполнения работ при назначение приоритета каждому дефекту и каждой задаче по отдельности. Попробуйте новую функцию массового определения приоритета с помощью специальных меток.
Метка с приоритетом — такая же текстовая метка, но с указанием приоритета, который влияет на сортировку объектов, которым эта метка присвоена.
Например, самым высоким приоритетом для GitLab является P1. Если отсортировать дефекты по приоритету, то сверху отобразятся дефекты с P1, затем с P2 и т.д. Помечая метку «Безопасность» высоким приоритетом P1, дефекты, относящиеся к этой категории, автоматически получат максимальный приоритет.
Пользовательский тип уведомлений
Чтобы быть в курсе важных для Вас событий, мы добавили новый тип уведомлений — пользовательский.
В предыдущих версиях GitLab можно было настроить уведомления Участника (participating level), т.е. подписаться на события в объектах, в которых Вы участвуете, или в которых Вы упомянуты.
В новой версии 8.9 Gitlab позволяет настроить уведомления по другому принципу - отметить интересующие типы событий (новое примечание, новый дефект, закрытие дефекта, новый запрос на объединение, переназначение дефекта и т.д.)
Запрос доступа к проекту
Связь с владельцами проектов теперь доступна с домашней страницы проекта. Если вам нужен доступ к проекту, обратись к владельцу проекта, не выходя из GitLab. Запросы отображаются в секции участников проекта. Владельцу проекта отправляется уведомление.
Шаблоны gitlab-ci.yml
Модуль поддержки непрерывной интеграции CI, встроенный в GitLab, управляется с помощью .gitlab-ci.yml файла, где определяются объекты тестирования, сборки и развертывания. Чтобы упростить первые шаги по настройке этого файла, попробуйте воспользоваться готовыми шаблонами.
Для того, чтобы начать работу с шаблоном .gitlab-ci.yml, создайте новый файл и назовите его .gitlab-ci.yml. Вы увидите выпадающий список названий готовых шаблонов.
Изменения в навигации пользовательского интерфейса
Базовая навигация по элементам проектов осуществляется с помощью верхней панели. Страницы, которые формируются специально для текущего пользователя ( дефекты, группы, активность и т.д.) теперь перенесены в новую боковую всплывающую панель.
Поддержка Универсальной 2-факторной аутентификации
GitLab теперь поддерживает стандарт универсальной 2-факторной аутентификации (u2f). Это означает, что вы можете использовать U2F ключи безопасности на Yubico, известного как YubiKeys, в качестве 2-го фактора при входе в GitLab.
Подробнее о поддержке u2f в нашем блоге и документации по 2-факторной аутентификации в GitLab.
Импорт / Экспорт проектов
Если у Вас несколько экземпляров GitLab, или Вам необходима резервная копия репозитория, то теперь Вы можете импортировать и экспортировать проекты целиком.
Перейдите на страницу настроек проекта, чтобы экспортировать Ваш проект. Импорт проекта можно сделать из новой страницы проекта.
Запрет объединения веток до успешной сборки
В новой версии у Вас есть возможность запретить объединение веток(merge) до момента, пока билд не выполнится успешно, Благодаря Руи Сантос.
Другие изменения
Подробнее об остальных изменениях можно ознакомиться в Changelog. Ниже приведены только наиболее значимые.
Улучшенная подсветка синтаксиса
GitLab 8.9 включает в себя первый релиз Rouge с сентября (!) с поддержкой более чем 20 новых языков, а также поддержкой новых возможностей Swift, Ruby, Python и C / C ++, а также некоторых критических исправлений ошибок для Apache, JavaScript, Objective — C и Groovy.
Award Emoji в комментариях
Теперь Вы можете проголосовать по отдельному комментарию в дефектах и запросах на объединение, а также ответить конкретному человеку, не искажая ход беседы, или провести быстрый опрос.
Ручное добавление Todos
Каждый дефект и запрос на объединение теперь может быть помечен как «Todo» или «Done».
Массовое присвоение меток
С функцией назначения приоритетов, метки играют все более важную роль в GitLab. Чтобы работать с дефектами эффективнее, мы добавили возможность массового присвоения меток.
Срок действия артефактов
Если Вы используете артефакты в GitLab, встроенных в CI, у Вас может накопиться большой архив старых данных. Теперь вы можете указывать срок действия артефактов путем добавления строки expire_in в свой. gitlab-ci.yml файл. Артефакты будут считаться устаревшими, после указанного периода времени.
Вы можете по-разному указывать срок действия:
3 mins 4 sec
2 hrs 20 min
2h20min
6 mos 1 day
47 yrs 6 mos and 4d
3 weeks and 2 days
Примечание: эта функция требует Runner 1.3, выпущенный одновременно с GitLab 8.9
Ключевое слово « Когда» для Артефактов
Теперь Вы можете иметь артефакты только на провал, успех или на все события.
Поведение по умолчанию такое же, как и раньше, создание артефактов только «на успех».
Примечание: эта функция требует Runner 1.3, выпущенный одновременно с GitLab 8.9
Поддержка Docker реестра Manifest V1
GitLab 8.9 добавляет поддержку Manifest V1, порожденного старыми версиями Docker (до 1.10)
GitLab Mattermost 3.1
Mattermost 3.1 отгружается в GitLab 8.9 с мульти-командными аккаунтами, переводом японского языка, Apple Watch, с модернизированными уведомлениями, новыми горячими клавишами и переключателем каналов, новыми вариантами отображения, новыми смайликами, плюс обновление для системы безопасности и многие другие улучшения.
Обновление требует ручных операций! Перед обновлением обязательно прочитайте документацию для обновления с версий до 8.9
Комментарии (45)
m8rge
11.07.2016 21:11> Блокировка файла не позволяет никому, кроме Вас, изменять определенный файл или целый каталог.
Да здравствуют фразы: «Отдай каталог/файл!», «Да я быстро», «Ой, я забыл блокировку снять» и т.д.
Гит изначально был придуман, чтобы избежать данной проблемы. Зачем вводить эту сомнительную фичу?
nem
11.07.2016 22:21+2В переводе пропустили пример про Game assets, объясняющий зачем нужна эта фича. Я вернул этот блок в статью.
Эта штука важна для разработчиков игр, и тех, кому приходится держать в репозиториях бинарные файлы.
liderman
11.07.2016 22:11Использую Gitlab CE как на работе, так и для своих проектов. Продукт очень качественный. Не знаю за что ругают Gitlab CI, как по мне так он идеален. И то что runner'ы можно на нескольких серверах быстро развернуть, и артефакты теперь можно хранить заданный промежуток времени, и зависимости указывать, и конфиг удобный. Единственное что напрягает в новой версии — навигация. Реально стало не понятно и не удобно. Боковая панель стала для меня бесполезной.
nem
12.07.2016 13:04Спасибо за фидбэк! На самом деле то что боковая панель стала бесполезной — это отлично. Значит цель редизайна достигнута. Все что должно быть под рукой переехало наверх.
Вот пост автора ГитЛаба про редизайн: https://about.gitlab.com/2016/06/06/navigation-redesign/
reactoranime
13.07.2016 09:15Единственный недочет с которым мы столкнулись используя gitlab ci, что он запускает все задачи на каждый push например может произойти такая ситуация: делаем пуш — прошли тесты — начался деплой, в это время пришел еще один пуш и начался параллельно второй деплой. нету возможности встать в очередь и приходиться реализовать самому блокировку от паралельных деплоев.
akzhan
12.07.2016 00:21+21) Хочется интеграции с Jenkins, ибо Gitlab CI — недоделка.
2) Как Git, работает нормально, нареканий нет. Кроме идиотского "merge when builds", которое пришлоссь отрубать из-за Gitlab CI.
3) Понятно, то никто не пользуется Issues, вам бы взять Redmine и JIRA хотя бы проинтегрировать, было бы СЧАСТЬЕ.nem
12.07.2016 12:521) Привет. А расскажи, чего по твоему не хватает в GitLab CI? Я сейчас как раз работаю над статьей про него.
2) Что не так с "merge when builds"? Я правильно понял что вы не пользуетесь CI, и эта фича как-то мешала вам?
3) Я думаю что "никто" — это все таки преувеличение. Понятно что если у вас уже есть issue трэкер, которым вы пользуетесь годами, переезжать на новый — трудозатратная процедура. Насколько я знаю, интеграция с Jira есть, я правда сам не пробовал ее. Можете рассказать что в ней не хватает?
ivnik
12.07.2016 15:33У меня были пара проблем с gitlab-ci
1) При интенсивном выводе в stdout очень сильно тормозил браузер при просмотре лога работы тестов
2) При использовании кеширования (cache в gitlab-ci.yml) и одновременном запуске двух билдов похоже, что для второго билда кеш не используется (соответственно выкачивается всё что можно из интернета)
Dreef
12.07.2016 14:12Используем GitLab + Redmine + Jenkins на команду ~10 человек
- Jenkins через https://github.com/jenkinsci/gitlab-plugin. В последних версиях его наконец допилили, работает вполне пристойно. Поддерживает все фичи вроде merge when build succeeded и т.п.
- С Redmine все хуже, есть только поддержка ссылок на Issues через соотв. Service у проекта в GitLab
ivnik
12.07.2016 15:21А мы вот наоборот, потихоньку, мигрируем с jenkins на gitlab-ci. Основные причины — конфиг CI лежит в вместе с проектом, тестируем в контейнерах, для некоторых проектов свои контейнеры (например ffmpeg собранный с определенными ключами) и баджи с результатом билда в merge request-ах. С jenkins не получилось толком интегрировать gitlab ce (видимо для качественной интеграции нужен gitlab ee).
ivlis
12.07.2016 08:02-3Сделали из Git subversion. Молодцы какие. Хорошо, что я застрял где-то на 7ой версии гитлаба без всяких CI, чатов, треккеров, блокировок файлов, которые не нужны мне, а выкинуть их нельзя.
blueboar2
12.07.2016 10:58Так можно ж не пользоваться? Я тоже думаю поставить GitLAB, и проинтегрировать с RedMine и Jenkins (а может и MediaWiki)
nem
12.07.2016 12:50Чата встроенного нет, не переживайте :) Блокировка — это вообще отдельная опция для EE.
СI и issue tracker можно отключить в настройках проекта:
IT_SECURITY
12.07.2016 14:51Кстати я занимался GitLab и GitLab CI фулл тайм.
Так что надеялся на улучшение качества продукта :) и тут такой подарок!!!
maxru
12.07.2016 14:59Чтобы обойти эту проблему, мы добавили возможность ручной блокировки файлов в GitLab.
Ура, теперь опция «не трогай, я редактирую» доступна и в CVS
ivnik
12.07.2016 15:26+1Может хочется странного, но хочется иметь «кнопку» для выпуска релиза — merge ветки в develop в master с интерфейса gitlab (с возможностью задать теги, комментарии). Сейчас релизы делаем или через merge request (develop -> master) в gitlab или вручную объединяем ветки и пушим в мастер.
Chvanikoff
12.07.2016 19:02Gitlab — отличный продукт, однако мне интересно, есть ли в планах следующие фичи?
- синтаксис поиска как на Github
- возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)
- возможность быстрой смены пользователя
andycaramba
12.07.2016 20:40+100500 за «возможность добавлять ssh-ключи для групп (доступ ко всем проектам внутри группы по одному ключу)». Просто ужас как не хватает, особенно когда проект состоит из множества мелких модулей находящихся в одной группе.
a1ien_n3t
13.07.2016 00:34+1А что мешает просто пользователя добавить в группу? Или я что-то непонял вашу задачу.
andycaramba
13.07.2016 08:37+2Речь про deploy keys в данном случае. Они только для проектов добавляются и, чтоб тот же npm или composer могли тянуть себе модули при деплое приложения, приходится в каждый модуль-проект добавлять ключи прод и стейдж серверов.
andycaramba
13.07.2016 08:47+1Кстати, страничка добавления deploy keys стала дюже не удобная. Раньше это было что-то вроде двух-оконного менеджера, где слева добавленные в проект ключи, а справа те, которые можно добавить. А сейчас все в одном списке-куче, просто добавленные вверху списка. И чтоб добавить еще один ключ, мне несколько раз скроллить приходится и выискивать его.
SlavikF
Как морда для GIT — Гитлаб очень неплох, хотя и несколько тяжеловесен.
Но вот как трекер — довольно убог. Поиск по тикетам работает криво, непонятно что где ищется, и ещё в этой версии 8.9 навигацию переделали так, что без 100 грамм не разберёшься.
Попытался настроить нотификацию, при создании новых юзер — бесполезно: в документации написано одно, в программе — другое.
Да похоже, что у них у самих всё настроено криво, потому что в их SaaS спамят нещадно.
justmara
Вообще странный комбайн. Git+трекер+ci. Причём каждый из компонентов (ну, кроме разве что обвязки гита — оно вполне неплохо) проигрывает самостоятельным продуктам в соответствующих категориях.
Как CI-сервер — ужасно неудобен (настройка билдов правкой yml-файликов — это красноглазие 90lvl).
Трекер — коряв и ограничен.
Git, вроде, ещё туда-сюда, но как полезешь в его api, чтоб снаружи привязаться — неожиданные «удивлялки» на каждом шагу.
Интеграция со сторонними компонентами — на уровне каких-то полухромых скриптиков и иногда работающих плагинов.
В общем, на мой взгляд, разве что для мелких красноглазых команд, которые хотят всё в одном месте чисто от лени.
nem
1) Могу пояснить за комбайн :)
Я поначалу как пришел в ГитЛаб, тоже недоумевал, почему в 2016 году, когда все пилят большие монолитные приложения на отдельные сервисы, ГитЛаб поступает ровно наоборот :)
Идея именно в том, чтобы весь процесс разработки можно было вести не выходя из ГитЛаба. В идеале:
Это то направление, куда движется продукт. Подробнее здесь. Надеюсь теперь этот комбайн начал обретать некоторый смысл для вас
2) За счет того что CI встроен в ГитЛаб, не нужно бегать между двумя сервисами, все в одном интерфейсе, и стало возможным запилить фичу "Merge when build succeed" — т.е. не нужно бегать и проверять а прошел ли билд, чтобы смержить его руками. Поставил галку — и иди занимайся следующей фичей.
3) Насчет CI и yml-файлов. А по-другому — это как? Я просто сам рубист, и у нас так все жизнь везде было, и это кажется очень естественным способом конфигурить. Опять же, version control для самого конфига — это же добро, не так ли?
Мне вчера попалась презентация про GitLab CI (ее автор никак не связан с ГитЛабом) — и там в общем прямо противоположное мнение. Посмотрите.
4) Расскажите пожалуйста, чего не хватает в трекере, и в чем корявости? По-моему за последние несколько релизов его не слабо так прокачали: Due date, веса для меток, возможность создавать скрытые iussues.
5) Интеграция со сторонними компонентами не сопоставима, конечно, с тем же ГитХабом. Но и компания сама пока поменьше. Плюс, если можно встроить что-то в сам продукт, то приоритет будет отдаваться этому, нежели чем созданию интерфейсов для интеграции. Это как раз следствие философии компании.
6)
Ммм, так, да не так. Большинство денег компании приносят большие компании. Для них возможность одним инструментом закрыть кучу проблема — большое благо.
Плюс им гораздо проще платить за одну тулзу, чем разбираться с ценовой политикой и политикой лицензирования десятка продуктов. Плюс потом их все еще отдельно устанавливать и интегрировать между собой.
ГитЛаб же ставится тупо с помощью
apt-get install, или что там у вас в вашей операционке ;)a1ien_n3t
Спасибо за Гитлаб. Используем у себя в компании. Пользуемся гдето с 5 версии. И если чесно редизайны каждый год немного достали))
Вопрос можно ли както настроить отображение субмодулей в списке файлов.
Очень удобно это сделанно на github. субмодуль просто показывается как папка в общем списке. в gitlab субмодули находятся после всех файлов, что неудобно.
nem
Спасибо за фидбэк! С 5 версии — это круто!
Создал issue про сабмодули: https://gitlab.com/gitlab-org/gitlab-ce/issues/19721
Если я что-то упустил, допишите там в комментариях плз.
nem
Упс, вот правильный линк: https://gitlab.com/gitlab-org/gitlab-ce/issues/19727
justmara
Не холивара ради, а вот чисто со своей колокольни и с опытом использования того же gitlab.
1) На КАЖДОМ шаге есть гораздо более гибкий инструмент. Большие компании обречены (по идее) упираться в куций функционал 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 всё вообще ужасно.
Для меня это некий общий показатель отношения к продукту, так что о какой-то интеграции можно даже не заикаться. Он не нужен и не интересен никому, кроме вас самих. А вы не спешите дружить с другими системами именно из-за идеологии "у нас свой комбайн".
asm0dey
Я разрабатываю на джаве и у нас тоже ямлы всюду… Думал уже стандарт для конфигурирования де факто…
nem
Спасибо за ваше мнение. Я думаю что продукты нужны всякие.
И видимо ГитЛаб просто не подходит для ваших нужд и вашего процесса разработки.
C Jira трекер ГитЛаба сравнивать не надо. Это очевидно продукты в совершенно разной весовой категории. Если уж сравнивать, то с ГитХабом.
P.S. я надеюсь что ГитЛабовский трекер никогда не превратится в Jira. Это было бы печально.
Вы кстати какую версию интегрировали с Jira? В Community edition полная поддержка Jira появилась только в 8.3: http://docs.gitlab.com/ce/project_services/jira.html
ГитЛаб — сравнительно молодой продукт, и было бы странно расчитывать на такую же его поддержку как и ГитХаба. Но это плавно меняется, кстати говоря. Ваш пример — тому подтверждение. +Картинка с google trends:
justmara
Если мне не изменяет память, то 8.4, 8.5, 8.6, а потом забили окончательно. сейчас часть проектов доживает в 8.6.5 (чисто как обёртка над гит), но вся разработка оттуда вынесена уже к чертям, чтоб больше не пинать этот труп.
Да я не спорю. Совершенно стандартная ситуация с комбайнами и выделенными решениями. Либо ты подстраиваешься под комбайн, либо подстраиваешь всё сам под себя.
justmara
Вдогонку про "интеграцию" с JIRA, сегодняшнее :) уж очень умилило.
это, если что, 12 коммитов, к каждому был указан ID задачи. собрать и сгруппировать — не судьба, видимо.
(да, мне лень заводить тикет по продукту, который мне уже не интересен, поэтому картинка тут, а не на gitlab.com)
VolCh
Нет (или не нашёл) возможности создавать вложенные задачи хотя бы на одном уровне. Нет (или не нашёл) возможности настраивать воркфлоу задачи, как-то отслеживать прогресс её исполнения.
Не, можно, конечно, в дескрипшене создать список подзадач и отмечать там их исполнение, и метками манипулировать, отмечая статус задачи, но не удобно, а потому никто этим не занимается.
nem
Да, обычно в описании просто создается список задач: https://gitlab.com/gitlab-org/gitlab-ce/issues/14838
Мне нравится идея для задач, где в описании есть такие списки, показывать процент выполненного на основе проставленных галочек. Запилю feature request, если этого еще нет в планах.
А какие у вас статусы у задач и для чего вы их используете? Интересно какой у вас процесс разработки.
VolCh
Да, приходится так эмулировать отсутствующую функциональность, но:
— связь просто на уровень встречных гиперссылок, создаваемых вручную. То есть создаёшь одну задачу, потом вторую, а потом проставляешь в них ссылки друг на друга. Никакой поддержки со стороны системы нет. И неудобно, и можно просто забыть, и ошибиться.
— в общем списке задачи всё равно вываливаются на одном уровне, что не позволяет хотя бы приблизительно оценить количество глобальных задач в работе
— нет оценки требуемого времени, дью дейт — не совсем-то, особенно для вложенных задач. Не у всех процесс разработки привязан к дедлайнам или вехам, есть ASAP. Часто ситуация, когда разработчик даёт оценку нужного ему времени, задаче назначают приоритет (в идеале точечно), когда более приоритетные задачи кончаются, разработчик приступает к задаче, если вдруг приходит более приоритетная, то он текущую откладывает, фиксируя (в идеале полуавтоматом) уже потраченное время, а потом возвращается. Так же автоматом фиксирует время при закрытии. Ну и если видит, что задача оказалась сложнее, то корректирует эстимейт (как вариант просит менеджера это сделать).
Глобальных статусов немного:
— new
— research
— development
— testing
— acceptance
— closed
но на почти каждый хотелось бы подстатусы:
todo
in progress
suspend
rejected
aionin
Первый список статусов вполне узнаваем. Но не задач, а требований или user-story, кому как нравится.
Второй список статусов часто встречается для описания процесса (workflow) управления задачами.
Для управления большим количеством задач и исполнителей важна иерархия задач. Для управления разработкой нескольких продуктов множеством команд аналитиков, разработчиков, тестировщиков одними задачами не обойтись — нужны типы объектов управления со своей иерархией и своим workflow. Для этого и нужны отдельные продукты Jira, RedMine, SBM.
Реализация таких сложных сущностей и отношений в GitLab может получиться слишком громоздкой. Где грань?
VolCh
Ну, как по мне, не нужно создавать новые типы объектов, но можно добавить поля и UI к ним для связи существующих issue и/или todo между собой и возможность создавать произвольные статусы а не только open/closed todo/done
Проще говоря, не нужно создавать систему управления проектов, но неплохо бы создать нормальный, а не легковесный треккер задач.
Distress
Да, поэтому приходится прикручивать redmine. Очень хочется что бы когда-нибудь появилась возможность разбивать на подзадачи.
reactoranime
Но ведь в travis также все делается через yml файл настроек, в гитлабе очень грамотно сделана поддержка билдов на докере — можно все запустить локально, а сам файл yml оставить на уровне команд для запуска.
Dreef
В Jenkins 2 тоже добавили Jenkinsfile
nem
Привет, я из ГитЛаба, если что. Я правильно понял что при всех этих недостатках вы таки пользуетесь ГитЛабом?
Буду рад, если получится помочь. По-порядку:
Тяжеловесность — известная проблема. Знаем про нее и активно работаем над этим
Поиск. У вас GitLab CE? С MySQL или PostgreSQL? Было бы здорово услышать конкретный сценарий использования — что где пытались найти и не получилось — тогда смогу донести фидбэк до команды.
Навигация. Редизайн — это всегда больно бля пользователя, увы. Но на привыкание уходит не так много времени, как кажется поначалу. Причина редизайна — поскольку функционала у ГитЛаба много, боковая панель была перегружена. И хоть к ней все к такой привыкли, для тех кто впервые видел ГитЛаб это было тяжело.
Нотификации. Будет круто, если кинете в меня ссылкой на устаревшую документацию — смогу отследить чтобы ее проапдэйтили.
SlavikF
Ну в первую очередь — спасибо за Гитлаб. При всех недостатках — да, это лучшее, что я вижу по совокупности функциональности.
У меня стоит Gitlab CE
*Нотификации*:
— Я хочу открыть регистрацию, чтоб люди могли приходить и писать feature requests. Но боюсь спама. Поэтому я хотел, чтобы мне приходили нотификации, когда создаётся новый пользователь. И вот тут
http://docs.gitlab.com/ce/workflow/notifications.html
написано, что вроде бы есть такой `event`: «New user created»
Но найти это у себя в Гитлабе я при всём старании не смог.
magic4x
Верните старую менюшку, пожалуйста!
nem
Так, чота отвык я от Хабра. Сейчас буду разбираться как тут все работает заново
SlavikF
Кстати, не подскажете, какой общий подход к тому, чтобы CI настроить так, чтобы job могла деплоиться в одну из нескольких ENVs по выбору?
Вот сейчас у меня Jenkins, и я сделал там LISTBOX, из которого я выбираю DEV, STAGING,… и запускаю job. А в Гитлабе накиких LISTBOX добавлять вроде бы нельзя. Получается, что перед каждый запуском надо редактировать job variables? Или есть какой-то более прямой путь?