Comments 56

Я так понимаю эти фичи есть и в обычном Gitlab? (Тот который можно у себя хостить)

Да, CI (и не только) есть в GitLab Community Edition, который можно хостить у себя.

На каждый пуш в репозиторий CI-система создает виртуальную машину, внутри которой запускает ваши инструкции, забирает результаты работы, и гасит машину

Не надо обобщать конкретные реализации до общего правила. В мире полно CI-систем, которые не используют никаких виртуальных машин или контейнеров.

Пожалуй, раскрою мысль.

Главная задача CI-системы — она должна уметь построить проект от и до. Любой проект. В том числе проект, в котором на этапе сборки используются сторонние утилиты с графическими инсталяторами просящими серийный номер и ключ. Такие утилиты в контейнер не положить, тут только предварительно вручную готовить виртуалку. Или даже не виртуалку — если утилита детектирует запуск в виртуалке и отказывается там работать из своих DRM-соображений.

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

Конечно, если делается новый проект, и есть возможность выбирать CI именно для этого проекта (а не на следующие 10 лет разработки) — то проблем вроде как нет.

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

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

Постепенно CI перекатывается в контейнеры почти полностью. Дело в изоляции. Другими методами крайне сложно правильно подготовить окружение и гарантировать повторяемость.

Запустить свой первый билд внутри CI — задача двух минут
— прочитал я после двух недель возни с настройкой Jenkins (c перерывами, конечно).
Travis CI и почему-то забытый в статье Appveyor — классные системы в том плане, что настройка достаточно простая, всё быстро и просто, много примеров, можно найти, как делать всякую эзотерическую фигню. У Appveyor даже есть вменяемый саппорт. Интеграция с Гитхаб очень удобная. Но для приватных проектов они платные. Для случая, когда хочется сэкономить, не нашёл альтернативы Дженкинсу, плюс у него полный контроль над происходящим, можно настроить свою инфраструктуру как угодно.

Сорян, забыл написать "внутри современной CI". Я ж не зря советую сторониться Jenkins-а. Он травмирует психику молодых разработчиков, и они потом боятся CI как огня.


Appveyor забыт в этой статье как и куча других CI-систем. В статье Гитхаба про популярные CI-системы он оказался на 4-ом месте. В отчет Forrester Wave вообще не вошел, поэтому он не привлек моего внимания.

Да вроде нормально он все делает, хоть я и относительно недавно начал вникать в CI. Например, он позволяет иметь главный сервер и сервера-слейвы на которых будет сборка. По моему, удобно.

А что до travis. Все же для pet-проектов с ценами перебор.
позволяет иметь главный сервер и сервера-слейвы

В гитлабе ты просто поднимаешь дополнительные раннеры (а не поднимаешь еще один гитлаб в slave-режиме)


Все же для pet-проектов с ценами перебор.

Да, увы.

В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.

Да нет, прикол вовсе не в том, чтобы собирать каждый день. Прикол в том чтобы мерджить каждый день (даже если ты не доделал фичу, ты мержишь в конце дня). А это намного сложнее.


А настройка билд-сервера это тривиальная задача, которая в принципе не про CI.


Best practice современной разработки — фичебранчи и пулреквесты.

А как же https://trunkbaseddevelopment.com/ ?

Прикол в том чтобы мерджить каждый день

Да, пожалуй так будет вернее. Я это подразумевал, но не акцентировал на этом внимание. Спасибо.


А как же https://trunkbaseddevelopment.com/

Не встречал раньше этот подход. Спасибо, почитаю.

Да, пожалуй так будет вернее

Не, не, различие тут не "верно"/"вернее". Просто написанное вами в статье неверно.


Я это подразумевал

Сомневаюсь, поскольку дальше вы пишите, что фичебранчи это best practice. Хотя это в принципе противоречит CI подходу. Думаю, что вы просто никогда не читали даже статьи в Википедии с определением CI.

Мартин там скорее пишет не про то, что этот подход не совместим с CI, а про то, что при таком подходе от CI получается меньше пользы. Причём сперва он в целом говорит о недостатках обычного feature branch подхода, упирая на ситуацию, при которой двое работают в долгоживущих локальных ветках над одним и тем же кодом, и у одного из них потом возникает большой сломанный merge (что обычно не так страшно). И при этом он взамен предлагает свой promiscuous intergration, когда feature branches часто мёржатся друг между другом — что во-первых не решает проблемы CI (изменения-то всё равно тогда происходят локально у разработчиков, и CI бездействует — им надо проводить интеграцию руками), а во-вторых порождает много коммитов слияния. В общем, там много можно копий сломать. :)

It'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.

Это уже проблема терминологии. Feature branches существуют и в том, что Мартин называет CI, просто они интегрируются часто. Поэтому, если вы используете его терминологию, и если кто-то говорит, что есть feature branch, то вы ещё не знаете, CI это или нет, и вам ещё надо выяснять, насколько часто она интегрируется.

Все так, но навскидку в 90% случаев, feature branch это интеграция 1 раз когда фича сделана. В противном случае зачем вам ветка для коммитов только этой фичи?

CI, Agile, DevOps имеют между собой одну общую черту — их убил маркетинг. Теперь CI — это не способ улучшения коммуникации в командах разработки, а GitlabCI, Jenkins, Travis и прочие инструменты. Agile и DevOps — не набор ценностей и принципов, а Kanban, Scrum, Daily meeting, Docker и другие buzzwords.


Очень похоже на религию, когда вместо философии и духа учения соблюдаются только обряды.

забыл написать «внутри современной CI»

Получается, что никакую современную CI нельзя просто и поставить себе на сервер бесплатно? Кроме, может быть Gitlab, но нутром чую, что Gitlab CI работает только с Gitlab-хостингом.

Appveyor примечателен тем, что это Windows, и точно так же, как Travis, интегрирован с Github и бесплатен для open-source проектов.
Получается, что никакую современную CI нельзя просто и поставить себе на сервер бесплатно? Кроме, может быть Gitlab, но нутром чую, что Gitlab CI работает только с Gitlab-хостингом.

Да, после прочтения статьи как раз возникает этот вопрос.

Appveyor примечателен тем, что это Windows

Пользую Appveyor в своем проекте на GitHub (PowerShell DSC) — результатом очень доволен.
Возможна ли реализация в локальном GitLab такой схемы CI: виртуалка Windows + PowerShell 5.1 + git + Pester?
Тесты сводятся к прогону Pester.
Возможна ли реализация в локальном GitLab такой схемы CI: виртуалка Windows + PowerShell 5.1 + git + Pester?

Думаю что да, хотя я по виде совсем не специалист.

А что можете сказать про Bitbucket Pipelines? У меня там репозитории, смотрю сейчас на их реализацию CI.

У меня немного опыта работы с ним. Там тоже docker, тоже настройки в yaml, что хорошо.
Он попроще гитлаба. Насколько я понял, там нет возможности разбить задачу на подзадачи — просто выполняет твои скрипты один за другим, и как следствие нет визуализации пайплайна.


Но в целом работает, а это главное.

Там не работают примитивные вещи, из-за которых я не смог вообще пощупать эту систему. Детские болезни не вылечены. Конкретно — нельзя склонировать https сабрепозитории. И всё, капут, проект не клонируется, потому что он зависит от сабреп.
Смотрел Bitbucket Pipelines в конце 2017. Сыровато было. Конкретнее — подвела интеграция с docker, хотя аналогичные задачи решал без проблем на travis и gitlab-ci.
Я пользуюсь Bitbucket Pipelines, действительно очень простой, хорошо интегрирован в хостинг репозиториев bitbucket. Более подробно рассказывал про него в подкасте: 5minphp.ru/episode29
Находил эту страницу, познавательно. Но нигде так и не нашел, как правильно деплоить на сервер. Кроме как командой scp или rsync, но не думаю, что это оптимальное решение, когда нужно выложить свежую версию сервера на ExpressJS.
А есть ли возможность использования CI на embedded системах?
Не очень понимаю как это будет работать.
А в чем разница? Ну, разве что деплой скорее всего придется не включать.

Есть, почему бы нет. Будет сложнее с тестами (во-первых, их где-то надо запускать, во-вторых в embedded надо прилагать больше усилий и внимания чтобы отвязать тестируемый код от железа), но как минимум CI система может вам делать всевозможные сборки плюс статический анализ, например.

Гитлаб прекрасен, для разработчика. Для манагер/продукта — это ад, зло и содомия. Хотя прошу прощения, это немного оффтопик. Просто мне пришлось с гитлабом работать, как с позиции разработчика/девопса, так и с позиции архитектора/продукта, то есть с манакгерской позиции. Наболело :)

Свести доски в что-то одно, для того чтобы увидеть общую картину не понятно как. Доски перегружены и не очень явно настраивается фильтрация.
Требует обязательной аккуратности от программистов, чтобы выставлять labels. Бизнесу (не техникам) очень тяжело понять как работать с доской и issues вообще. Ведение "user history" или "epic", мягко говоря не удобно.


Мы попробовали подойти, как к канбану, и как scrum. Наверное, если бы мы сидели в офисе, то за какое-то врем мы бы договорились и зашли бы, но так как, команда на 70% распределенная, мы отказались в сторону jira, и зажили, как ни странно :)

Я прочитал несколько ваших статей. Достаточно интересно.
Как раз сейчас решаю подобные проблемы. Но у меня задача сложнее:
есть несколько доккер модулей для одного приложения. Каждый из таких модулей живёт в своём репозитории и собирается отдельной сборкой. Хочется настроить режим превью разработки (он же staging). А проблема заключается в том, что есть задачи, которые задевают несколько модулей. И задача состоит в том, чтобы для тех модулей, которые не были затронуты, надо собрать/развернуть из ветки «current» (условно стабильной), а для тех модулей, которые задействованы в изменениях, надо собрать из FEATURE ветки, а после этого установить.
Интересно, можно ли организовать такой pipeline в GitLib?

Рассматривали ли вы вариант использования монорепозитория? Сразу уберет описанные вами боли, так как в dev-ветке модули, которые не изменялись, будут current-версии.

Пока нет. Это не является в данный момент серьёзной проблемой, чтобы сейчас перестраивать весь процесс разработки.
В статье незаслуженно забыт 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. Управление пользователями довольно дубовое — админы прописываются в конфигфайле, например.
Работаю студентом-девелопером в девопс-отделе крупной компании, и мне интересно, что почти ни в одной статье про CI/CD системы я не вижу упоминаний используемой у нас GOcd.

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

То ли мы — такие динозавры, каких ещё поискать, то ли просто ребятам из ThoughtWorks'а нужно поработать над стратегией продвижения.
Из интересного, что сам недавно узнал, даже в мире 1С разработки продвинутые ребята внедряют Continues Integration процессы: silverbulleters.org
Это вы еще «книжку» не видели — с Jenkins и GitLab для 1С. isthisdesign.org/bookoneorder

Но в целом всё крутится вокруг вот это проекта habr.com/post/301064 и репозиториев на github

уж коли в статье помянут GitLab напомню, что в скриншоте не хватает sonarQube (есть только linter) и не хватает deploy фазы — gitLab сейчас пропагандирует реализацию цикла Деминга — docs.gitlab.com/ee/user/project/cycle_analytics.html

Плюс у gitlab есть фишка AutoDevOps — позволяющая сделать развертывание uat контуров под фичу.

P.S. Все продвинутые в 1С ребята есть на Хабре ;-) EvilBeaver artbear и остальные ;-)

А кроме того — docker во все поля. И да, для devops под 1с мы сделали свой скриптовый движок и пишем линукс-скрипты прямо на языке 1С )

А в чем рисовали такую симпатичную графику, как с бранчами и в разделе «у CI под капотом»?
Спасибо за интересную и насущную статью.
Такой вопрос: что если в jobе CI производится инкремент билда/версии приложении, и это изменение пушится в репозиторий? CI опять ведь начнет билдить с этого пуша.

можно в commit message добавить [skip ci], и тогда ci не затриггерится

Вот только это убьёт и запуск ручных тасков для такого комита :( Что конечно логично, если задуматься, но не всегда полезно. Я использую вот такую конструкцию (shell:cmd) в начале тасков которые надо пропустить при наличии строчки "[CI Release]" в commit message


    script:
        - git show -s --format=%%B | findstr /C:"[CI Release]" >nul 2>&1 && (exit 0) || (set errorlevel=0)
Раньше еще было сильное ограничение по времени, сейчас не проверял. Но вряд ли что-то поменялось
Пробежался глазами, увидел, что не надо юзать TeamCity, прекратил дальнейшее чтение.

Всего лишь не рекомендую его тем, кто хочет впервые попробовать CI на практике и далек от enterprise-разработки, IDE и прочего в таком духе.

Only those users with full accounts are able to leave comments. Log in, please.