Что будет после Agile? Непрерывная интеграция…

Как и Agile, CI не нова — ей исполнилось уже 26 лет. За это время подход успел себя хорошо зарекомендовать, и сейчас крупные компании все чаще обращаются к нему. Один из последних примеров внедрения этого набора практик и принципов в России — вездесущий Сбербанк. Из опубликованной документации следует, что банк планирует внести изменения в часть подпроцессов непрерывной сборки, развертывания и поставки (Continuous Integration, Delivery и Deployment). За консультационные услуги соответствующих специалистов в банке готовы выложить 35,98 млн рублей.

Семь составляющих непрерывной интеграции

Continuous Integration порой относят к agile-практикам. Но если в Agile во главу угла ставят изменение мышления и практики (за которыми идут организационные изменения), то CI — это в первую очередь автоматизация процессов, которая позволяет избежать многократного выполнения рутинных операций. Проще говоря, непрерывная интеграция — это практика частых сборок кода в сочетании с его инспекцией и постоянным тестированием. И поскольку вручную все это делать сложно, процесс максимально автоматизирован. Главный плюс описанных ниже инструментов — все это можно сделать бесплатно, потратив только время разработчиков на организацию и автоматизацию процесса.

Единый репозиторий исходного кода

Репозиторий необходим, чтобы снизить риски потери контроля над развитием кода или даже потери самого кода. Когда над проектом трудятся несколько разработчиков, и каждый из них хранит код по-своему (неважно, что это — ноутбук, файловый сервер или личная система контроля версий git), велика вероятность, что какой-то фрагмент будет потерян. Нельзя исключать конфликтов при интеграции кода разными разработчиками — тогда понадобится организовать резервное копирование. Кроме того, единый для проекта репозиторий позволяет удобно организовать в проекте процесс Code Review (рецензирование кода) и в случае ошибки позволяют откатиться обратно, до работающей версии. Самой популярной системой контроля версий сейчас считается Git.

Как это работает

Сейчас единый репозитарий кода — это стандарт, своего рода константа при разработке. В «Инфосистемах Джет» его используют в обязательном порядке на всех проектах. К примеру, над системой управления инцидентами информационной безопасности Jet Signal работают порядка 10 человек, и весь проект ведется в централизованном репозитарии.

Преимущества

• Вся команда получает единую входную точку.
• Проще контролировать версии.
• Есть возможность получить список отличий между двумя версиями.
• К коду получает доступ вся команда.
• Проще посчитать вклад каждого.
• Можно посмотреть историю изменений.
• Код можно разбивать на ветки.

Инструменты

Subversion, Git, TFS, Perforce, ClearCase.

Автоматизированный процесс сборки

Преобразование исходного кода в исполняемые файлы (они же – «артефакты») не всегда проходит просто. И чтобы превратить исходники в работающую систему, нужно компилировать, постоянно перемещать файлы и загружать схемы в базы данных. Конечно, человек может делать все, но есть несколько причин, почему это лучше поручить роботам.

Как это работает

Де-факто автоматизация сборки у нас используется на всех проектах. Взять тот же Jet Signal или Jet Toolbar, предназначенный для организации канала обратной связи оператора и абонента услуг передачи данных. Всегда есть сервер, который автоматически собирает написанный код и сохраняет результат так, чтобы его мог найти любой член команды. Приведем пример: предположим, что тестировщик, чтобы что-то протестировать, идет к разработчику и просит собрать код. Если таких сборок 5 в день (а это нормальный показатель) — это уже 100 потраченных минут, причем только между одной парой «тестировщик–разработчик». Если в команде собраны 5 разработчиков и 5 тестировщиков, это уже 500 минут или 1 человеко-день, которые можно сэкономить, просто настроив автоматическую сборку.

Преимущества

• Нивелируются человеческие ошибки при сборе системы.
• Растет взаимозаменяемость — любой разработчик или тестировщик может развернуть систему.
• Не нужно заниматься ручным развертыванием системы, больше времени для разработки.
• Упрощается перенос системы в новую тестовую среду.
• Растет качество продукта, потому что не нужно ждать окончания разработки, чтобы убрать баги и внести изменения в функционал.

Инструменты

TFS Build, Maven, Graddle, Ant.

Автоматизация тестирования сборки

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

Как это работает

Не вдаваясь в детали, мы подсчитали, что при разработке Jet Signal автоматические тесты сохраняют нам примерно столько же, сколько и автоматизированная сборка — 1 человеко-день ежедневно. Главное, что нужно помнить: если вы разработали автотест, им нужно пользоваться постоянно. Нет, заменить автотестами всех тестировщиков не получится — иногда дешевле и быстрее работать с людьми, чем тратить время и автоматизировать этот процесс.

Преимущества

• Автотесты могут выполняться 24/7, они значительно дешевле.
• Скорость намного выше ручного тестирования.
• Они надежнее, потому что нельзя забыть или намеренно пропустить какой-то тест.
• Снижаются человеческие и технические риски, нет угрозы попасть в зависимость от команды разработки и тестирования.
• Автотест позволяет обойти ограничения пользовательского интерфейса.

Запуск на интеграционном сервере

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

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

Как это работает

Все последние проекты «Инфосистемы Джет» сейчас запускаются с пониманием необходимости этого подхода. К примеру, интеграционный сервер очень помогает в работе команде, которая трудится над системой обнаружения вторжений «Плутон». Если бы они каждый раз брали сборку, установленную на машине конкретного разработчика, это принесло бы немало проблем: не та конфигурация, не хватает пунктов в инструкции по установке, не так настраивается. И так для каждого разработчика, а их там пятеро. Интеграционный сервер избавляет от хаоса, связанного с пятью разными сборками.

Преимущества

• Проще интегрировать различные части проекта.
• Снижается риск, связанный с конфигурацией программного и аппаратного обеспечения у членов команды.

Инструменты

Jenkins, TeamCity, TFS, Travis CI, Circle CI.

Тестирование в клоне рабочей среды

Основная идея в том, чтобы проводить тестирование и развертывание продукта в среде, аналогичной продуктивной, чтобы не тратить время на выяснение конфигурационных проблем. Эти проблемы можно будет найти уже во время тестирования. Есть и ограничения: если разрабатывать десктопное приложение, не будет финансовой возможность повторить все многообразие конфигураций. Но все, что касается серверной части, решается в рамках этой практики. К тому же можно сократить затраты, построив виртуальную многомашинную среду для тестирования и имитации различных окружений.

Как это работает

Одна из самых малораспространенных практик CI, потому что не каждый заказчик готов описать конфигурацию его серверов, есть только абстрактные схемы. К тому же этот инструмент сложно применять в банкинге, потому что там, чтобы создать клон рабочей среды, нужны настоящие данные пользователей банка. А они вряд ли на это согласятся. Клон рабочей среды точно планируют использовать в разработке «Плутона» и применяли при внедрении решения для одного из сотовых операторов (конкретный кейс заказчик просил не разглашать). И потом это сильно упростило нам работу по внедрению.

Преимущества

• Позволяет предупредить ошибки продукта, которые могут возникнуть в связи с особенностями окружения.

Доступность сборки для всей команды

Каждый раз в процессе разработки, когда нужно убедиться в работоспособности ПО, необходимо запустить приложение и проверить его. При этом важно, чтобы каждый член команды в любой момент мог посмотреть на это программное обеспечение и проверить его. Поэтому должно быть единое, удобное хранилище со стабильными сборками. А все участники проекта должны знать, как попасть в это хранилище и как с ним работать.

Как это работает

Все очень просто: если вы сделали все предыдущие шаги (интеграционный сервер, автоматизация сборки), этот процесс у вас будет работать в обязательном порядке. Если у вас есть интеграционный сервер, который сам делает сборки и выкладывает их, теперь все тестировщики знают, куда зайти, чтобы взять последнюю версию сборки. Так устроена, например, разработка Jet Signal.

Преимущества

• Обеспечивает стабильность и высокую надежность системы.
• Минимизирует затраты на управление и хранение исполняемых файлов в разных средах — файловая система хранит только одну копию любого двоичного файла.
• Контроль доступа и история изменений помогают отследить, кто и какие изменения вносил в систему.
• Доступ к артефактам есть у всех участников процесса разработки.
• Обеспечивает расширенное управление каждым этапом: загрузкой, развертыванием, перемещением, копированием.

Инструменты

Nexus, Artifactory, TFS Build, Archiva, ProGet.

Автоматизированное развертывание целевого решения

В процессе разработки и использования программного обеспечения требуется несколько сред: тестовая, разработчиков, продуктивная. И вместо того чтобы тратить время на ручное развертывание при обновлении, есть смысл автоматизировать этот процесс. Причем разработчики охотно автоматизируют развертывание, когда из решение занимает условные 50 серверов. Но когда их меньше 10, люди не вкладываются в автоматизацию, хотя даже при таком количестве это имеет смысл.

Как это работает

В Jet Toolbar развернули автоматическое развертывание решения и подсчитали, что автоматизация сократила этот процесс с 4 часов до 10 минут.

Преимущества

• Автоматизированная сборка более устойчива к появлению ошибок и проще в тиражировании.
• Собрать ее может любой человек из команды.
• Разработчики больше времени занимаются непосредственно разработкой.
• Установить сборку на новый стенд несложно, достаточно изменить имя машины.
• Появляется возможность выпускаться чаще.

Инструменты

Nexus, Artifactory, TFS Build, Archiva, ProGet.