Представьте себе, что Роскосмос решил собрать новую ракету, не имея ни чертежей, ни четкого понимания того, как должна быть построена ракета.
Отдельный завод производит корпус ракеты, отдельный завод — двигатели, третий — сопла.
Гендиректор "Роскосмоса" рассказал, что доверяет профессионалам и мастерски делегирует всю работу заводам.
Через год все узлы доставляют в основной сборочный цех, и оказывается, что двигатель не помещается в корпус, а форсунки начинают плавиться еще во время пробных запусков двигателя.
Чтобы такой ерунды не происходило, в реальных проектах всегда есть этап планирования и проектирования, на котором фиксируются технические задания на то, как детали будут взаимодействовать друг с другом и какие характеристики они должны иметь.
При разработке программного обеспечения мы не можем себе позволить длительный этап проектирования, потому что… За это время будет потеряна бизнес-ценность того, что мы пытаемся разработать — конкуренты нас тупо обойдут. Поэтому команды, разрабатывающие программные компоненты (модули), часто вынуждены работать, не до конца понимая, как их модуль будет взаимодействовать с другими частями.
Как и в случае с ракетой, когда вы пытаетесь выпустить новую версию приложения, которое разрабатывается по частям несколькими командами, вы можете обнаружить, что некоторые модули несовместимы.
В 1991 году Грейди Бутч , видимо устал от такого безобразия, и предложил собирать весь проект каждый день, чтобы обнаружить несовместимости не в день релиза, а раньше — и назвал этот подход Continuous Integration. Действительно, составить программу проще, чем собрать ракету (особенно из недоработанных компонентов), так почему бы не начать делать это раз в день? В ?Экстремальное программирование Мы решили обострить эту тему и устраивать собрания несколько раз в день.
Что такое сборка?
Ну, например, вам нужно скопировать модули в одно место и начать компилировать программу.Если все получится, то сборку можно считать успешной; если нет, то у команды есть повод разобраться в этом подробнее и решить проблему, прежде чем все зайдет слишком далеко.
В интерпретируемых языках, таких как PHP, Python и Ruby, компилировать нечего.
В них сборка может включать запуск модульных тестов, развертывание веб-приложения на тестовом сервере и выполнение приемочных тестов на этом тестовом сервере.
Подводя итог, можно сказать, что непрерывная интеграция — это практика.
Цель практики — сократить количество интеграционных факапов и повысить качество выпускаемого ПО.
Суть метода заключается в запуске сборки проекта несколько раз в день.
Допускаю, что Гради Буч в давние времена начал практиковать CI вручную, бегая по отделам своей компании, заставляя всех давать ему дискеты с последними версиями модулей, а затем уже с языком наготове все это компилировал вручную :)
В нашем 2018 году уже немного проще — процесс CI автоматизирован в куче систем — выбирайте любую на свой вкус: 
О CI-системах
Их совсем немного .Они разные.
Есть специализированные для конкретного языка программирования.
Некоторые из них предназначены для разработки мобильных приложений, некоторые встроены в IDE, некоторые настраиваются через графический интерфейс, а некоторые настраиваются через файл конфигурации в репозитории.
Некоторые работают только в облаке, некоторые можно установить на собственные сервера.
Мы не будем сейчас пытаться охватить их все.
Возьмем только современные системы общего назначения, представляющие собой веб-приложения.
Современная разработка предполагает, что вы используете систему контроля версий.
Контроль версий почти всегда git. Git — это почти всегда GitHub или аналогичный сервис.
Лучшая практика современной разработки — это ветки функций и запросы на включение.
CI идеально вписывается в историю запросов на включение.
Вы не только видите все изменения, обсуждаете разработку конкретной фичи в одном месте, вы сразу видите статус соответствующей CI-билда: 
(здесь сборка не удалась - нужно зайти в Детали, узнать, что где сломалось и исправить)
Исправили, закоммитили, запушили, и процесс начинается заново — CI-система обнаруживает новые изменения в ветке и запускает новую сборку: 
Сборка может состоять из нескольких этапов.
Наиболее типичные из них — тесты, компиляция, развертывание.
Естественно, система CI должна объяснять, что это за этапы.
Настройка CI-систем
Все хорошие системы CI следуют принципу конфигурации как кода, где инструкции для системы CI — это просто еще один файл в репозитории вашего проекта.Как-то так получилось, что большинство систем используют для инструкций формат YAML. Простой файл инструкций для GitLab CI может выглядеть так:
Чуть более сложные инструкции (Круг CI):test_job: script: - ls -l
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-системы используют для этого Docker, другие обходятся без него.
Подсказка: возьмите тот, что с докером ;) (на самом деле все несколько сложнее, и большинство CI-систем могут работать в куче разных режимов, но лучше начать с режима по умолчанию — просто запуск задач внутри докер-контейнера)
Зачем все это обычному разработчику?
- Чем больше аспектов развития вы сможете охватить, тем выше ваша ценность.
Если вы просто написали код, запихнули его, а потом трава не растет — это одно.
Если при этом вы позаботились о тестах и развернутом приложении — совсем другое дело.
Если вы автоматизировали все это в CI — третье :)
- Просто поймите, что со временем CI станет тем же, что и контроль версий по умолчанию.
Вполне возможно, что вы посетили одно из следующих мест:
Ситуация №1
Два разработчика развиваются в разных ветках.Для каждого из них тесты проходят успешно, в том числе после слияния с мастером.
Но как только обе ветки объединяются в мастер, тесты начинают проваливаться.
Проблема в том, что без CI такой код легко может пойти в производство, и только там станет ясно наличие ошибки.
Ситуация №2
Команда из пятнадцати человек разрабатывает веб-приложение.У Василия приближается семейный праздник.
Он попросил начальника уйти пораньше, не проверив досконально работоспособность кода, запустил развертывание в командной строке и ушел с работы, заблокировав компьютер и при этом выключив телефон – семья важнее работы! В результате продакшен ломается, логи развертывания остаются на заблокированном компьютере, остальные разработчики рвут на себе волосы, пытаясь понять, что же было развернуто, что пошло не так в процессе развертывания и кто виноват. Если команда использует CI-систему, то все логи развертывания (и любые другие задачи) сохраняются в ней, поэтому вы всегда можете увидеть, что пошло не так.
С какой системы CI начать?
Хорошая подсказка для нас дает Github :
Проект с открытым исходным кодом на GitHub, скорее всего, запускает тесты в Travis CI. Вы не можете не столкнуться с этим.
Ок, учтем Travis CI, но не будем пока бежать в гугл и читать мануалы.
Давайте еще раз посмотрим на выводы недавнее исследование The Forrester Wave об инструментах непрерывной интеграции :
Вкратце, были рассмотрены текущие возможности CI-системы, потенциал развития и текущий размер рынка.
Для тех, кто интересуется методологией тестирования, прочтите само исследование.
Нас интересуют выводы.
Лидерами были: 4) ОблакоПчелы компания стоит за Дженкинс .
Это одна из старейших CI-систем с открытым исходным кодом, и было бы странно не увидеть ее в числе лидеров.
3) Круг CI уже во втором источнике он лидировал.
Так что это тоже заслуживает внимания.
2) Майкрософт - без комментариев.
Огромная компания с огромным влиянием.
Если вы разрабатываете программное обеспечение для Windows, то, скорее всего, у вас даже не будет выбора.
Если компания приобрела лицензии на стек инструментов разработки Microsoft с TFS и своей CI-системой, вы просто будете есть то, что они дают, особо не оглядываясь по сторонам.
1) GitLab в первую очередь.
Для тех, кто не следил за компанией последние несколько лет, это может стать полной неожиданностью.
Давайте поговорим о нем подробнее.
GitLab
Автор год работал в Gitlab в должности Developer Advocate, так что вы имеете полное право считать меня предвзятым и повысить регулятор скептицизма на пару десятков процентов при чтении следующих абзацев.Тем не менее, я считаю, что вам нужно многое знать о Gitlab, а еще лучше — начать им пользоваться.
Важно, что Gitlab отказался считать себя просто клоном Github, и компания решила развивать Gitlab в сторону «системы единого окна» для разработчика.
Gitlab уже способен заменить GitHub, Trello, CI-систему и так далее в списке.
Все инструменты уже настроены и интегрированы друг с другом.
Результат для разработчика — минимум возни с настройками.
Исходный код Gitlab открыт, и при желании вы можете бесплатно использовать его на своем сервере.
Но что нас сейчас больше всего интересует в этой истории, так это облачная версия — GitLab.com и возможности, которые это дает:
- Хостинг неограниченного количества частных проектов
- 2000 билд-минут в месяц для работы со встроенным CI бесплатно
Ну и возможность учиться, используя это для личных проектов, как следствие.
Короче говоря, вы уже догадались, что моя личная рекомендация GitLab CI .
У Gitlab есть все шансы стать следующим большим достижением в будущем.
А быть опытным специалистом в чем-то, что вдруг стало модным, значит быть востребованным специалистом ;) Если вы не готовы покинуть Github, попробуйте Круг CI или Трэвис К.
И.
.
На начальных этапах знакомства с CI избегайте Дженкинс И TeamCity .
Эти системы старой школы имеют слишком много накладных расходов, поэтому вам придется больше иметь дело с функциями систем, чем с самой CI. Вы начнете думать, что Дженкинс — CI, но это глупо.
Возможным исключением является то, что вы Javaист, Рокист или Котлинист, и у Вас все работает прямо из коробки.
Если вы рождены программировать для Windows, то мимо стека Microsoft вы точно не пройдете, но по доброй воле я бы им не пользовался.
Хорошо, идем дальше.
С каких задач начать
Хорошей новостью является то, что вам не обязательно сразу же становиться экспертом по CI. Для начала будет достаточно простого «оставаться в теме».Итак, начните с чего-нибудь легкого:
- Например, узнайте, как развернуть личный веб-сайт при отправке на главный.
- Врежьте это проверка орфографии с помощью Yaspeller для текстов на личном сайте
- Запуск небольшого рабочего проекта в 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 становится рабочая документация процесса непрерывной интеграции в команде.
Любой разработчик может что-то туда добавить или изменить, создав пул-реквест с нужными изменениями.
3) Наконец, система CI становится центральное место , в котором вы можете увидеть, где и когда что-то пошло не так во время развертывания или выполнения тестов.
Ну и добавьте на свой вкус все эти традиционные бла-бла-бла про ускорение процесса разработки, повышение надежности и снижение рисков.
Куда копать дальше
(если вы хотите изучить глубже) 1) Посмотрите скринкаст с примерами как развернуть на S3 и Heroku с помощью GitLab CI. 2) Читать введение в GitLab CI И руководство по развертыванию .3) Покурить документация .
4) После того, как вы освоитесь с одной CI-системой, выберите и поиграйте с любой другой из списка перспективных, чтобы убедиться, что принципы везде одинаковы, и обрести еще большую уверенность в своих силах.
Теги: #git #github #DevOps #тестирование #gitlab #системы контроля версий #ci #непрерывная интеграция #развертывание #системы сборки #рабочий процесс git
-
Стоит Ли Дублирование Dvd Ваших Денег?
19 Oct, 24 -
Химические Элементы
19 Oct, 24 -
«Единственный Человек, Вошедший В Дверь»
19 Oct, 24 -
Пол Грэм: Откуда Вы Знаете
19 Oct, 24
