Все о SCRUM. Изучение, разработка, интеграция

В результате компиляции и объединения всех компонентов получается сборка, используемая для прохождения тестов и получения обратной связи от Владельца продукта. С точки зрения Scrum, эта сборка соответствует микро-инкременту, который к концу спринта станет инкрементом для показа во время обзора.

• Процесс

При каждом коммите разработчика инструмент на сервере интеграции (например, Jenkins или Travis) инициирует цепочку действий [58]. Цепочка обычно следующая:

✓ Компиляция и проверка.

✓ Запуск модульных тестов.

✓ Запуск тестов интеграции и приемочных тестов.

✓ Запуск инструмента, который проверяет синтаксис и корректность кода (например, Linter).

✓ Запуск инструмента, который проверяет качество кода (например, Sonar).

✓ Составление отчета.

✓ Подготовка версии ПО, готовой к использованию.

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

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

Чтобы быстро устранить причину поломки, нужно запустить отладчик.

• Когда следует начать?

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

Команда должна обсудить важность этого подхода с Владельцем продукта, объяснить его преимущества – в частности, более быстрое получение обратной связи. Хороший Владелец продукта обязательно согласится.

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

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

• Непрерывное развертывание

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

Такой ввод в эксплуатацию позволяет получить обратную связь еще быстрее и пройти тесты в более представительной среде.

Чтобы больше об этом узнать, можно обратиться к [Саке, DevOps].

19.1.2 Разработка через тестирование

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

Практика разработки через тестирование [Бек, TDD] идет дальше: сначала пишется модульный тест и уже затем – код, достаточный для его прохождения. Такой подход существенно снижает риски при написании кода.

Разработка через тестирование включает рефакторинг.

• Сначала тест

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

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

Она способствует быстрому проектированию и хорошему знанию кода разработчиками. По сути, это форма неявной документации.

• Рефакторинг

Рефакторинг – это процесс улучшения кода без изменения его поведения. Улучшение качества достигается за счет упрощения и оптимизации текущего решения: команда убирает дублирование кода и делает его более простым и легким для восприятия. И, следовательно, для поддержания.

После каждого изменения необходимо снова проводить тесты, чтобы убедиться: поведение кода осталось прежним. Рефакторинг может выполняться без предварительной разработки тестов, но именно в объединении этих процессов в одну формулу состоит принцип разработки через тестирование.

TDD = Написание теста в первую очередь + рефакторинг.

Внимание: помимо общего кода, это относится и к коду теста.

Рисунок 19.1 – Практика разработки через тестирование

• Когда следует начать?

Для нового ПО – чтобы избежать технического долга