company_banner

CI\CD для стартапа: какие есть инструменты, и почему ими пользуются не только крупные и известные компании

    Разработчики CI\CD-инструментов часто указывают в качестве клиентов крупные компании — Microsoft, Oculus, Red Hat, даже Ferrari и NASA. Казалось бы, что такие бренды работают только с дорогими системами, которые не сможет позволить себе условный стартап из пары разработчиков и дизайнера. Но значительная часть инструментов доступна и для небольших команд.

    На что можно обратить внимание — расскажем далее.


    Фото — Csaba Balazs — Unsplash



    PHP Censor


    CI-сервер с открытым исходным кодом, облегчающий сборку проектов на PHP. Это — форк проекта PHPCI. Сам PHPCI до сих пор развивается, однако не так активно, как прежде.

    PHP Censor умеет работать с репозиториями GitHub, GitLab, Mercurial и несколькими другими. Для тестирования кода инструмент использует библиотеки Atoum, PHP Spec, Behat, Codeception. Вот пример файла конфигурации для первого случая:

    test:
        atoum:
            args: "command line arguments go here"
            config: "path to config file"
            directory: "directory to run tests"
            executable: "path to atoum executable"
    

    Считается, что PHP Censor неплохо подходит для развертывания небольших проектов, но хостить и настраивать его придется самостоятельно (self-hosted). Эту задачу упрощает довольно подробная документация — она есть на GitHub.



    Rex


    Rex — это сокращение от Remote Execution. Систему разработал инженер Ференц Эрки (Ferenc Erki), чтобы автоматизировать процессы в дата-центре. Работа Rex строится на Perl-скриптах, но знать этот язык для взаимодействия с инструментом необязательно — большинство операций (например, копирование файлов) описано в библиотеке функций, а скрипты часто умещаются в десять строк. Вот пример для входа на нескольких серверах и запуска uptime:

    use Rex -feature => ['1.3'];
    
    user "my-user";
    password "my-password";
    
    group myservers => "mywebserver", "mymailserver", "myfileserver";
    
    desc "Get the uptime of all servers";
    task "uptime", group => "myservers", sub {
       my $output = run "uptime";
       say $output;
    };
    

    Начать свое знакомство с инструментом рекомендуем с официального гайда и электронной книги, которую в настоящий момент дописывают.



    Open Build Service (OBS)


    Это — платформа для оптимизации разработки дистрибутивов. Её код открыт и лежит в репозитории на GitHub. Автор инструмента — компания Novell. Она участвовала в разработке дистрибутива SuSE, а этот проект изначально назвала openSUSE Build Service. Неудивительно, что Open Build Service используют для сборки проектов в openSUSE, Tizen и VideoLAN. С инструментом также работают Dell, SGI и Intel. Но есть среди постоянных пользователей и небольшие стартапы. Специально для них авторы собрали (стр.10) преднастроенный программный пакет. Сама система полностью бесплатна — потратить деньги придется только на хостинг или железный сервер для её развертки.

    Но за все время существования инструмент так и не обзавелся широким сообществом. Хотя он был частью Linux Developer Network, отвечающей за стандартизацию открытой ОС. Бывает сложно найти на тематических форумах ответ на интересующий вопрос. Но один из резидентов Quora отметил, что в IRC-чате на Freenode участники сообщества отвечают довольно охотно. Проблема маленького комьюнити не глобальна, так как решение многих задач описано в официальной документации (PDF и EPUB). Там же можно найти лучшие практики по работе с OBS (есть примеры и кейсы).



    Rundeck


    Открытый инструмент (GitHub), автоматизирующий задачи в дата-центре и облаке с помощью скриптов. За их выполнение отвечает специальный сервер сценариев. Можно сказать, что Rundeck — это «дочка» платформы для управления приложениями ControlTier. От неё Rundeck отделился в 2010 году и обзавелся новой функциональностью — например, интеграциями с Puppet, Chef, Git и Jenkins.

    Системой пользуются в The Walt Disney Company, Salesforce и Ticketmaster. Но проект подходит и для стартапов. Это связано с тем, что Rundeck распространяется по лицензии Apache v2.0. При этом инструмент довольно прост в использовании.

    Резидент Reddit, который работал с Rundeck, говорит, что решал большую часть трудностей самостоятельно. С этим ему помогли документация и электронные книги, опубликованные разработчиками.

    Также в сети можно найти краткие руководства по настройке инструмента:




    GoCD


    Открытый инструмент (GitHub) автоматизирующий контроль версий кода. Его представила в 2007 году компания ThoughtWorks — тогда проект назывался Cruise.

    С GoCD работают инженеры онлайн-ресурса по продаже автомобилей AutoTrader, генеалогический сервис Ancestry и поставщик кредитных карт Barclaycard. Однако четверть пользователей инструмента составляет малый бизнес.

    Популярность сервиса среди стартапов можно объяснить его открытостью — он распространяется по лицензии Apache v2.0. При этом GoCD имеет плагины для интеграции со сторонним ПО — системами авторизации и облачными решениями. Правда система довольно сложна в освоении — у нее большое число операторов и команд. Также некоторые пользователи жалуются на неудачный интерфейс и необходимость настраивать агенты для масштабирования.


    Фото — Matt Wildbore — Unsplash

    Если вы хотите опробовать GoCD на практике, то на сайте проекта можно найти официальную документацию. Как источник дополнительной информации также можно рекомендовать блог разработчиков GoCD с руководствами по настройке.



    Jenkins


    Jenkins широко известен и считается своеобразным стандартом в сфере CI\CD — конечно, без него эта подборка была бы не совсем полной. Инструмент появился в 2011 году, став ответвлением проекта Hudson от Oracle.

    Сегодня с Jenkins работают в NASA, Nintendo и других крупных организациях. Однако более 8% пользователей приходится на небольшие коллективы до десяти человек. Продукт полностью бесплатен и распространяется по лицензии MIT. Однако хостить и настраивать Jenkins придется самостоятельно — ему требуется выделенный сервер.

    За все время существования инструмента вокруг него сформировалось обширное сообщество. Пользователи активно общаются в тредах на Reddit и Google Groups. Материалы по Jenkins также регулярно появляются на Хабре. Если вы бы хотели стать частью комьюнити и начать работу с Jenkins, есть официальная документация и справочник от разработчиков. Еще мы рекомендуем следующие гайды и книги:


    У Jenkins есть несколько полезных сторонних проектов. Первый — плагин Configuration as Code. Он упрощает настройку Jenkins за счет удобочитаемых API, которые понятны даже администраторам без глубоких познаний инструмента. Второй — система Jenkins X для облака. Она ускоряет доставку приложений, разворачиваемых на масштабной ИТ-инфраструктуре за счет автоматизации некоторых рутинных задач.



    Buildbot


    Это — continuous integration система для автоматизации цикла сборки и тестирования приложений. Она автоматически проверяет работоспособность кода каждый раз, когда в него вносятся какие-либо изменения.

    Автором инструмента выступил инженер Брайан Уорнер (Brian Warner). Сегодня его на посту сменила инициативная группа Buildbot Oversight Committee, в которую входит шесть разработчиков.

    Buildbot используется такими проектами, как LLVM, MariaDB, Blender и Dr.Web. Но его также применяют в менее крупных проектах вроде wxWidgets и Flathub. Система поддерживает все современные VCS и обладает гибкими настройками билдов за счет использования Python для их описания. Разобраться со всеми ними поможет официальная документация и сторонние туториалы, например, вот краткое руководство от IBM.



    Разумеется, это не все DevOps инструменты, на которые стоит обратить внимание небольшим организациям и стартапам. Приводите свои любимые инструменты в комментариях, и мы постараемся рассказать о них в одном из следующих материалов.



    О чем мы пишем в корпоративном блоге:

    ITGLOBAL.COM
    Рассказываем про Managed IT, облака и ИБ.

    Комментарии 22

      +7

      Не проще ли завести Gitlab Community Edition? И одним махом решить большую часть проблем DevOps цикла?

        +6
        Удивительно, что Гитлаба нет в подборке.
        Облачная версия очень даже в бесплатном варианте. А подписка стоит не дорого. Для любителей своего хостинга можно поставить к себе. Что еще нужно то?
        В комплекте с CI/CD собственно Git, Docker Registry, надстройка для Kubernetes.
          0
          Нужен GitFlow. Если мы правильно поняли то, он в гитлабе не возможен?
            0
            Честно говоря, не пользовался GiFlow, но вот что нашел: docs.gitlab.com/ee/workflow/gitlab_flow.html
              0
              Как не возможен. Я его использую. Это методология управления ветками на базе git. Этот подход не зависит от инструмента. Хоть на TeamCity хоть на Gitlab-CI можно реализовать
                0
                Это работает когда у вас в один репозитарий комитят несколько человек и проект из состоит из нескольких репозиториев? Насколько я понял, что в гитлабе один юзер это не юзер как в гите, а дополнительная ветка в репозитории.
                На сам деле мы гитлаб пробовали очень давно. Тогда у них небыло gitflow. Скорее всего они что то сделали по этому поводу.
            +3
            А как же gitlab-ci?
              +2

              Gitlab-ci думаю лучший выбор для стартапера

                +3

                Зашел, чтобы оставить коммент про gitlab-ci. И очень рад, что хабровчане о нем знают и любят. Это действительно великолепный инструмент, который интегрирован в окружение gitlab инфраструктуры. Не уверен можно ли его использовать автономно вне gitlab. Но в любом случае — это отличное решение для небольших команд, кто не хочет сильно заморачиваться на инфраструктуре для CICD, но в тоже время смотрит в будущее своего проекта.

                  +1
                    0

                    И всё остальное не нужно)

                    0

                    CI/CD использую во всех своих проектах, очень удобно, от 0 до 2 команд на деплой.


                    На работе в "энтерпрайзе" есть то, что у компании называется CI/CD, но только объяснение "как оно работает" занимает 3 часа, а деплой это ад, вовлекающий 3 докера, практически вручную запускаемые пустыми коммитами в 3 репозитория различных команд, которые не хотят делиться доступами и ходят через PRы при том, что, внезапно выплевываемый результат не деплой, а докер имейдж, который ещё надо развернуть финальной танцей с бубном.

                      +1
                      TeamCity забыли
                        +2
                        travis?
                          0

                          Кроме упомянутого GitLab (который для стартапа наверное лучший вариант сейчас), есть еще AWX — upstream Ansible Tower. Что-то вроде Rundeck. Удобно если ваши джобы и так ansible based. Не упомянули и ZuulCI из Openstack.
                          А так у Jenkins почти монополия, несметное количество плагинов, расширений, огромное комьюнити.

                            0
                            Я по сделал форк репозиториия DeepNude в Gitlab, из статьи на хабре.
                            Меня заблокировали. Мой аккаунт на Гитлабе. Я начал вести переписку со службой поддержки, меня разлочили, после того, как я согласился сам удалить репоизторий DeepNude.

                            На GitHub, насколько я знаю, удаляли без согласования с пользователем его личные репозитории c DeepNude.

                            Этим мне Гитлаб очень приглянулся, что относится к коду пользователей, как к частной собственности, в отличии от Гитхаба.

                            Jenkins — это Гитхаб, Gitlab CI — это Гитлаб.

                            К тому же, прекрасная и достаточно доступная документация по Gitlab CI.
                              0

                              "Jenkins — это Гитхаб" — что это значит? Это девиз?

                                0
                                Это не надо понимать буквально, в лоб.
                                Имеется ввиду, что большинство пользователей Github выбирают для CI Jenkins, и это такой «стандарт де-факто» на этой платформе.
                                  0
                                  Я думаю большинство пользователей вообще выбирают Jenkins и это никак не связано с Github. Там кстати вполне популярен Travis.
                                    0
                                    Тут была бы уместна статистическая диаграмма по использованию инструментов для CI,
                                    искал, но нашел другое интересное сравнение
                                    Сравнение инструментов CI/CD

                                    Jenkins

                                    Инструмент CI с открытым исходным кодом, написанный на Java и выпущенный под лицензией MIT. Первоначально являлся частью проекта Hudson, принадлежавшего компании Oracle. Впервые был выпущен 2 февраля 2011 года.

                                    Jenkins представляет из себя достаточно гибкую систему автоматизации задач, связанных с программным обеспечением. Почти весь функционал реализован с помощью плагинов. Хоть это обеспечивает большую гибкость, но в то же время может и являться большим минусом из-за конфликтов с определёнными версиями или остановкой поддержки плагина.

                                    Jenkins pipeline(трубопровод) доступен в виде плагина с 2016 года. Использует язык Groovy, хранимый в удаленном репозитории или же в локальных файлах Jenkins. Основной минус Jenkins заключается в том, что возможность определять groovy-скрипты вне репозитория и использование определенных плагинов для реализации нужного функционала, затрудняют внедрение на других системах Jenkins.

                                    GitLab CI

                                    Инструмент CI, встроенный в GitLab, написанный на на Ruby and Go и выпущены под лицензией MIT. Изначально был выпущен как самостоятельный проект. В дальнейшем интегрирован в основное программное обеспечение GitLab в сентябре 2015 года.

                                    Процесс CI/CD в GitLab CI определяется отдельным файлом в самом хранилище кода с использованием синтаксиса конфигурации YAML. Для выполнения задач используется изолированные виртуальные машины, называемые «GitLab CI runners». Они являются кроссплатформенными.

                                    Главный минус GitLab CI заключается в том, что он привязан к GitLab, что не позволяет использовать другие репозитории. Плюсом является то, что для настройки среды CI/CD не требуется установка и изучение дополнительного инструментария. Нужно всего лишь включить несколько параметров в веб-интерфейсе, зарегистрировать «GitLab CI runner» и добавить файл с синтаксисом конфигурации YAML в репозиторий.

                                    Buildbot

                                    Инструмент CI, написанный на Python и выпускаемый под лицензией GPL. Выпущен в 2003 году в качестве альтернативы проекту Tinderbox в Mozilla. Первоначально являлся инструментом автоматизации тестирования сборки.

                                    Основной минус и одновременно плюс в том, что конфигурация Buildbot полностью написана на Python, что значительно сложнее, чем в других системах, но в то же время это дает больше возможностей для разработки идеального рабочего процесса.
                                    Drone

                                    Современный инструмент CI/CD, основанный на pipeline, написан на Go и выпускаемый под лицензией Apache. Весь рабочий процесс основан на Docker контейнерах. Имеет встроенную поддержку для настройки сертификатов SSL с Let's Encrypt.

                                    Как и в GitLab CI, для конфигурации задач используется синтаксис YAML в репозитории.

                                    Как и в Jenkins, присутствует система плагинов, но представлена она в виде специальных контейнеров Docker, в которых предварительно сконфигурированы задачи для рабочего процесса. Это является несравненным плюсом. Но Docker-контейнеры не всегда удобно использовать на Windows системах.

                                    Пожалуйста, не забудьте правильно оформить цитату:
                                    Бабаев В.С. ИССЛЕДОВАНИЕ СОВРЕМЕННЫХ CI/CD ИНСТРУМЕНТОВ И ВНЕДРЕНИЕ ИХ В КРУПНЫЕ WEB-ПРОЕКТЫ НА ПРИМЕРЕ JENKINS // Научное сообщество студентов XXI столетия. ТЕХНИЧЕСКИЕ НАУКИ: сб. ст. по мат. LXXIV междунар. студ. науч.-практ. конф. № 2(73). URL: sibac.info/archive/technic/2(73).pdf (дата обращения: 22.07.2019)
                              0
                              Не в обиду автору, но простое перечисление CI\CD и «почему ими пользуются» это скорее для толкового словаря, а не для статьи.
                                0
                                Успешно пользуюсь как Bitbucket Pipelines так и GitlabCI

                                Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                Самое читаемое