В целом, похоже на правду. Не сказал бы полноценный скриптинг и разветвленная система пайплайнов против проложенных кем-то за вас рельсов это не переусложнение, все зависит от человека. Если человек подавил падение, возможно, он знает, что делает. Про ручное действие в GitLab я, к сожалению, не помню, в чем там затык — возможно, с правами и возможностью запустить джобу из старого/любого пайплайна и сломать все еще сильнее.
Все-таки, Gitlab на текущей стадии развития это CI, хоть и довольно неплохой. Он способен работать в качестве CD в несложной среде, к нему можно прикрутить много чего, если вы готовы мириться с его особым путем развития (большинство нужных нам фич было в состоянии полумертвых тикетов 2+ годичной давности, но так будет не у всех).
> А что умеет Jenkins, чего не умеет Gitlab CI?
В первую очередь, он умеет логику и скриптинг не только на уровне одного шага. Пайплайны там это не нагромождение изолированных джобов, а фактически один скрипт, в котором могут быть свои переменные, которые будут переданы дальше. Можно написать библиотеку с базовыми шагами на Groovy и подключать ее в разных деплоях, сведя количество копипаста/поддерживаемого кода к минимуму. Можно вызывать другие пайплайны с определенными параметрами, получать результат их выполнения и реагировать не только одним доступным способом (упасть).
Есть ручное подтверждение — деплой стоит на паузе, пока не пройдут какие-то важные ручные тесты. Есть и тонкий контроль доступа (с плагином), можно вообще вынести пайплайны в другой репозиторий, и никто их не сможет поправить.
Да много чего есть, всего и не упомнишь, главное это не бояться плагинов и Groovy, они там сделаны нормально. Скажем так, после Jenkins чтение развесистого .gitlab-ci.yml с элементами CD обычно вызывает саркастический смех.
У всех, конечно, свои минусы, но если приручить JCasC и контейнеризировать все этапы, требующие какого-то окружения, Jenkins становится не так страшен.
> как обычно делают тестовые стэнды?
Вряд ли скажу какой-то best practice, ибо тут все зависит от принятых в компании процессов. У нас вот dev от qa/staging отделен из соображений безопасности и быстродействия. Но в целом с изоляцией Kubernetes (namespaces, resources) можно делать тестовые стенды в каком угодно количестве в рамках одного и того же кластера, если это вписывается в концепцию безопасности.
> И как Jenkins «решает» на какой стэнд накатывать какой BRANCH?
Multibranch Pipeline (плагин). Скриптинг на Groovy и доступная переменная с названием бранча.
> CD-компонент
CI в GitLab, в принципе, неплох, но вот CD… Его там практически нет. Есть интеграция с целым одним (в бесплатной версии) прибитым гвоздями кластером Kubernetes и безграничные возможности Bash-скриптинга. По сравнению с Jenkins это по сути является крайне ограниченным велосипедом без колес и руля.
Интересная трактовка конституции, свобода передвижения не гарантирует бесплатности и бесконтрольности (в плане аутентификации и авторизации) оного. Когда под вашим именем в поезд сядет кто-то другой, а вас отправят куда подальше, думаю, мнение по данному вопросу резко изменится :)
Не нужно вводить людей в заблуждение на волне хайпа: единственный более-менее безопасный SOCKS-сервер это тот, где аутентификация осуществляется через GSSAPI (при этом соединение шифруется). При использовании любого другого метода логин и пароль передаются плейнтекстом в открытом виде без единого намека на шифрование, а проксируемые соединения также никак не шифруются.
Так а никто и не говорит про всю функциональность. Автор внятно написал только, что ему «неудобно»/«непонятно»/«задачи обсуждаются в X, а ставятся в Y», после чего пошел костылизировать свое видение Slack+%TASK_MANAGER% в форме бота для Telegram. В принципе, его право, но аргументация вялая и весьма странная, особенно, если учесть количество телодвижений, совершаемых при работе с «тикетом» через бота, явно избыточных в сравнении с обычным таск-менеджером.
Кастомизация workflow (читай: настройка рабочего инструмента) это, по-вашему, «дурная работа»? Потыкать мышкой в GUI теперь сложнее написания готового продукта с нуля, серьезно? Это примерно как пойти писать свой desktop environment на каком-нибудь javascript, если на купленном ПК не обнаружится предустановленных привычных вам нескучных обоев на рабочем столе. Вы же явно не ожидаете, что весь софт будет идеально настроен именно под вас из коробки, не придумывайте глупости.
По-моему, если человек неспособен разобраться в крайне популярных (и неспроста) jira/redmine/youtrack хотя бы на уровне воркфлоу «создать-решить/отфутболить-закрыть», ему нечего делать в разработке, где все на несколько порядков сложнее.
P. S. Пользуйтесь спеллчеком, пожалуйста.
P. P. S. Когда уже пройдет этот хайп с различными ботами, которых пытаются насильно скрещивать со всем подряд?
Что такое «оптимизация у HLS» и насколько она хреновая, в чем измеряется хреновость? Без конкретики это все болтология на уровне «я слышал, игрушка XXX тормозит». Далее, при нормальной логике плеера задержка составляет длину сегмента, которая обычно выставляется в 5-10 секунд, но можно ведь поставить и поменьше. Это не PS4 Remote Play и не Steam Link, задержка всегда есть и будет, а на чемпионатах она еще и настраивается на несколько минут по очевидным причинам.
А на реддите в указанной теме годичной давности не ищется ни одна из указанных проблем. Более того, кто-то даже пишет, что с HLS его ноутбуку становится лучше :) Да и по личным наблюдениям на Youtube все начинает воспроизводиться гораздо быстрее и с меньшими ресурсозатратами, особенно, если заходить под Linux.
Просто кто-то делает (google), а у кого-то всегда находятся причины не делать, деньги же и без этого идут.
Какие это там технологии непригодны для стриминга? Сущий бред, технологии что со стороны стримера (взять аудио+видео, маленько пожать и отправить), что для конечного пользователя (HLS) абсолютно идентична. При этом длина и «живость» трансляции никакой роли вообще не играет: многие ТВ-сервисы именно в этом виде отдают как прямой эфир, так и архив своим пользователям, ибо он кроссплатформенный и понимается огромным количеством устройств и плееров.
Кстати, вот вам сюрприз: и на youtube, и на твитче используется HLS. Твитч просто (пока еще?) не осилил полный переход.
Все-таки, Gitlab на текущей стадии развития это CI, хоть и довольно неплохой. Он способен работать в качестве CD в несложной среде, к нему можно прикрутить много чего, если вы готовы мириться с его особым путем развития (большинство нужных нам фич было в состоянии полумертвых тикетов 2+ годичной давности, но так будет не у всех).
В первую очередь, он умеет логику и скриптинг не только на уровне одного шага. Пайплайны там это не нагромождение изолированных джобов, а фактически один скрипт, в котором могут быть свои переменные, которые будут переданы дальше. Можно написать библиотеку с базовыми шагами на Groovy и подключать ее в разных деплоях, сведя количество копипаста/поддерживаемого кода к минимуму. Можно вызывать другие пайплайны с определенными параметрами, получать результат их выполнения и реагировать не только одним доступным способом (упасть).
Есть ручное подтверждение — деплой стоит на паузе, пока не пройдут какие-то важные ручные тесты. Есть и тонкий контроль доступа (с плагином), можно вообще вынести пайплайны в другой репозиторий, и никто их не сможет поправить.
Да много чего есть, всего и не упомнишь, главное это не бояться плагинов и Groovy, они там сделаны нормально. Скажем так, после Jenkins чтение развесистого .gitlab-ci.yml с элементами CD обычно вызывает саркастический смех.
У всех, конечно, свои минусы, но если приручить JCasC и контейнеризировать все этапы, требующие какого-то окружения, Jenkins становится не так страшен.
> как обычно делают тестовые стэнды?
Вряд ли скажу какой-то best practice, ибо тут все зависит от принятых в компании процессов. У нас вот dev от qa/staging отделен из соображений безопасности и быстродействия. Но в целом с изоляцией Kubernetes (namespaces, resources) можно делать тестовые стенды в каком угодно количестве в рамках одного и того же кластера, если это вписывается в концепцию безопасности.
> И как Jenkins «решает» на какой стэнд накатывать какой BRANCH?
Multibranch Pipeline (плагин). Скриптинг на Groovy и доступная переменная с названием бранча.
CI в GitLab, в принципе, неплох, но вот CD… Его там практически нет. Есть интеграция с целым одним (в бесплатной версии) прибитым гвоздями кластером Kubernetes и безграничные возможности Bash-скриптинга. По сравнению с Jenkins это по сути является крайне ограниченным велосипедом без колес и руля.
Для спутникового интернета обычно используется наземная линия передачи данных от пользователя к провайдеру, емнип.
Очень странно видеть сравнение не со схожей конфигурацией под управлением mdraid, а одним диском под XFS.
Подробнее можно узнать в соответствующих RFC или в документации Dante: www.inet.no/dante/doc/1.4.x/config/auth.html
Жаль, а ведь это самое главное и интересное.
Кастомизация workflow (читай: настройка рабочего инструмента) это, по-вашему, «дурная работа»? Потыкать мышкой в GUI теперь сложнее написания готового продукта с нуля, серьезно? Это примерно как пойти писать свой desktop environment на каком-нибудь javascript, если на купленном ПК не обнаружится предустановленных привычных вам нескучных обоев на рабочем столе. Вы же явно не ожидаете, что весь софт будет идеально настроен именно под вас из коробки, не придумывайте глупости.
P. S. Пользуйтесь спеллчеком, пожалуйста.
P. P. S. Когда уже пройдет этот хайп с различными ботами, которых пытаются насильно скрещивать со всем подряд?
А на реддите в указанной теме годичной давности не ищется ни одна из указанных проблем. Более того, кто-то даже пишет, что с HLS его ноутбуку становится лучше :) Да и по личным наблюдениям на Youtube все начинает воспроизводиться гораздо быстрее и с меньшими ресурсозатратами, особенно, если заходить под Linux.
Просто кто-то делает (google), а у кого-то всегда находятся причины не делать, деньги же и без этого идут.
Кстати, вот вам сюрприз: и на youtube, и на твитче используется HLS. Твитч просто (пока еще?) не осилил полный переход.
P.S. http://gaming.youtube.com/live