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

DevOps (Development + Operations)

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

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

Подходы к автоматизации процесса валидации уязвимостей, найденных автоматическими сканерами безопасности, при помощи нечётких множеств и нейронных сетей

Attention! По ссылке ниже ещё больше букв, чем в названии. А ещё много формул :-)

http://math-n-algo.blogspot.ru/2014/08/FuzzyClassificator.html

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

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

Опубликовано:
Гильмуллин Т.М., Гильмуллин М.Ф. Подходы к автоматизации процесса валидации уязвимостей, найденных автоматическими сканерами безопасности, при помощи нечётких множеств и нейронных сетей // Фундаментальные исследования. – 2014. – № 11 (часть 2). – стр. 266-279;
URL: www.rae.ru/fs/?section=content&op=show_article&article_id=10004779

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 для превращения любого вашего скрипта, написанного на любом языке, в результаты теста – не требует никакого изменения логики вашей системы для функционального автотестирования.

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