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

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

Но эта простота может иметь и обратную сторону. В приложении нет готового CI/CD, и для реализации этих механизмов приходится использовать стороннее решение. В нашем случае у клиента эту роль играл Jenkins, для которого существует специальный плагин. Однако данный выбор был скорее историческим наследием, чем технической необходимостью. CI/CD с ним был не очень удобен в работе. Для оптимизации процесса деплоя мы сошлись на переходе на GitLab, а это означало и замену самой Gitea, функции которой теряли смысл. Также в процессе работ были найдены мелкие проблемы, которые мешали миграции.

Интересно узнать подробности о том, почему связка Gitea + внешний CI/CD (тут Jenkins) оказалась настолько неудобной, что решились на замену всего стека.

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

Не только, но преимущественно — да. Потому что так накапливается опыт/инструменты, с которыми создается добавленная стоимость, чтобы оказывать услуги эффективно и качественно (а не просто перепродавать чьи-то часы работы).

ну, как пример, предлагался переезд с куба от провайдера Х на куб у вас как одно из условий предоставления услуг DevOps инженера для поддержки нашей инфраструктуры.

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

У каждого managed-решения своя специфика, которую нужно глубоко знать для обеспечения SLA по работе критичных для бизнеса приложений в нем.

У нас K8s-дистрибутив, который одинаково работает на разных провайдерах (в т.ч. на on-prem bare metal или OpenStack), сертифицированный в CNCF по соответствию базовым API оригинального K8s. Такой подход позволяет пользователю не быть ограниченным одним провайдером, а это огромная изначальная ценность Kubernetes, которую "съели" managed-сервисы крупных провайдеров.

Если же такой подход кажется неподходящим... что ж, это рынок, он рассудит :-)

ну, у вас на сайте в качестве примеров есть "кластер Kubernetes в AWS", но вы всё же настаивали на переезде именно на вашу инфраструктуру с хостинга AWS.
Хотя, может я тогда вас и не дослушал/недопонял и вы предлагали поднять свой "K8s-дистрибутив" на базе AWS, вместо использования их EKS...

Это странно - как будто бы что-то не так было объяснено или понято. Можем разобраться, если это сколь-нибудь актуально (напишите в личку тогда, плз).

Потому что написанное на сайте - правда. У наших клиентов работают кластеры и в разных публичных провайдерах (AWS, GCP, Azure, Яндекс.Облако...), и в частных (OpenStack, vSphere), и на обычном bare metal.

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

Ну тут-то как раз загадки нет. Дешевле поддерживать один универсальный сервис, который объединял бы в себе сразу 3 других: Git storage, CI/CD и Registry. Кроме того Флант имеет богатый опыт поддержки Gitlab, который не ограничивается только CI/CD, но и покрывает другие аспекты: бэкап, обновление и мониторинг.

Отдельные выделенные под конкретную задачу сервисы могут иметь свои преимущества перед комбайном. В статье же вы обошли это стороной, но упомянули, что Gitea в целом представляет собой хорошее решение. Вот и хотелось бы чуть более детального сравнения, а не просто "CI/CD с ним был не очень удобен в работе.".

Максимально пристрастная точка зрения, но, если сразу смотреть с этим пониманием, то все-таки неплохо для старта (потому что довольно подробно) — здесь.

Взгляд с другой стороны — здесь.

Истина где-то посередине и в зависимости потребностей.

Мне кажется, не указали самого главного - сколько это стоило заказчику (денег и времени) и какой экономический эффект от переезда (денег и ускорения процессов).

Заказчику сделали вендор лок за его же деньги.

Vendor lock — это про стоимость ухода с текущего решения на другие. GitLab выглядит куда меньшим vendor lock'ом (чем Gitea) в силу своей куда большей распространенности.

Экосистема Windows Server+dotnet+ASP+MSSQL server была самой популярной в свое время. Была ли она от этого меньшим вендор локом? Нет

Или AWS сегодня. Самое популярное облако в мире. Тут, надеюсь, никто не станет спорить, что этот пример - пример прямо абсолютного вендорлока

Была ли она от этого меньшим вендор локом? Нет

Зависит от того, что и с чем сравнивать. Тут мы сравниваем два Open Source-проекта. Один из которых значительно (ну, уж на порядок — точно) популярнее другого.

P.S. Не думаю, что указанный выше стек был самым популярным. Для меня таковым являлся Linux + Apache. Но не суть…

И ещё важно в данном случае (если уж сравнивать с другими примерами): а) оба этих продукта - self-hosted и б) работают поверх одной и той же Git (а не на разных систем версионирования, что потребовало бы дополнительных манипуляций на уровне самого хранилища).

Хорошо. Давайте сравним.

Gitlab CE, по факту, владеет некая компания, которая целиком и полностью направлеяет развитие проекта. Что она захочет - то и будет, остальным остается только лобзиком сбоку приделывать свои доработки и потом их мигрировать с версии на версию (что, между прочим, существенная работа).

Gitea - community-driven решение. В случае большого конфликта, с примерно равными позициями, можно форкнуть еще раз проект.

Думаете, в этом больше рисков, чем в том, что менее популярное решение не будет достаточно хорошо развиваться (потому что к нему меньше интереса и у пользователей, и у разработчиков, и нет стабильной финансовой поддержки)? Мне так не кажется.

А форкнуть можно и GitLab. Как у решения с гораздо большей аудиторией, скорее всего этим форком заинтересуются больше людей, чем даже условная половина сообщества маленького проекта.

Зависит от того, что и с чем сравнивать. Тут мы сравниваем два Open Source-проекта. Один из которых значительно (ну, уж на порядок — точно) популярнее другого.

Не надо ничего ни с чем сравнивать. Gitea ставится на любой слабый комп с современной ОС, пул настроек минимальный, просто работает и позволяет получить свой собственный маленький github, с пулреквестами, Milestone, WiKi, а также смузи и штаны с подворотами.
GITLab потребует в 5-10 раз больше ресурсов, админа и много чего еще. Вендорлок здесь в том, что теперь для сопровождения нужно больше специалистов и ресурсов. Прощай возможность сделать apt-get и через 10 минут работать, наблюдая как выделение памяти остановилось на 1Гб.
Оправдывают такие расходы будущие доходы — в статье демонстративно этот вопрос обошли стороной. Так что да, сейчас выглядит как «заказчика заставили заплатить за переезд в систему, в которой удобней работать исполнителю».

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

Вычислительные ресурсы в данной конкретной истории совсем не те, чтобы это было значительной разницей.

А до вашего прихода оно же как-то работало? Оно бы и дальше продолжило работать, но тут пришли люди с синдромом not-invented-here, ой, not-supported-here, и как-то умудрились продать весь этот процесс ЛПР.

В "Как-то работало" и "как-то умудрились продать" чувствуется одновременно и противоречие, и разгадка для конкретного случая :-) За услугами не приходят просто так, когда все, что уже есть сейчас, бизнес устраивает... Проблемы были - и в том числе из-за того, что в схеме участвовала не только маленькая и делающая свое дело Gitea, но ее связка с Jenkins. И эта реализация не была достаточно гибкой и прозрачной, приносила и больше непонятного поведения, и сложности в процессе отладки. Но мы писали не об этом, а о пути, который посчитали оптимальным, учитывая многие факторы и в конечном счёте эффективность для бизнеса.

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

У статьи вообще не было умысла продвигать идею миграции с Gitea на GitLab как таковую. Материал для тех, кто такое решение уже принял или имеет свои причины его рассматривать. Для "убеждения" в такой миграции, как я уже писал, надо делать отдельную и совершенно другую статью, потому что раскрывать в ней надо бизнесовые темы (метрики, риски...) и весьма осторожно, т.к. случаи индивидуальны, а критериев - много. Сейчас же складывается впечатление, как будто мы призвали всех делать такую миграцию. Но этого не было и нет.

Если же переходит к теме бизнеса, то он ориентируется на свои показатели (метрики вроде скорости доставки новых версий бизнес-критичного софта) - ему они важны, а не то, какая Open Source-утилита будет под капотом для достижения адекватных значений. Нужен практический результат. Да, конечно, важен ещё фактор упомянутого vendor lock-in, потому что это финансовые риски, но конкретно эту тему уже в комментариях раскрыли достаточно, по-моему; аргументы приведены были, а выводы каждый волен делать сам.

Справедливости ради, админить в гитлабе особо нечего. А вот ресурсы да. Жрет гитлаб непомерно, при этом все равно тормозит.

Сравнивая все подобные показатели, надо ещё помнить, что GitLab пришел на замену не только Gitea, но её связке с Jenkins.

Так что да, сейчас выглядит как «заказчика заставили заплатить за переезд в систему, в которой удобней работать исполнителю».

Не увидел этого примечания вчера. Как уже написал в комментарии выше, заказчик платит за то, чтобы получать результат для бизнеса, а инструменты для него вторичны. Если заказчик принципиально требует использования какой-то конкретной системы (а ее использование все же сопряжено с проблемами), на то должны быть весомые причины*, надо их отдельно обсуждать и приходить к компромиссу. А если нет компромисса, то искать другого исполнителя, и всем будет хорошо.

* В данном случае их не было. Здесь в комментариях они тоже по сути свелись к "работает - не трогай" без знания всей ситуации. А в плане более простой поддержки того, что было, дополни свои ответы напоминанием, что речь шла не про одну Gitea, а про Gitea+Jenkins.

Это самое главное для бизнеса, но статья была от инженера для инженеров — о технике этого процесса, чтобы помочь тем, кому это предстоит (по их причинам). Бизнесовая тема тоже интересна, но скорее для отдельных публикаций (потому что для чуть другой аудитории).

почему вы считаете, что инженерам не надо задумываться об экономической составляющей предлагаемых решений? Вполне резонно спросить о целесообразности переезда и небольшой "революции", чтобы это не выглядело как...

Вы потратили вагон с тележкой времени и ресурсов на миграцию не просто "по фану" же? И не ради одного аргумента "нам так проще обслуживать, так как для нас это шаблонная работа будет"

Обсуждение статьи ушло не в том русле, для которого она была написана. Краткий ответ на ваш вопрос есть здесь, и там же объяснено, почему для более подробного ответа нужно было бы писать другой материал.

Ну и как сейчас поживает GitLab? Зачем было наступать на грабли, если автор сей поделки был завзятый русофоб? И почему не рассматривался GitHub?

Давайте отбросим политику.

Github не рассматривался потому, что требовалось on-prem решение, а для Gitlab в Флант есть отлаженные workflow.

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