Через год все составные части доставляются в главный сборочный цех, и выясняется, что двигатель не входит в корпус, а сопла начинают плавиться даже при тестовых запусках двигателя.
Чтобы такой фигни не случалось, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются спецификации того как части будут взаимодействовать между собой и какими характеристиками ни должны обладать.
При разработке ПО мы не можем себе позволить долгий этап проектирования, т.к. за это время потеряется бизнес-ценность того что мы пытаемся разработать — нас тупо обойдут конкуренты.
Поэтому команды, разрабатывающие составные части программы(модули) зачастую вынуждены работать не до конца понимая как их модуль будет взаимодействовать с остальными частями.
Как и в случае с ракетой, при попытке выпустить новый релиз приложения, разрабатываемого по частям несколькими командами, может выясниться что какие-то из модулей не совместимы.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Действительно, компилировать программу проще, чем собирать ракету (особенно из недоделанных компонентов), так почему бы не начать это делать раз в день? В Экстремальном Программировании решили эту тему усугубить, и устраивать сборку несколько раз в день.
Что такое сборка?
Ну, например, нужно скопировать модули в одно место и запустить компиляцию программы.
Если все получилось, то сборку можно считать успешной, если нет — то у команды появляется повод разобраться подетальнее, и решить проблему пока все не зашло слишком далеко.
В интерпретируемых языках типа PHP, Python и Ruby компилировать нечего. В них сборкой может являться запуск юнит-тестов, деплой веб-приложения на тестовый сервер, и прогон acceptance-тестов на этом тестовом сервере.
Итого, Continuous Integration — это практика. Назначение практики — уменьшить количество интеграционных факапов, повысить качество выпускаемого софта. Способ — запуск сборки проекта несколько раз в день.
Допускаю что Гради Буч в стародавние времена начинал практиковать CI вообще вручную, бегая по отделам своей компании, и заставляя всех давать ему дискеты с последними версиями модулей, а потом с языком наперевес все это вручную компилировал :)
Нам в нашем 2018 уже чуть попроще — процесс CI автоматизирован в куче систем — выбирай любую на свой вкус:
Про CI-системы
Их довольно много. Они разные. Есть специализированные под конкретный язык программирования. Есть заточенные под разработку мобильных приложений, есть встроенные в IDE, есть с настройкой через GUI, есть с настройкой через конфигурационный файл в репозитории. Часть работает только в облаке, некоторые можно устанавливать на свои сервера.
Мы не будем сейчас пытаться охватить их все. Возьмем только современные системы общего назначения, представляющие из себя веб-приложения.
Современная разработка подразумевает что вы используете Version Control систему.
Version Control — это почти всегда git.
Git — это почти всегда GitHub или аналогичный сервис.
Best practice современной разработки — фичебранчи и пулреквесты.
CI как раз отлично вписался в историю с пулреквестами.
Вы не только видите все изменения, обсуждаете разработку конкретной фичи в одном месте, у вас тут же показывается статус соответствующей CI-сборки:
(здесь сборка провалилась — надо идти в Details, выяснять что где поломалось и чинить)
Починили, закоммитили, запушили, и процесс начинается по новой — CI-система детектит новые изменения на ветке и запускает новую сборку:
Сборка может состоять из нескольких этапов. Самые типичные — тесты, компиляция, деплой.
Естественно, CI-системе нужно объяснить что из себя представляют эти этапы.
Настройка CI-систем
Все правильные CI-системы исповедуют принцип configuration as code, когда инструкции для CI-системы — это просто еще один файл в репозитории вашего проекта. Как то так сложилось, что в большинстве систем для инструкций используется формат YAML.
Простейший файл с инструкциями для GitLab CI может выглядеть так:
test_job:
script:
- ls -l
Чуть более сложные инструкции (Circle СI):
version: 2
jobs:
test:
docker:
- image: circleci/ruby:2.4-node
steps:
- checkout
- run: rspec
deploy:
docker:
- image: circleci/ruby:2.4-node
steps:
- checkout
- run: cap deploy
И тут мы вспоминаем что все эти инструкции должны где-то запускаться.
Что у CI-систем под капотом
На каждый пуш в репозиторий CI-система создает виртуальную машину, внутри которой запускает ваши инструкции, забирает результаты работы, и гасит машину:
Чистая система каждый раз нужна для того чтобы ограничить влияние внешних факторов на сборку.
Некоторые CI-системы используют для этого докер, некоторые выкручиваются без него. Хинт: берите ту, что с докером ;)
(в реальности все несколько сложнее, и большинство CI-систем умеют работать в куче разных режимов, но начинать лучше с дефолтного режима — простого запуска задач внутри докер-контейнера)
Зачем это всё обычному разработчику?
- Чем больше аспектов разработки ты способен закрыть, тем больше твоя ценность. Если ты просто написал код, запушил, а дальше хоть трава не расти — это одно. Если ты при этом позаботился о тестах и о деплое приложения — совсем другое. Если ты это все автоматизировал в CI — третье :)
- Просто поймите, что через время CI будет такой же дефолтной штукой как и Version Control.
Приведу вам пару ситуаций из практики. Вполне возможно что вы в какой-то из ни побывали:
Ситуация №1
Два разработчика разрабатывают на разных ветках. У каждого из них тесты проходят успешно, в том числе и после мержа c мастером.
Но как только обе ветки вмержены в мастер, тесты начинают падать. Проблема в том что без CI такой код запросто может уйти в продакшн, и наличие ошибки выяснится уже только там.
Сиуация №2
Команда из пятнадцати человек разрабатывает веб-приложение. У Василия на носу семейный праздник. Он отпросился у начальства уйти пораньше, не очень тщательно проверив работоспособность кода, запустил в командной строке деплой, и ушел с работы, залочив компьютер, и заодно отключив телефон — семья же важнее работы!
В результате продакшн поломан, логи деплоя остались на залоченном компе, оставшиеся разработчики рвут на себе волосы в попытках понять что же было задеплоено, и что пошло не так в процессе деплоя, и кто вообще виноват.
Если в команде используется CI-система, то все логи деплоя (и любых других задач) сохраняются в ней, так что всегда можно посмотреть что пошло не так.
С какой CI-системы начинать
Неплохую подсказку нам дает Гитхаб:
Open source проект на GitHub скорее всего гоняет тесты в Travis CI. Вы не сможете с этим не столкнуться. Ок, берем Travis CI на заметку, но гуглить и обчитываться мануалами пока не бежим.
Давайте еще посмотрим на выводы недавнего исследования The Forrester Wave про Continuous Integration Tools:
Если в двух словах, то исследовались текущие возможности CI-системы, потенциал для развития, и текущий размер рынка.
Кому интересна методология тестирования, читайте само исследование. Нам же интересны выводы.
В лидерах оказались:
4) CloudBees — это компания стоящая за Jenkins. Это одна из старейших CI-систем c открытым исходным кодом, и было бы странно не увидеть их в лидерах.
3) Circle CI уже во втором источнике оказался в лидерах. Значит тоже заслуживает внимания.
2) Microsoft — no comments. Огромная компания с огромным влиянием. Если вы разрабатываете софт под винду, то скорее всего у вас даже не будет стоять вопрос выбора. Если в компании куплены лицензии на майкрософтовский стек разработческих инструментов с TFS и их CI-системой, вы просто будете есть что дают, не особо смотря по сторонам
1) GitLab на первом месте. Для тех кто не следит за компанией последние несколько лет, это может оказаться полным сюрпризом. Поговорим про него поподробнее.
GitLab
Автор год работал в Гитлабе на позиции Developer Advocate, так что вы имеете полное право считать меня предвзятым и выкрутить регулятор скептичности на пару десятков процентов при прочтении следующих абзацев. Тем не менее считаю, что многие вещи про Гитлаб надо знать, а еще лучше — начинать им пользоваться.
Важно что Гитлаб отказался считать себя просто клоном Гитхаба, и в компании решили развивать Гитлаб в сторону “системы одного окна” для разработчика. Гитлаб уже сейчас способен заместить вам Гитхаб, Трелло, CI-систему, и так далее по списку. Все инструменты уже настроены и интегрированы между собой. Результат для разработчика — минимум возни с настройками.
Исходный код Гитлаба открыт, и его при желании можно бесплатно использовать на собственном сервере. Но нас в этой истории сейчас больше всего интересует облачная версия — GitLab.com и возможности которые она дает:
- Хостинг неограниченного количества приватных проектов
- 2000 билд-минут в месяц для работы с встроенным CI бесплатно
Халява, ага. Ну и возможность поучиться, используя для личных проектов, как следствие.
Короче, вы уже догадались что моя личная рекомендация — это GitLab CI. Гитлаб имеет все шансы стать the next big thing в будущем. А быть опытным специалистом по внезапно ставшей модной штуке — это быть востребованным специалистом ;)
Если не готовы покидать Гитхаб, пробуйте Circle CI или Travis CI.
На начальных стадиях знакомства с CI избегайте Jenkins и TeamCity. В этих олдскульных системах слишком много оверхеда, так что придется больше разбираться с особенностями систем, чем фигачить сам CI.
Начнете думать что Jenkins это и есть CI, а это тупо. Возможное исключение — вы джавист, скалист или котлинист, и для вас там все работает прямо из коробки.
Если вам на роду написано программировать под Windows, то мимо Microsoft-стека вы мимо точно не пройдете, но по доброй воле я бы им пользоваться не стал.
Ок, едем дальше…
C каких задач начинать
Хорошие новости в том что не обязательно сразу становиться экспертом по CI. Для начала хватит и простого “быть в теме”. Поэтому начните с чего нибудь лайтового:
- Например, научитесь деплоить личный сайт при пуше в мастер.
- Впилите проверку орфографии с помощью yaspeller для текстов на личном сайте
- Запустите в CI второстепенного рабочего проекта пару линтеров.
Запустить свой первый билд внутри CI — задача двух минут. Чтобы запустить что-то полезное, придется потратить чуть больше времени, т.к. нужно настроить рабочее окружение для ваших скриптов.
Здесь мы в это углубляться не будем. Для заинтересовавшихся — ссылки в конце статьи.
А пока посмотрим как CI используется в больших проектах, и какую мощь он может вам дать.
Что дает CI в больших проектах
В больших проектах — серьезные требования. Тут уже запуском одной-двух команд не обойдешься. Легко можно представить себе логику типа такой: 1) выполняй задачу, только при коммите в определенные ветки, 2) при успехе выполняй следующие задачи, 3) игнорируй ошибки при выполнении определённых задачи и 4) жди ручной отмашки прежде чем задеплоить всё это дело.
Мой любимый пример — сам GitLab:
Там всегда кипит работа, и можно посмотреть как работает CI прямо в режиме реального времени: https://gitlab.com/gitlab-org/gitlab-ce/pipelines
Это большой проект, и его CI-конфиг я бы не рекомендовал смотреть без предварительной подготовки.
Вместо этого лучше посмотрите на визуализацию цепочки CI-задач:
https://gitlab.com/gitlab-org/gitlab-ce/pipelines/20201164
1) Такое есть далеко не во всех CI-системах. Там где это есть — это дает команде визуальное представление происходящего в CI, и я считаю это дорогого стоит.
2) Кроме этого, файл настроек CI-системы становится работающей документацией процесса Continuous Integration в команде. Любой разработчик может там что-то добавить или изменить, создав пулреквест с желаемыми изменениями.
3) Наконец, CI-система становится центральным местом, в котором можно увидеть где и когда что пошло не так при деплое или прогоне тестов.
Ну и добавьте по вкусу все эти традиционные бла-бла-бла про ускорение процесса разработки, повышение надежности, и уменьшение рисков.
Куда копать дальше
(если захотелось изучить поглубже)
1) Посмотрите скринкаст с примерами как нарулить деплой на S3 и на Heroku с помощью GitLab CI.
2) Прочитайте введение в GitLab CI и руководство по деплою.
3) Покурите документацию.
4) После того как освоитесь с одной CI-системой, выберите и поиграйтесь с любой другой из списка перспективных, чтобы удостовериться что принципе везде общие, и заполучить еще больше уверенности в своих силах.
Комментарии (49)
mayorovp
10.04.2018 15:17На каждый пуш в репозиторий CI-система создает виртуальную машину, внутри которой запускает ваши инструкции, забирает результаты работы, и гасит машину
Не надо обобщать конкретные реализации до общего правила. В мире полно CI-систем, которые не используют никаких виртуальных машин или контейнеров.
mayorovp
10.04.2018 15:49Пожалуй, раскрою мысль.
Главная задача CI-системы — она должна уметь построить проект от и до. Любой проект. В том числе проект, в котором на этапе сборки используются сторонние утилиты с графическими инсталяторами просящими серийный номер и ключ. Такие утилиты в контейнер не положить, тут только предварительно вручную готовить виртуалку. Или даже не виртуалку — если утилита детектирует запуск в виртуалке и отказывается там работать из своих DRM-соображений.
Поэтому использование докера для CI-системы — это не фича, а ограничение.
Конечно, если делается новый проект, и есть возможность выбирать CI именно для этого проекта (а не на следующие 10 лет разработки) — то проблем вроде как нет.
nem Автор
10.04.2018 16:19Все верно, спасибо! Но статья вводная, и я позволил себе несколько упростить картину мира. Плюс у меня есть уточнение что мы рассматриваем только "системы общего назначения", без специфики типа тестирования десктопных или мобильных приложений.
mayorovp
10.04.2018 16:26Вот как система общего назначения и не имеет права ограничивать себя докером. А специальная — может.
nem Автор
10.04.2018 19:33Все так. Если говорить за Гитлаб, он как раз не ограничен докером, но дефолтный режим в облачной версии Gitlab.com именно такой.
acmnu
11.04.2018 10:22В мире полно CI-систем, которые не используют никаких виртуальных машин или контейнеров.
Постепенно CI перекатывается в контейнеры почти полностью. Дело в изоляции. Другими методами крайне сложно правильно подготовить окружение и гарантировать повторяемость.
VioletGiraffe
10.04.2018 16:00Запустить свой первый билд внутри CI — задача двух минут
— прочитал я после двух недель возни с настройкой Jenkins (c перерывами, конечно).
Travis CI и почему-то забытый в статье Appveyor — классные системы в том плане, что настройка достаточно простая, всё быстро и просто, много примеров, можно найти, как делать всякую эзотерическую фигню. У Appveyor даже есть вменяемый саппорт. Интеграция с Гитхаб очень удобная. Но для приватных проектов они платные. Для случая, когда хочется сэкономить, не нашёл альтернативы Дженкинсу, плюс у него полный контроль над происходящим, можно настроить свою инфраструктуру как угодно.nem Автор
10.04.2018 16:16Сорян, забыл написать "внутри современной CI". Я ж не зря советую сторониться Jenkins-а. Он травмирует психику молодых разработчиков, и они потом боятся CI как огня.
Appveyor забыт в этой статье как и куча других CI-систем. В статье Гитхаба про популярные CI-системы он оказался на 4-ом месте. В отчет Forrester Wave вообще не вошел, поэтому он не привлек моего внимания.
springimport
10.04.2018 18:37Да вроде нормально он все делает, хоть я и относительно недавно начал вникать в CI. Например, он позволяет иметь главный сервер и сервера-слейвы на которых будет сборка. По моему, удобно.
А что до travis. Все же для pet-проектов с ценами перебор.nem Автор
10.04.2018 19:37позволяет иметь главный сервер и сервера-слейвы
В гитлабе ты просто поднимаешь дополнительные раннеры (а не поднимаешь еще один гитлаб в slave-режиме)
Все же для pet-проектов с ценами перебор.
Да, увы.
ptQa
10.04.2018 16:31+2В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Да нет, прикол вовсе не в том, чтобы собирать каждый день. Прикол в том чтобы мерджить каждый день (даже если ты не доделал фичу, ты мержишь в конце дня). А это намного сложнее.
А настройка билд-сервера это тривиальная задача, которая в принципе не про CI.
Best practice современной разработки — фичебранчи и пулреквесты.
А как же https://trunkbaseddevelopment.com/ ?
nem Автор
10.04.2018 19:39Прикол в том чтобы мерджить каждый день
Да, пожалуй так будет вернее. Я это подразумевал, но не акцентировал на этом внимание. Спасибо.
А как же https://trunkbaseddevelopment.com/
Не встречал раньше этот подход. Спасибо, почитаю.
ptQa
10.04.2018 21:53Да, пожалуй так будет вернее
Не, не, различие тут не "верно"/"вернее". Просто написанное вами в статье неверно.
Я это подразумевал
Сомневаюсь, поскольку дальше вы пишите, что фичебранчи это best practice. Хотя это в принципе противоречит CI подходу. Думаю, что вы просто никогда не читали даже статьи в Википедии с определением CI.
ptQa
10.04.2018 23:56По поводу чем плох feature branch и почему этот подход не совместим с CI можно почитать тут, от одного из авторов термина https://martinfowler.com/bliki/FeatureBranch.html
Falstaff
11.04.2018 01:41Мартин там скорее пишет не про то, что этот подход не совместим с CI, а про то, что при таком подходе от CI получается меньше пользы. Причём сперва он в целом говорит о недостатках обычного feature branch подхода, упирая на ситуацию, при которой двое работают в долгоживущих локальных ветках над одним и тем же кодом, и у одного из них потом возникает большой сломанный merge (что обычно не так страшно). И при этом он взамен предлагает свой promiscuous intergration, когда feature branches часто мёржатся друг между другом — что во-первых не решает проблемы CI (изменения-то всё равно тогда происходят локально у разработчиков, и CI бездействует — им надо проводить интеграцию руками), а во-вторых порождает много коммитов слияния. В общем, там много можно копий сломать. :)
ptQa
11.04.2018 02:43It's important to note that, most of the time, feature branching like this is a different approach to CI. One of the principles of CI is that everyone commits to the mainline every day. So unless feature branches only last less than a day, running a feature branch is a different animal to CI.
Falstaff
11.04.2018 03:37Это уже проблема терминологии. Feature branches существуют и в том, что Мартин называет CI, просто они интегрируются часто. Поэтому, если вы используете его терминологию, и если кто-то говорит, что есть feature branch, то вы ещё не знаете, CI это или нет, и вам ещё надо выяснять, насколько часто она интегрируется.
ptQa
12.04.2018 17:01+1Все так, но навскидку в 90% случаев, feature branch это интеграция 1 раз когда фича сделана. В противном случае зачем вам ветка для коммитов только этой фичи?
Telichkin
11.04.2018 14:48+2CI, Agile, DevOps имеют между собой одну общую черту — их убил маркетинг. Теперь CI — это не способ улучшения коммуникации в командах разработки, а GitlabCI, Jenkins, Travis и прочие инструменты. Agile и DevOps — не набор ценностей и принципов, а Kanban, Scrum, Daily meeting, Docker и другие buzzwords.
Очень похоже на религию, когда вместо философии и духа учения соблюдаются только обряды.
VioletGiraffe
10.04.2018 17:16забыл написать «внутри современной CI»
Получается, что никакую современную CI нельзя просто и поставить себе на сервер бесплатно? Кроме, может быть Gitlab, но нутром чую, что Gitlab CI работает только с Gitlab-хостингом.
Appveyor примечателен тем, что это Windows, и точно так же, как Travis, интегрирован с Github и бесплатен для open-source проектов.pvs043
10.04.2018 17:57Получается, что никакую современную CI нельзя просто и поставить себе на сервер бесплатно? Кроме, может быть Gitlab, но нутром чую, что Gitlab CI работает только с Gitlab-хостингом.
Да, после прочтения статьи как раз возникает этот вопрос.
Appveyor примечателен тем, что это Windows
Пользую Appveyor в своем проекте на GitHub (PowerShell DSC) — результатом очень доволен.
Возможна ли реализация в локальном GitLab такой схемы CI: виртуалка Windows + PowerShell 5.1 + git + Pester?
Тесты сводятся к прогону Pester.nem Автор
10.04.2018 19:41что Gitlab CI работает только с Gitlab-хостингом
Да, все дорогу было именно так. Они в последнем релизе выкатили фичу когда можно внешний репозиторий подключать, но я если честно еще не успел проверить насколько она хорошо работает.
SkryabinD
10.04.2018 20:29А что можете сказать про Bitbucket Pipelines? У меня там репозитории, смотрю сейчас на их реализацию CI.
nem Автор
10.04.2018 20:36У меня немного опыта работы с ним. Там тоже docker, тоже настройки в yaml, что хорошо.
Он попроще гитлаба. Насколько я понял, там нет возможности разбить задачу на подзадачи — просто выполняет твои скрипты один за другим, и как следствие нет визуализации пайплайна.
Но в целом работает, а это главное.
VioletGiraffe
10.04.2018 21:01Там не работают примитивные вещи, из-за которых я не смог вообще пощупать эту систему. Детские болезни не вылечены. Конкретно — нельзя склонировать https сабрепозитории. И всё, капут, проект не клонируется, потому что он зависит от сабреп.
samizdam
11.04.2018 17:34Смотрел Bitbucket Pipelines в конце 2017. Сыровато было. Конкретнее — подвела интеграция с docker, хотя аналогичные задачи решал без проблем на travis и gitlab-ci.
PQR
11.04.2018 22:26Я пользуюсь Bitbucket Pipelines, действительно очень простой, хорошо интегрирован в хостинг репозиториев bitbucket. Более подробно рассказывал про него в подкасте: 5minphp.ru/episode29
SkryabinD
12.04.2018 08:13Находил эту страницу, познавательно. Но нигде так и не нашел, как правильно деплоить на сервер. Кроме как командой scp или rsync, но не думаю, что это оптимальное решение, когда нужно выложить свежую версию сервера на ExpressJS.
Veter9
11.04.2018 08:45А есть ли возможность использования CI на embedded системах?
Не очень понимаю как это будет работать.Falstaff
11.04.2018 16:11Есть, почему бы нет. Будет сложнее с тестами (во-первых, их где-то надо запускать, во-вторых в embedded надо прилагать больше усилий и внимания чтобы отвязать тестируемый код от железа), но как минимум CI система может вам делать всевозможные сборки плюс статический анализ, например.
rudenkovk
11.04.2018 11:45+1Гитлаб прекрасен, для разработчика. Для манагер/продукта — это ад, зло и содомия. Хотя прошу прощения, это немного оффтопик. Просто мне пришлось с гитлабом работать, как с позиции разработчика/девопса, так и с позиции архитектора/продукта, то есть с манакгерской позиции. Наболело :)
Busla
11.04.2018 12:51любопытно, а можете конкретнее осветить?
rudenkovk
11.04.2018 13:20Свести доски в что-то одно, для того чтобы увидеть общую картину не понятно как. Доски перегружены и не очень явно настраивается фильтрация.
Требует обязательной аккуратности от программистов, чтобы выставлять labels. Бизнесу (не техникам) очень тяжело понять как работать с доской и issues вообще. Ведение "user history" или "epic", мягко говоря не удобно.
Мы попробовали подойти, как к канбану, и как scrum. Наверное, если бы мы сидели в офисе, то за какое-то врем мы бы договорились и зашли бы, но так как, команда на 70% распределенная, мы отказались в сторону jira, и зажили, как ни странно :)
gubber
11.04.2018 14:39Я прочитал несколько ваших статей. Достаточно интересно.
Как раз сейчас решаю подобные проблемы. Но у меня задача сложнее:
есть несколько доккер модулей для одного приложения. Каждый из таких модулей живёт в своём репозитории и собирается отдельной сборкой. Хочется настроить режим превью разработки (он же staging). А проблема заключается в том, что есть задачи, которые задевают несколько модулей. И задача состоит в том, чтобы для тех модулей, которые не были затронуты, надо собрать/развернуть из ветки «current» (условно стабильной), а для тех модулей, которые задействованы в изменениях, надо собрать из FEATURE ветки, а после этого установить.
Интересно, можно ли организовать такой pipeline в GitLib?Telichkin
11.04.2018 14:53Рассматривали ли вы вариант использования монорепозитория? Сразу уберет описанные вами боли, так как в dev-ветке модули, которые не изменялись, будут current-версии.
gubber
11.04.2018 15:06Пока нет. Это не является в данный момент серьёзной проблемой, чтобы сейчас перестраивать весь процесс разработки.
squizduos
11.04.2018 14:47В статье незаслуженно забыт Drone CI, который отвечает на большинство вопросов разработчиков выше.
1. Self-hosted, опенсорсный, а как следствие — бесплатен на приватных проектах в любом количестве и без каких-либо ограничений.
2. Очень простой и шустрый — благодаря Go в основе, два экземпляра спокойно крутятся на самом дешевом инстансе за 3 евро.
3. Превосходно интегрируется с Github, Butbucket и Gitlab (включая вариант с self-hosted)
4. Настройка, как и у Travis, Circle CI и Gitlab CI — через конфигурационный файл.
5. Интегрируется с мессенджерами — например, отсылает статус сборки в Slack и Telegram.
Из недостатков:
1. Поддерживает один источник данных — то есть, нельзя одновременно собирать проекты с Gitlab и собственного Gitlab.
2. Жёстко завязан на Docker — не могу назвать это недостатком, но кому-то может быть критично.
3. Управление пользователями довольно дубовое — админы прописываются в конфигфайле, например.
abar
11.04.2018 14:47Работаю студентом-девелопером в девопс-отделе крупной компании, и мне интересно, что почти ни в одной статье про CI/CD системы я не вижу упоминаний используемой у нас GOcd.
Для нужд нашей компании она подходит почти идеально (только в части проектов используется Джекинс), к тому же я просто не представляю, как было бы возможно перенести сотни различных проектов и их пайплайнов (часть из которых требует кастомных плагинов) на любую другую систему, но нигде больше я пока даже и не видел особо упоминаний этой системы.
То ли мы — такие динозавры, каких ещё поискать, то ли просто ребятам из ThoughtWorks'а нужно поработать над стратегией продвижения.
PQR
11.04.2018 22:34Из интересного, что сам недавно узнал, даже в мире 1С разработки продвинутые ребята внедряют Continues Integration процессы: silverbulleters.org
andrew8712
12.04.2018 14:37Спасибо за интересную и насущную статью.
Такой вопрос: что если в jobе CI производится инкремент билда/версии приложении, и это изменение пушится в репозиторий? CI опять ведь начнет билдить с этого пуша.
ExTalosDx
Я так понимаю эти фичи есть и в обычном Gitlab? (Тот который можно у себя хостить)
nem Автор
Да, CI (и не только) есть в GitLab Community Edition, который можно хостить у себя.