Pull to refresh

Comments 14

Где-то с год назад смотрел на нее. Парни очень навязывали вместе с CI еще и деплоилку и механику деплоя через свою тулзу — BOSH.
На сколько далеко они продвинулись в отвязывании от неё?

да, я тоже несколько раз смотрел на этот BOSH, но так и не понял, зачем он мне нужен. Так его и не попробовал ни разу. Отвечая на вопрос: у меня он нигде не используется, так что особо к нему я не привязан.

BOSH не нужен вообще, можно без него.

Прочитал статью. Вроде бы всё неплохо. Но так и не понял — в чём основная фишка этой системы?

То есть вот у нас уже есть Jenkins, GitlabCI. Что такого есть у Concourse CI, что мне стоит перейти на него? Таски? Как-то не тянет на киллер-фичу… Тем более, что в Gitlab есть stages, — по моему вполне аналог таскам.
Хороший вопрос, попробую ответить. Я тоже какое-то время пользовался одновременно и GitlabCI, и ConcourseCI и могу их более-менее сравнить. У GitlabCI есть особенность: он берёт исходники только из Gitlab. Это одновременно и хорошо и плохо. Если вы храните код в Gitlab, то наверно у вас особо выбора нету: при всей моей любви к конкоурзу, я вынужден признать что связка Gitlab + GitlabCI просто идеальна — очень легко использовать, у каждого коммита появляется красивая галочка, интеграция из-коробки и сам GitlabCI покрывает 90% ваших потребностей. А что если код хранится где-то в другом месте, скажем, Gogs или приватный Github? Тогда вам стоит рассмотреть другие варианты. Я бы описал конкоурз как «взять ресурсы откуда угодно, собрать как угодно и закинуть куда угодно». К тому же та гранулярность, о которой я описал в последней главе, иногда даёт существенную гибкость, особенно если у вас довольно нетривиальный процесс сборки проекта.
Как-то так.
Киллер фич есть несколько. Одна — что Concourse CI «нативен» для билд-монитора, т.е. его легко вывести на большой экран чтобы видеть текущий статус системы. Для этого не нужны плагины, это круто выглядит и красиво анимировано Вторая — что Concourse всеми силами навязывает модель «повторяемого» билда, например передавать данные между джобами можно только через ресурсы (которые персистентные), а каждый таск работает в одноразовом контейнере. Это не уникально, конечно, можно так же сделать в Дженкинс, но тут все изначально и by design. Например мы недавно полностью переключились с одного инстанса Конкурса на другой просто сменив target. Билд завёлся сразу, без трогания воркеров или АТС. Опять же, так можно где угодно, но Конкурс к этому активно подталкивает.
От себя только добавлю ссылочку на Дашбоард, которая идёт пока в бете, но в ближайшем будущем будет доступна по-умолчанию: ci.concourse.ci/beta/dashboard Её можно как раз вывести на экран телевизора.
В gitlab.CI есть cach. Это позволяет передавать данные между stages, аналог job в Concourse CI. На мой взгляд, это уже стандарт для всех CI систем.
Он есть, только его не рекомендуется использовать иначе, как кэш. Т.е. надо всегда иметь в виду, что кэша может не быть — если джоб запущен на другом воркере и даже в рамках одного воркера.

Нативно интегрированные контейнеры, которые работают без боли дженкинсового docker-in-docker, простой формат описания пайплайнов, интеграция с секретами k8s, возможность для теста запустить пайплайн "с вот этим локальным каталогом". Gitlab CI покрывает многое из этого, но Gitlab огромен и неповоротлив. Менеджер и вебморда Concourse у меня помещается в 200мб ram.

У Jenkins и GitlabCI есть «фатальный недостаток» — они написаны другими людьми ;-)
ИМХО это единственная причина плодить овер дофига CI систем
каждая операция запускается в отдельном Docker-контейнере
Отлично, что система сама из изначально на этом строиться, но если мне нужны собирать на других контейнерах отличных от Docker. А если мой продукт ориентирован под Windows, ведь Docker контейнер сможет запуститься только на Windows 10. Что там с мобильной разработки? Я вижу из-за этого ограничения использования для бизнеса.
В качестве web-разработки, сборки микросервисов и просто для домашнего использования стоит рассмотреть. Лёгкая, быстрая система — этим она выделяется от остальных.

запускается на докере != может собирать только образы для докера

Напоминает проект Drone.io, где также сборка происходит в контейнере. В начале осени присматривался, но отказался, т.к. фронтенд был(все ещё?) приколочен к CDN.

Sign up to leave a comment.

Articles