CI/CD - zuul против Jenkins в приложениях Java EE [закрыто]
Я ищу подробный ответ на эти два вопроса, чтобы сравнить Zuul и Jenkins. Если ваша компания собирается разработать новое приложение Java EE, то какие из этих инструментов (Zuul,Jenkins) вы бы порекомендовали? Почему?
Если ваша компания хочет внедрить практику CI/CD для существующего приложения Java EE, то какой из этих инструментов (Zuul,Jenkins) вы бы порекомендовали? Почему?
1 ответ
Это не правильный тип вопроса для ТАК вопроса ... НО я вас посмею ...
Если бы я начинал компанию и хотел выбирать между двумя, я бы выбрал Дженкинса. Почему? Широко поддерживаемый / документированный, проверенный в боях, гибкий, он используется разработчиками всех способностей, и большинство людей использовали CI / CD раньше, поэтому даже если разработчики не имеют опыта конкретно в Jenkins, они, по крайней мере, использовали что-то еще - GoCD, Bamboo, TeamCity и т. Д. Так что нанять кого-то с нужным / соответствующим опытом не составит труда.
Для приложения Jenkins как конвейер CI / CD предназначен именно для этой цели. Его открытый исходный код. Это бесплатно.
Zuul, который (на первый взгляд) выглядит как служба типа API Gateway / прокси (похожая на программное обеспечение типа Google Apigee, Kong, Nginx).
Zuul не нацелен на CI / CD таким же образом. Это технология, открывающая доступ к вашим приложениям более широкой аудитории ... включая маршрутизацию, безопасность (авторизацию / аутентификацию - OAuth), балансировку нагрузки и т. Д. Так что, по крайней мере, для меня это не кажется подходящим инструментом для работы.
Благодаря конвейерам Jenkins вы можете делать все, что хотите в процессе сборки / развертывания - добавлять / удалять шаги (запускать модульные тесты, запускать интеграционные тесты, запускать статический анализ, пакетировать приложения, развертывать приложения), уведомлять людей о чаты (для наглядности), электронное письмо коммиттеру / команде, когда шаг не удался и т. д.
Для CI / CD Jenkins.