Комментарии 56
Я так понимаю эти фичи есть и в обычном Gitlab? (Тот который можно у себя хостить)
На каждый пуш в репозиторий CI-система создает виртуальную машину, внутри которой запускает ваши инструкции, забирает результаты работы, и гасит машину
Не надо обобщать конкретные реализации до общего правила. В мире полно CI-систем, которые не используют никаких виртуальных машин или контейнеров.
Главная задача CI-системы — она должна уметь построить проект от и до. Любой проект. В том числе проект, в котором на этапе сборки используются сторонние утилиты с графическими инсталяторами просящими серийный номер и ключ. Такие утилиты в контейнер не положить, тут только предварительно вручную готовить виртуалку. Или даже не виртуалку — если утилита детектирует запуск в виртуалке и отказывается там работать из своих DRM-соображений.
Поэтому использование докера для CI-системы — это не фича, а ограничение.
Конечно, если делается новый проект, и есть возможность выбирать CI именно для этого проекта (а не на следующие 10 лет разработки) — то проблем вроде как нет.
Все верно, спасибо! Но статья вводная, и я позволил себе несколько упростить картину мира. Плюс у меня есть уточнение что мы рассматриваем только "системы общего назначения", без специфики типа тестирования десктопных или мобильных приложений.
Все так. Если говорить за Гитлаб, он как раз не ограничен докером, но дефолтный режим в облачной версии Gitlab.com именно такой.
В мире полно CI-систем, которые не используют никаких виртуальных машин или контейнеров.
Постепенно CI перекатывается в контейнеры почти полностью. Дело в изоляции. Другими методами крайне сложно правильно подготовить окружение и гарантировать повторяемость.
Запустить свой первый билд внутри CI — задача двух минут— прочитал я после двух недель возни с настройкой Jenkins (c перерывами, конечно).
Travis CI и почему-то забытый в статье Appveyor — классные системы в том плане, что настройка достаточно простая, всё быстро и просто, много примеров, можно найти, как делать всякую эзотерическую фигню. У Appveyor даже есть вменяемый саппорт. Интеграция с Гитхаб очень удобная. Но для приватных проектов они платные. Для случая, когда хочется сэкономить, не нашёл альтернативы Дженкинсу, плюс у него полный контроль над происходящим, можно настроить свою инфраструктуру как угодно.
Сорян, забыл написать "внутри современной CI". Я ж не зря советую сторониться Jenkins-а. Он травмирует психику молодых разработчиков, и они потом боятся CI как огня.
Appveyor забыт в этой статье как и куча других CI-систем. В статье Гитхаба про популярные CI-системы он оказался на 4-ом месте. В отчет Forrester Wave вообще не вошел, поэтому он не привлек моего внимания.
В 1991 году Гради Буч, видимо, устал от такого безобразия, и предложил делать сборку всего проекта каждый день, чтобы выяснять несовместимости не в день релиза, а пораньше — и назвал этот подход Continuous Integration.
Да нет, прикол вовсе не в том, чтобы собирать каждый день. Прикол в том чтобы мерджить каждый день (даже если ты не доделал фичу, ты мержишь в конце дня). А это намного сложнее.
А настройка билд-сервера это тривиальная задача, которая в принципе не про CI.
Best practice современной разработки — фичебранчи и пулреквесты.
А как же https://trunkbaseddevelopment.com/ ?
Прикол в том чтобы мерджить каждый день
Да, пожалуй так будет вернее. Я это подразумевал, но не акцентировал на этом внимание. Спасибо.
А как же https://trunkbaseddevelopment.com/
Не встречал раньше этот подход. Спасибо, почитаю.
Да, пожалуй так будет вернее
Не, не, различие тут не "верно"/"вернее". Просто написанное вами в статье неверно.
Я это подразумевал
Сомневаюсь, поскольку дальше вы пишите, что фичебранчи это best practice. Хотя это в принципе противоречит CI подходу. Думаю, что вы просто никогда не читали даже статьи в Википедии с определением CI.
По поводу чем плох feature branch и почему этот подход не совместим с CI можно почитать тут, от одного из авторов термина https://martinfowler.com/bliki/FeatureBranch.html
Мартин там скорее пишет не про то, что этот подход не совместим с 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 это или нет, и вам ещё надо выяснять, насколько часто она интегрируется.
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 работает только с Gitlab-хостингом
Да, все дорогу было именно так. Они в последнем релизе выкатили фичу когда можно внешний репозиторий подключать, но я если честно еще не успел проверить насколько она хорошо работает.
Возможна ли реализация в локальном GitLab такой схемы CI: виртуалка Windows + PowerShell 5.1 + git + Pester?
Думаю что да, хотя я по виде совсем не специалист.
У меня немного опыта работы с ним. Там тоже docker, тоже настройки в yaml, что хорошо.
Он попроще гитлаба. Насколько я понял, там нет возможности разбить задачу на подзадачи — просто выполняет твои скрипты один за другим, и как следствие нет визуализации пайплайна.
Но в целом работает, а это главное.
Есть, почему бы нет. Будет сложнее с тестами (во-первых, их где-то надо запускать, во-вторых в embedded надо прилагать больше усилий и внимания чтобы отвязать тестируемый код от железа), но как минимум CI система может вам делать всевозможные сборки плюс статический анализ, например.
Гитлаб прекрасен, для разработчика. Для манагер/продукта — это ад, зло и содомия. Хотя прошу прощения, это немного оффтопик. Просто мне пришлось с гитлабом работать, как с позиции разработчика/девопса, так и с позиции архитектора/продукта, то есть с манакгерской позиции. Наболело :)
Свести доски в что-то одно, для того чтобы увидеть общую картину не понятно как. Доски перегружены и не очень явно настраивается фильтрация.
Требует обязательной аккуратности от программистов, чтобы выставлять labels. Бизнесу (не техникам) очень тяжело понять как работать с доской и issues вообще. Ведение "user history" или "epic", мягко говоря не удобно.
Мы попробовали подойти, как к канбану, и как scrum. Наверное, если бы мы сидели в офисе, то за какое-то врем мы бы договорились и зашли бы, но так как, команда на 70% распределенная, мы отказались в сторону jira, и зажили, как ни странно :)
Как раз сейчас решаю подобные проблемы. Но у меня задача сложнее:
есть несколько доккер модулей для одного приложения. Каждый из таких модулей живёт в своём репозитории и собирается отдельной сборкой. Хочется настроить режим превью разработки (он же staging). А проблема заключается в том, что есть задачи, которые задевают несколько модулей. И задача состоит в том, чтобы для тех модулей, которые не были затронуты, надо собрать/развернуть из ветки «current» (условно стабильной), а для тех модулей, которые задействованы в изменениях, надо собрать из FEATURE ветки, а после этого установить.
Интересно, можно ли организовать такой pipeline в GitLib?
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. Управление пользователями довольно дубовое — админы прописываются в конфигфайле, например.
Для нужд нашей компании она подходит почти идеально (только в части проектов используется Джекинс), к тому же я просто не представляю, как было бы возможно перенести сотни различных проектов и их пайплайнов (часть из которых требует кастомных плагинов) на любую другую систему, но нигде больше я пока даже и не видел особо упоминаний этой системы.
То ли мы — такие динозавры, каких ещё поискать, то ли просто ребятам из ThoughtWorks'а нужно поработать над стратегией продвижения.
Такой вопрос: что если в 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)
Для чего программисту Continuous Integration и с чего начинать