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

1. Continuous Integration with TeamCity Pavel Sher JetBrains, Inc.

2. Что такое Continuous Integration? Практика программирования Preconditions: хранение исходных кодов в репозитории и автоматизация сборки проекта Минимальные требования к Continuous integration tool – вытаскивать исходный код и запускать сборку проекта Современные системы дают гораздо больше, нет смысла изобретать велосипед

3. В двух словах о TeamCity J2EE приложение, центральный сервер с веб интерфейсом, вся информация о билдах в одном месте Сборки / билды запускаются на агентах – как правило отдельные машины

4. Чем TeamCity отличаемся от других ? Есть бесплатная версия Внимание к деталям, удобство интерфейса Developer-oriented Наличие ряда уникальных возможностей Расширяемость, с помощью плагинов ( Java API )

5. Проблемы и решения Долгие билды Плохой код в репозитории Тесты никто не чинит Качество кода деградирует

6. Долгие билды Для многих долгие билды это объективная реальность Универсального решения нет, но, кое-что можно сделать : Показать текущую стадию билда, прошедшие, упавшие тесты Разрезать билд на части и запускать их параллельно (агенты) Тестировать одновременно в разных окружениях (опять же агенты) Попросить сервер запускать ранее падавшие тесты перед остальными

8. Не компилируемый код в репозитории Закоммитились не все файлы, локальный ребилд пересобрал не всё, не сделали апдейт перед чекином, и т.п. Решение – персональные билды Опциональный автокоммит при успешном прохождении билда Ваши персональные билды ни на что не влияют и никому не мешают

9. Тест никто не чинит Тесты падают уже давно, похоже никто не собирается их чинить , непонятно в какой момент они сломались Решение : First failed in , а также история коммитов помогут установить, кто виноват Назначьте ответственного, он получит нотификацию прямо в IDE , остальные будут видеть, что падением теста занимаются

11. Качество кода ухудшается Объём кода растёт, и вы чувствуете что теряете контроль над ситуацией Решение : регулярные билды, собирающие метрики Duplicate code analysis Inspections Coverage Показ inspections & duplicates прямо во время редактирования кода в IDE

13. Другие возможности : Определение зависших билдов + нотификации Распознование ошибок компиляции Трекинг новых упавших тестов (не падавших в предыдущих билдах) Интеграция с issue trackers Статус коммитов – какие тесты, билды сломались, после этого чекина Исторические билды Зависимости Чекаут исходного кода билда из разных репозиториев (в том числе разного типа) И многое другое

14. Pavel Sher < [email_address] > Спасибо!