DevOps best practices: рекомендации по организации конфигураций в TeamCity

DevOps (Development + Operations)

Принимая участие в разработке нескольких сотен сборочных, деплойных и иных автоматических конфигураций для поддержки процессов разработки ПО, рано или поздно начинаешь находить в них и выделять общие решения, концепцию, архитектуру, схему взаимодействия конфигураций между собой. Предлагаю вам некоторые рекомендации в области разработки конфигураций, подходы и схему организации процессов сборки и тестирования ПО. Эти подходы были успешно опробованы мной и моими коллегами: Александром Паздниковым, Ярославом Акимовым и Алексеем Соловьёвым, для большого числа IT-проектов, на базе системы непрерывной интеграции TeamCity.

Частично вопросы организации процессов сборки и тестирования уже были рассмотрены в статье "TeamCity triggers & dependencies: построение процессов разработки и тестирования". В статье ниже приведена терминология основных понятий, используемых при описании конфигураций, рекомендуемый набор конфигураций для произвольного проекта, а также схема взаимодействия конфигураций для релизных и нерелизных сборок, деплоя, функционального тестирования. 

TeamCity TestRuns on Rails: распараллеливаем тест-раны и агрегируем статистику

В автоматизации тестирования часто требуется распараллелить запуск тестовых сьюитов и при этом собрать общую статистику в едином отчете по тест-рану. Можно решить эту задачу, создав собственный парсер результатов прогона каждого тест-сьюита, а можно воспользоваться механизмом зависимых конфигураций в TeamCity, о которых было написано в статье "TeamCity triggers & dependencies: построение процессов разработки и тестирования". Суть этого подхода проста: нужно добавить в TeamCity конфигурации для запуска отдельных тест-сьюитов, а также конфигурацию для основного тест-раннера, который будет запускать сьюиты и агрегировать их результаты используя механизм зависимых конфигураций.

TeamCity triggers & dependencies: построение процессов разработки и тестирования

В процессах разработки и тестирования программного обеспечения всегда можно выделить отдельные подпроцессы:

• сборку или компиляцию (building, compilation) программных модулей из исходных кодов,
• модульное unit-тестирование,
• подготовку дистрибутивного пакета из собранных модулей,
• тестирование сборки (Build Verification Testing),
• сохранение дистрибутива в некоторой системе репозиториев,
• проверка основной функциональности при помощи smoke-тестирования,
• прочие виды тестирования: функциональное, интеграционное, стресс-тестирование, UI-тестирование, тестирование инсталляции, удобства использования, и т.д., которые также можно выделить в отдельные подпроцессы.

Каждый из подпроцессов обычно стремятся автоматизировать, связать друг с другом в единый процесс, непрерывный и зависящий от результатов каждого подпроцессв. В системе интеграции TeamCity, кроме непосредственно разработки конфигураций для автоматизации чего-либо, возможно организовать такие взаимосвязанные процессы. Для этого в ней предусмотрены механизмы триггеров (triggers) и зависимостей (dependencies) конфигураций. Рассмотрим их использование на примере двух разнонаправленных процессов: подготовки дистрибутива (I) и его тестирования (II).

Мета-раннеры в TeamCity

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

Мета-раннер (TeamCity Meta-Runners) - это "раннер в раннере", это инструмент, который позволяет выделить из отдельных билд-конфигураций общие повторяющиеся действия и перенести их на уровень выше. Мета-раннеры позволяют использовать шаги одной билд-конфигурации в других билд-конфигурациях целиком, как отдельный параметризуемый шаг. Если шаблон конфигурации можно сравнить с параметризованной функцией в программировании, то мета-раннер - это класс, в понятиях ООП.

Использование TeamCity в качестве системы управления запуском функциональных авто-тестов

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

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

Аутентификация в Linux с помощью ключевой пары

Задача: требуется аутентифицировать машину Клиента (user: client_username, host: client_host) на машине Сервера (remote user: server_username, host: server_host). 

Решение: