Comments 39
Возможно я что-то проглядел, но в гитлабе есть встроенный функционал канбан-доски — Issues -> Boards.
Верно, но там канбан-доски только в контексте проекта или группы, а не всего гитлаба.
Делают уже и для мульти-проектов: https://gitlab.com/gitlab-org/gitlab-foss/issues/53811
И почему бы не сделать режим показа всего, добавив эту опцию в код самого гитлаба?
Я как-то из названия статьи совсем не ожидал, что она будет про собственный велосипед.
Мне видится процесс внесения новым участником изменений в репу гитлаба чересчур долгим и сложным, но могу ошибаться.
Если бы вносить изменения в OpenSource было бы чересчур долго и сложно, то всё движение уже загнулось бы. А мы напротив, вовсю наблюдаем его расцвет.
ОпенСурс очень неравномерный. И у него тоже бывает и человеческий фактор, и стандарты качества, и какой-то план развития. Поэтому в зависимости от проекта пропихнуть нужный фикс или фичу бывает от "просто" до "невозможно"
Да, можно всегда форкнуться, но это ужасно, т.к. придется потом таскать и обновлять свой набор патчей. А это прям… непросто.
Сорри, промахнулся. Ответ на ваш коммент тут: https://habr.com/ru/company/lanit/blog/462855/#comment_20698567
Я бы мог обстоятельно рассказать почему мой велосипед в данном случае лучше и его непременно надо было сделать, но с канбордом всё оказалось просто: когда я понял, что в каждом проекте гитлаба отдельно нужно будет добавлять вебхук, а в канборде auto actions не позволяют прикурить уже существующие в гитлабе задачи, я психанул и забил на канборд :-) В дальнейшем это оказалось правильным решением — синхронизировать из гитлаба потраченное и запланированное на задачи время канборд не умеет, а доска у нас выросла в таймтрекер.
Сорри за оффтоп, не сдержался)))
Передо мной стояла такая же проблема.
И знаете, если создать корневую группу и перенести туда все существующие проекты/группы, то доска по ней покажет все задачи по всем проектам
Ну или так )) Меня эта мысль почему-то не посетила...
Ну или использованием сервисов вроде Jira. Но в нашей команде один разработчик на удалёнке, а гитлаб в закрытом контуре (недоступен из интернетов по соображениям информационной
1. И как Ваше решение вопрос закрытого контура решило?
2. ВПН прокинуть к джире тоже нельзя было реализовать?
- Канбан-доска тоже в закрытом контуре, если точнее, на той же виртуалке, что и гитлаб;
- Это вопрос, касающийся некоторых аспектов взаимодействия с нашей службой информационной безопасности. В целом, могу сказать, что всё очень сложно ;-)
- Но даже если решить этот вопрос, Jira ещё и по деньгам недёшево нам обошлась бы. Разработчиков мало (пока, надеюсь), но вот менеджеров, следящих за тасками, хватает, поэтому standalone-лицензия, боюсь, обошлась бы нам в $2.5к в год, что для небольшой команды как-то дороговато.
— 8 часов рабочего времени;
Круто. Я почему-то уверен, что если заказывать такой функционал на фрилансе, исполнитель зарядил бы цену минимум в 500$ и срок минимум неделя.
4 дня на погружение, обсуждение, тз, согласование, правки. 8 часов на реализацию))
$500 на 40 часов рабочей недели, не так и много
Так-то ничего сложного сделать за день можно наверно… Но покопаться в API gitlaba, покопаться с авторизацией и гитлаба и внутренней, поискать нужную библиотечку для отображения канбана(С учетом того. что обычно дай бог третья подходит, а на каждую по часику нужно), разобраться с ней, пересобачить формат гитлабовских данных в формат библиотеки канбана, потрахаться с css. Обязательно ж какой-нить затык будет, задеплоить это все(особенно, когда чувак описал сложности с безопасностью). Если все гладко проскочит, то легко но ведь так не бывает((
Но в нашей команде один разработчик на удалёнке, а гитлаб в закрытом контуре (недоступен из интернетов по соображениям информационной безопасности), поэтому выбирать пришлось наиболее простое из двух возможных решений:
Vpn не? Иначе как он работает? Перегибы в ИБ ведут к глупостям. Что разработка ненужных штук, что создание странных кадавров для обхода ИБ (типа туннель через туннель через https)
создание механической руки и контроллера к ней, который позволит удалённо переклеивать стикеры на доске, при этом, чтобы не усложнять решение, писать на стикерах нам придётся за нашего недосягаемого коллегу, что несправедливо;
Шутка зашла
… что его команде нужна канбан-доска
Все возможные доски, которые я видел, нужны были именно человеку Р, а не команде.
Часто и к сожалению для скрытия неквалификации в области менеджмента проектов.
Все талантливые Р, которых я видел у таких досок, использовали её именно как возможность лично обсудить и понять возникающие сложности.
А в целом, простой компонент получился, решающий свою задачу.
Вы правы. Линейному разработчику в команде просто нужен пул задач, а как они распределяются между участниками — не его головная боль. Поэтому доска нужна, в первую очередь, организатору разработки. Есть различные техники вовлечь разработчиков в игру с доской, но сути это не меняет.
И да, физическая доска с бумажными стикерами, конечно, приятнее.
Наш гитлаб в закрытом контуре, из интернета недоступен, интегрировать с внешними сервисами невозможно.
Ну, как бы есть разница между "наш гитлаб из интернета недоступен" и "наш гитлаб из интернета недоступен, но при этом свободно может ходить в интернет". Прошу прощения за уточнение. Мы, например, столкнулись с тем, что куча функционала — то же сканирование образов, docker executor etc. без плясок с бубнами БЕЗ доступа в интернет (хотя бы на скачивание) не заводится. Это реально очень интересная тема — как в нынешних условиях в закрытом контуре запускать такие штуки, так чтобы было безопасно и не очень больно.
наш гитлаб из интернета недоступен, но при этом свободно может ходить в интернет
И ходить не может, контур же закрытый. Даже обновить гитлаб — отдельная песня с согласованием и регламентированием работ.
Впрочем, даже если бы гитлаб мог триггерить веб-хуки у трелло, опять же возникает проблема с тем, что данные о задачах будут храниться у третьего лица — у нас это грех посильнее доступа в интернет ))
Тема действительно интересная, вы верно заметили.
«У тебя в команде не понятно, кто чем занимается.»
То:
1) Чем занимается тимлид? Почему он базовые свои обязанности не выполняет?
2) За такие велосипедные велосипеды для решения базовой задачи я бы тимлида разжаловал в рядовые, ведь видно, что кодить ему нравится больше, чем управлять, а основная задача у тимлида — управлять командой.
Это пророческий коммент! Потому что, ~ полтора месяца назад, осознав, что кодить мне во сто крат интереснее, чем тимлидить, я инициировал процедуру самоотвода с этой должности. Вопрос о том, куда расти сеньору и что тимлидство далеко не для всех, а так же где найти тимлида вместо себя, если исторически был первым разрабом в компании и создал группу разработки — само по себе отдельная тема для обстоятельной заметки, которую я обязательно напишу.
Это пророческий коммент!
Это опыт, дружище, глаз наметан на такие ситуации )
Вопрос о том, куда расти сеньору
Выбор есть, вопрос в том, какие возможности предоставляет Вам текущее место работы:
1) Technical Lead — главный по технологиям в команде. Кодить нужно много, но нужен широкий кругозор для выбора технологий и педантичность в их отборе.
2) Architect — главный по архитектуре, но тут кодить нужно сильно меньше.
3) Остаться в сеньорах и кодить в удовольствие. Так же можно замещать тимлида по каким-то вопросам или полностью в его временное отсутствие(отпуск).
4) DevOps. Тут открывается непочатый край интеграций с сервисами и тонкого тюнинга.
Лёгкое программирование: канбан-доска для GitLab за один рабочий день