Почему вам нельзя строить Continuous Integration (еще или уже?)
Многие из вас последнее время слышат многое про такие популярные штуки, как Continuous Delivery и Service Discovery. Несколько лет назад такой шум стоял от Continuous Integration и System Configuration Management. “У нас в штате нет админов, только devops” — все это слышали, и про DevOps шум стоит до сих пор.
Когда не сильно искушенный в этих материях человек пытается с этим разобраться, он идет на специализированные издания и читает статьи. По мере прочтения непонятного становится все больше и больше.
За деревьями теряется лес, все вокруг общаются на непонятном птичьем языке, и если смысл отдельных понятий или назначение инструментов ухватить получается, то как этим пользоваться не понимаешь вообще.
Более того, часто бывает другой негативный сценарий: поддавшись искушению ты начинаешь внедрять какой-то из buzzword’ов, мгновенно напарываешься на интеграционные проблемы, начинаешь задавать вопросы “как?” и тебе в ответ объясняют, что ты просто неправильно все понял, и кроме buzzword’а X, тебе нужно внедрить еще Y и Z, и обязательно A и C, а вот B брать не нужно, потому что он сырой.
Я видел это многократно в разных ситуациях, в роли этих X были fleet, continuous integration, continuous delivery, docker, CoreOS, облака, devops, service discovery, terraform, еще куча других слов.
Ключевая проблема всех подобных статьей и обзоров: они говорят что делать, но не говорят зачем.
“Мы внедрили Continous Integration” или “У нас используется Service Discovery” или “У нас DevOps вместо админов”. Для непосвященного человека все это звучит как “сепульки” из романа Лема.
В таких случаях я всегда задаю ровно один вопрос желающим внедрять: “Какую проблему вы хотели бы решить при помощи X?” и другой вопрос адептам X: “Какую задачу вы решали при помощи X?”.
Удивительно, но этот простой вопрос вызывает непонимание, удивление, сомнение в моих компетенциях или даже агрессию. “Ну, очевидно же”… и дальше идет поток этих самых buzzword’ов.
Я не претендую ни в коей мере на истину в последней инстанции, но я хотел бы вставить свои пару копеек, не по поводу всего выше перечисленного, а лишь на примере Continous Integration.
Один мой знакомый, владелец хостинг-провайдера, почитав статьи решил предоставлять своим клиентам CI. Прочитав это, я схватился за голову, и полчаса пытался понять, как же ему объяснить, что CI он вообще про другое. Я попытался найти статью, которая бы описала цель CI, как оно внедряется, зачем оно нужно. Безрезультатно — огромное количество статьей про то, какой классный CircleCI или Jenkins, но ни одной про процессы разработки команды.
Видимо, мне придется попытаться закрыть этот пробел, ни в коем случае не претендуя на корректность. С другой стороны, у меня есть некоторые основания полагать, что мое мнение будет интересно — в том или ином виде процессы разработки, тестирования, release management, continuous integration, continuous delivery и администрирования я сопровождал и разрабатывал в разных компаниях последние десять лет.
CI или CD, про которые вы читаете, которые обещают стабилизацию разработки, быструю доставку изменений заказчику или на production, автоматическое тестирование и все прочие манящие слух штуки является, в некотором смысле слова, финалом, конечной вишенкой на огромной горе, в которую вложить нужно часто чудовищное количество сил.



Начинать нужно не с верхушки, а с фундамента, и слой за слоем перестраивать собственные процессы разработки, на каждом этапе получая результат, которые начинает приносить пользу, и лишь в самом-самом конце вы получаете тот самый CI из рекламных проспектов.
В самом низу, в основании пирамиды, лежит… система учета задач. Если у вас нету формального или, хотя бы, полуформального способа оформления задач для разработчиков, никакого CI у вас не получится. Неважно, что вы используете — JIRA, wrike, Redmine, Trello или любой другой инструмент — важно, что такая система учета задач была. Иначе что же будет проверять или деплоить ваша CI или CD? “Я работал неделю и что-то сделал”? И какой тогда в ней смысл?
Одной системы задач недостаточно, важен еще и рабочий процесс — регламент работы с этой системой задач со стороны всех заинтересованных ролей — разработчиков, менеджеров, владельцев бизнеса, продуктовых менеджеров. Неважно, есть ли у вас команде такие должности, важно, что кто-то эти роли выполняет. Для каждой роли должен быть workflow, регламент по которому задачи ставятся, планируются, выполняются, тестируются и закрываются.
Нет рабочего процесса по работе с задачами — никакого CI у вас не будет никогда.
Следующим уровнем идет workflow по работе с системой контроля версий. Да-да, вы не ослышались — если у ваших разработчиков нету регламента работы с git’ом, то никакого CI у вас не получится.
Регламент — это небольшая инструкция, обычно из пяти-шести пунктов, которая описывает (все указанное, но не ограничиваясь им):
- Формат commit message
- Связь commit message с задачи в вашей системе учета задач
- Именование веток
- Порядок работы с ветками
Это очень-очень сжато, но на тему git workflow, например, сломано немало копий, и тут нужно смотреть строго по месту, какой именно workflow хорошо зайдет в вашу команду. Это сильно зависит от числа людей, их квалификации, стека технологий (как ни странно) и сложившейся культуры разработки. Важно другое, чтобы такой workflow был, был описан, принимался всеми разработчиками как необходимое зло, и по большей части — соблюдался.
Эти два пункта, зачастую, требует иногда несколько месяцев активной работы всех членов компании, чтобы начать работать как должно.
Их внедрение само по себе уже, зачастую, дает тот самый прирост производительности всей компании, и, что часто важнее, улучшает предсказуемость разработки тех или иных частей вашего продукта.
Если вы разобрались с задачами (“что будет делать”) и системой контроля (“куда сохранить сделанное”) можно переходить к следующему пункту (“как проверить сделанное”).
Я не могу не напомнить еще раз, что помимо технической приемки задачи, есть еще приемка продуктовая — читайте выше пункт первый про задачи. Кто-то обязательно должен проверять, что сделано именно то, что нужно было сделать, а не что-то другое, похожее на нужное. Этот вопрос, опять же, за пределами данной статьи, но не упомянуть про него я не мог.
Перейдем к технической приемке. Допустим, процессы у нас работают, работа с задачами ведется по workflow, работа с git’ом идет тоже по workflow. На этом этапе вы обнаружите такую штуку как возврат к задачам для исправления ошибок.
Другими словами, работа ведется, но вас не устраивает качество получившегося результата.
На этом этапе, нет, никакого CI еще нет! мы переходим к тестированию — ручному либо автоматическому.
Тестирование — это процесс проверки проделанной работы с точки зрения корректности работы, как в основном сценарии, так и в различных граничных случаях.
Простейший вид теста выглядит так: “проект собирается”. Простейший тест, но который отлавливает кучу проблем и экономит кучу времени.
Дальше начинаются другие buzzword’ы, такие как юнит-тестирование, функциональное тестирование, регрессионное тестирование , smoke тестирование. Неважно, что именно они означают, важно что они делают — они проверяют соответствие вашего продукта, какой-то определенной версии определенным требованиям, оформленными в виде тестов.
И вот только на этом этапе, когда у вас последовательно решены вопросы что делаем (задачи), куда сохраняем результат (система контроля версий), как проверяем результат (тесты) идет Continuous Integration — автоматический прогон тестов при фиксации изменений в репозитории исходного кода.
И вот только после построения этого базового процесса у вас идут все последующие buzzword’ы — Continous Delivery, Service Discovery, которые являются на самом деле частью процессов Release Management и System Administration.
Самое главное, чтобы я бы хотел, чтобы вы вынесли из статьи — важны не инструменты и даже не конкретные технологии.
Важны рабочие процессы, те правила игры, по которым работает ваша команда. Инструменты поменять легко, во всяком случае, легче, чем команду и правила игры в ней.
