Кроме внутренних семинаров и встреч Apple-разработчиков мы помогаем организовывать семинары SPB SQA Group — сообществу тестировщиков Санкт-Петербурга.

На одном из таких семинаров Олег Ладыгин рассказал о своем опыте создания системы управления.

презентация

Меня зовут Олег Ладыгин, последние пять лет я работаю в компании «Петер-Сервис». Это большая компания, 800 человек, программное обеспечение для биллинга и телекоммуникаций. Я – разработчик, изначально туда приходил разрабатывать автоматические тесты для тестирования нагруженных серверов, всякие Сишные приложения, базы данных, ОРАКЛ и довольно быстро, через полгода, столкнулся с такой проблемой: тесты написать – это… Ну какой человек нормально может написать тест? Программисты могут написать даже хороший код иногда. Это уже очень хорошо. Что с ним делать дальше – непонятно. Т.е. состояние программного обеспечения, состояние сборки - в какой момент она готова, что там реализовано, что не реализовано, какие багги сейчас проверяет тестировщик? Если написан какой-то тест, то он через два месяца теряется. И если он падает, то непонятно, почему он падает? Может быть, это так и надо? Может быть, о нем забыли, его не запустили? Получается, что программное обеспечение – вещь сама в себе, а тесты – сами по себе. И все манипуляции между ними – ручные. Меня это дело очень сильно расстроило, потому что я люблю стройность, чтобы все было хорошо и понятно.

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

Чтобы не заниматься ерундой, я поставил себе три вопроса:

• Кто этим будет пользоваться?
• С чем он уже работает?
• Что можно улучшить, если что-то можно улучшить?

Кто этим будет пользоваться – понятно. В первую очередь, это – разработка и тестирование. Сразу сделаем маленький задел на управление и руководство. Потому что такие хорошие люди как менеджер проекта, какой-нибудь тест-менеджер – они часто спрашивают, раз в два дня, каждую пятницу: «Что у вас сделано, уходят ли у вас куда-то сроки?». У меня на подготовку такого отчета уходило полдня. Это мне очень не нравилось, хотелось как-то оптимизировать.

С чем люди уже работают? Я расскажу о нашей компании. В первую очередь, это разработка программного обеспечения – много платформ (Windows, Solaris, Linux, Mac, Android и т.д.), плюс веб-приложения, PHP, Python, собственные разрабтки и много-много баз данных (например, до полутора тысяч систем на Oracle, которые объединены в 300-400 проектов). И некое хранилище рабочих заданий, где я объявлял: нужно разработать версию 126 такой-то подсистемы – задание такое-то, нужно такие-то багги закрыть, такие-то импрувенты на реализацию тоже закрыть; срок – две недели, тестирование – две недели. И это все, в общем –то разные продукты, они ничем не были соединены. Разные люди работали одновременно со всем. Разработчик получал задание в одном продукте, писал код в другом, после чего начинал собирать эти подсистемы вручную. Вручную нужно было скомпилировать какой-то сервер на шести платформах, время компиляции – час. Соответственно, исходных файлов – 400-500 штук, их нужно залить в каку-то папку (при этом не ошибиться, в какую), взять какие-то результаты, запаковать их в архив. Половина времени уходит только на сборку. Причем никакой ночной сборки, никаких стабильных сборок – вообще ничего. Такая каша была пять лет назад.

Какую часть можно было улучшить?

1. Сборки нужно было сделать быстро и автоматически.

2. Должно быть все прозрачно. Я должен знать – где дистрибутировать, когда дистрибутировать, даты всякие, какие багги –всю эту информацию нужно было свести в одну большую кучу.

3. Дальше самое интересное – тесты. Тесты нужно было не терять, нужно было знать, что они собой представляют, всякие текстовые документы с описанием – это не вариант, они не поддаются никакой автоматической обработке. Люди просто сидят и тратят время на их чтение. Тесты нужно было привязывать к версиям, к интервалу версии, делать разнообразные записки, бумажки, стикеры клеить на монитор: «Этот тест работает для всех версий, кроме 50-й, а так вообще для всех». А потом: «А, нет, для 40-й версии лучше использовать другой тест». Нужно было не забывать запускать. Запускать тесты вручную – это нереально. Потому что маленькими функциональными тестами еще можно как-то тестирование провести. А когда идет нагрузка, это нужно было оставлять, к примеру, на сутки. Базу нужно было быстро поднять, от заказчика кусок анонимный – все там проверить, потом склеить какие-то результаты – все это работает сутки-двое. И естественно, в пятницу вечером все это запускается. В понедельник утром приходишь, думаешь, сейчас все будут результаты отличные, потом сдадим… Начинаешь читать логи – через 15 минут сервер выключился. Ну выключился сервер, упал – электричество прыгнуло, все что угодно. Серверов есть несколько, но их тоже не перезапустишь. Это все должно было автоматически перезапуститься. Вот это та область, которой я изначально стал заниматься.

Кратко уточню слова, которые буду употреблять.

Что такое дистрибутив — для меня это было множество «динамиков», они все вложены в архив, рядом лежит файл, где описано: что это за дистрибутив, как его нужно инсталлировать, какие у него системные требования, какие там реализованы пожелания. Это конечный продукт, который должен быть поставлен заказчику. Он выгружается, уходит на лазерный диск, по почте, куда угодно.

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

Сборка. Сборка – это мы взяли исходный код и выполнили над ним некоторые преобразования. В итоге получили какие-то результирующие файлы – ЕХЕ-шники. По поводу сборки – такой момент: нужно отличать сборку и исходный код – с одной стороны они отличаются, а с другой стороны – это одно и то же. Т.е. нельзя сказать, что у меня есть в системе управления какой-то текст, я из него сейчас получу какой-нибудь ЕХЕ-шник, и это вытекает одно из другого. Это неправда. Компиляция идет три часа, сервер занят, поэтому она была запущена вечером, за это время разработчик что-то внес, параллельно разрабатывается несколько версий, между ними должно быть четкое соответствие. Иначе получим очень много ошибок. Потому что последняя сборка никогда не проверяется тестировщиками. Собраны все платформы, все везде заверено, все скомпилировано. А за это время исходный код поменялся. Есть тысячи причин, по которым он мог поменяться. Эти файлы оказались разными. Неизвестно, что проверял тестировщик и когда. От этого нужно было избавиться обязательно.

Что такое стабильная сборка? Это некий дистрибутив, или просто ЕХЕ-шник, который был подвергнут тестам – успешным, неуспешным – все равно. Мы запустили 50 тестов именно на этом файле, не на исходном коде. Должно быть записано: именно этот файл протестирован таким-то тестом с таким результатом. Если никто не менял исходный код, получили этот файл заново – это уже другое, это может быть все, что угодно, но это не та стабильная сборка, о которой мы говорим. Особенно для многоплатформенных приложений. Потому что для многоплатформенных это можно было в итоге делать только одним образом: взяли все исходные файлы, запихнули их в архив, архив сохранили, этот архив распихали по всем серверам, там распаковали, запустили, собрали. И внимательно смотрим, чтобы никто в этот процесс не вмешивался. Тогда есть хоть какая-то гарантия, что мы поставляем именно то, что тестировали.

Тест и тип теста. Тесты – это что-то. Для меня это всегда была просто какая-то команда с какими-то данными, файлами, которые можно было «натравить» на дистрибутив, на файл, на инсталлированную где-то систему, на готовый веб, где угодно. Которая производит неизвестные мне действия, но на выходе есть результат. Т.е. для меня тест – это маленькая черная коробочка, но на выходе есть результат. Причем каждый результат должен быть в таком виде: что тестируется, подробное описание того, что там на самом деле было, интервал версий, для которых это валидно, интервал значений, которые получены в результате этого теста – тест получает значение 15, интервал валидности этого значения – 10-20 – это хорошо, все остальное плохо. Типы теста – функциональные, регрессионные, нагрузочные. Это разделение всегда условно. Я их разделял специально. Потому что нагрузочное тестирование нужно проводить в особо хороших условиях. Желательно это делать по выходным на выделенных серверах, это занимает большое время, нужны стабильные системы. Делать это нужно иногда, и на результаты нагрузочного тестирования смотреть нужно редко. И делать это нужно всегда. Идет несколько версий – полгода делается. Например, пять версий выпустили, каждый месяц выпускали – все хорошо. В какой-то момент узнали – оказывается, два месяца назад у нас был порог производительности 15%. Почему? Мы должны поднять результаты двухмесячной давности, увидеть, на какой сборке это произошло, в какую неделю; поднять, кто это делал, что он писал, и тогда мы сможем где-то за час-два сказать, что вот эту функцию добавили, а потом, когда начали ее использовать, то там все «поехало». Если этой информации нет – все, эта разработка уходит в никуда.

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

Регулярная сборка и тестирование. Исходный код нужно собирать и тестировать как можно чаще, желательно каждую ночь. Потому что серверы все равно электричества потребляют очень мало, а платит за это кто-нибудь другой, а бывает так, что сборка в какой-то момент вдруг не собирается. Собарается-собирается-собирается-не собирается. Тесты 20 раз прошли, 1 раз была ошибка. Плавающие ошибки – самое серьезное дело, статистика нужна, все должно тестироваться постоянно. Человек никогда этого не сможет сделать. Должна быть система, которая всем управляет. Сразу возникает вопрос –

Ресурсы. Ресурсы — это не только люди. Это серверы, платформы, базы данных, исходные данные для тестов, база с кусочком каких-то данных, по которым проводится тестирование, база маленьких ошибок – это все ресурсы.

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

Серверы и платформы. Платформа — это Windows 2003, к примеру. На ней у нас есть 3-4 сервера. Они все одинаковые, мы можем между этими серверами свободно перемещать задания, компилироваться то там, то там; тесты запускать то там, то там, они все равно ломаются, уходят на плановое обслуживание, но серверы все равно остаются. Вторая платформа – Windows 2008, один сервер. Но в нее же мы можем запихнуть один из серверов Windows 2003, потому что там будут такие вещи делаться, что нам без разницы. То есть, серверы и платформы они соотносятся.

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

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

Тестирование: нужно взять сам тест – это какие-то файлы – взять дистрибутив – тот, который собрали; не какую-то промежуточную сборку на компьютере у соседа-программиста, нет – именно ту коробочку нужно взять – ее нужно принести к себе, распаковать аккуратно, ничего не перепутать, оттуда вытащить программу, нужно это не полениться поставить. После этого нужно подготовить тестовую среду – все привести в исходное состояние, ничего не забыть, переменные окружения выставить какие-то идентичные, которые угодны заказчику, запустить сам тест. Получив какие-то результаты, их нужно сохранить. Получили набор значений: 50, 50, 40, нет, crash, dump. Все это нужно сохранить. Нужно всем об этом рассказать. Сразу, не сразу, но эта информация должна быть доступна в любой момент кому угодно. Разработчик должен зайти куда-нибудь, у него должно где-то что-то сверкнуть – тест прошел/тест не прошел – он должен знать об этом. Багги закрыть/создать, может быть к ним дописать что-нибудь еще. Для меня это был процесс самый трудоемкий. Система должна работать так: багу нашли – ок, такая бага есть – ок, записываем ноту – повторилась. Бага не повторилась – закрываем. Опять повторилась – переоткрываем, добавляем ноту, что повторно эта бага. Проверяем – нам разработчик говорил или нет, что он эту багу исправлял? Если исправил – то это так работает, если не исправлял – то пока игнорируем, просто складываем результаты. Это должен быть автоматический процесс, потому что очень умные люди план делают очень хорошо – через них можно проверить качество. Но порой они говорили – давайте мерить багги, искать сходимость ошибок, разные строить вещи. Сейчас мы нашли 100 багов, завтра мы нашли 90, 80. Вот когда мы найдем 10, тогда мы можем смело говорить, что заказчик ничего не найдет. Но эти числа можно мерить только в тот момент. когда у нас багги зовутся правильно, их регулярно все ведут.

Вот небольшая схема. Система должна быть формально описана. Я для себя придумал такое формальное описание. Формальное зачем? Чтобы это сразу можно было запихнуть в базу и все.

Дистрибутив. Он состоит, к примеру, из трех операций:

1. Собрать серверную часть – это сервер на двух платформах;
2. Нужно собрать исходники – это архив с теми самыми исходными файлами. о которых я говорил;
3. И некая клиентская часть. Клиенсткая часть – это скрипты какие-то, их нужно тоже собрать в исходники, потом может быть как-то оптимизировать.

Что мы сначала делаем? Сначала мы должны собрать исходники. Потом эти исходники отправить на платформу 1 и 2-ю, получить результаты, собрать всю серверную часть из всех платформ и это все объединить. С клиентской понятно – там платформа одна – сразу собрали исходник, сохранили, отправили куда-то, сжали, запаковали, что-нибудь сделали, отправили сюда. Все замечательно.

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

Можно попытаться представить все это некими кубиками, у кубиков есть последовательность – они могут выполняться последовательно, параллельно, в зависимости от иерархии.

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

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

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

Каждый квадратик на самом деле одинаков. У квадратиков (у любого: сборка, тест – все равно) есть некие исходные файлы. Все исходные файлы хранятся в версионном хранилище.

Далее есть некая команда, которая над этими файлами выполнена. В первую очередь, изначально это была команда операционной системы. Потом поставил команду на платформе, потом стала команда на чем угодно – на базе, например. Т.е. если тест проверяет какой-то ЕХЕ-шник, то команда задана на платформе Windows. Такой же тест может быть для приложений баз данных. Не нужно писать что-нибудь, что будет там файлик соединяться с базой каким-то логинами. Команда будет выполнена на нужной базе данных сразу.

На выходе этого квадратика есть конечные файлы: результаты сборки, некоторые, может быть, дампы тестов, которые мы получили – любые результирующие файлы; логии и результаты работы.

Результаты работы – это как раз те строчки: «Выполнено то-то», «Сделано это», «Сборка прошла».

Так получилось, что весь этот квадратик у меня называется Целью. Потому что, по сути, он достигает некую цель. Цель какая – собрать этот ЕХЕ-шник. Цель? Цель. Достигли? Достигли.

Дальше мы эти квадратики раскрашиваем определенным цветом. Каждый квадратик, каждая цель имеет определенный тип. Все эти цели определены внутри некой подсистемы. У вас это может называться «продукт», что угодно. Это то, что разрабатывается. Внутри есть множество целей сборки и множество целей тестирования. Это типы. Тип 1 и тип 2. Сборка может быть, например, Debug и Release. Тип 4, тип 5. Тесты – тоже раз, два, три. Что-то рождается, что-то рождается, команды заданы фиксирующие – исходные файлы, результирующие файлы – все задается для платформы. Потому что до версии 15 – одна команда, после версии 15 – другая команда.

С тестами все то же самое. Команда валидна, тест валиден для одних версий, а для каких-то версий команд может не быть.

Все эти записи положили в мозг, что у нас есть подсистема, цели, что-то импортировали из внешних средств, что-то настроили автоматически. Составьте фото мастера, который задает вам три вопроса:

— Хотите сборку? – Да.

— Какая система у вас – платформенная или база данных, или что-то еще? – База данных, платформы такие-то.

Ок, он квадратики настроил, у него все элементарно. Потом разработчик подошел, что-то немного поменял в команде. Настройка делается мастером замечательно быстро. Все это лежит в базе.

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

Если мы начинаем это все крутить во времени, то у нас получается много результатов, и все результаты мы храним. Дальше выбираем, какие результаты выполнения нам нужны для какого-нибудь теста.

Потому что нам нужно следующее. Нам нужна последняя сборка для проведения регулярного ночного тестирования. Сборка отвалилась – тесты отвалились. В другом случае нам нужна последняя успешная сборка для того, чтобы все проверить. Это – второй вариант. Доставьте нам результаты последней успешной сборки. Потому что эта сборка нужна для запуска чего-нибудь другого. Нам нужна стабильная сборка – сборка, максимальным образом оттестированная. Либо нам нужна сборка, на которой тестировщик поставил: «Я ее проверил руками, мамой клянусь!».

Если у нас будет такой механизм, мы сможем делать все, что угодно.

Чтобы реализовать такой механизм. была выдвинута такая идея: когда у нас что-то автоматически начинает выполняться, мы создаем связи. Если у нас в каком-то пуле задач есть несколько одинаковых целей (в одном месте она выполняется, а в другом – выставляется.), Например, идет сразу несколько задач по сборке. Цепь сборки выполняется. А рядом пул задач, в котором эти результаты должны тестироваться. Там они не выполняются, там выставляются результаты. У нас получается пересечение целей – они все начинают быть связанными. связываются они в пределах определенного пула. Вот я зашел наверх, поставил галочки: подсистема – собрать, тест – такой, набор – такой. Создали заявку, сейчас все начнет работать. Они все между собой связаны. Базовая система упадет – все остальное тоже упадет.

А если я сначала сказал: «Собрать», а потом – «Тест», тогда получается в раздельном пространстве, и тогда они будут совсем по-другому складывать связь, непосредственной связи уже не будет. В итоге – выполняется сборка – три Билда, над Билдами выполняются тесты. Если тест под Билдом выполнился успешно, мы вешаем одну медальку. Под медалькой я подразумеваю такую запись: «Такой-то тест, выполнил такую-то проверку, получил такие результаты, и они признаны успешными». В итоге накапливаются сборки: успешные, неуспешные, часть из них протестирована, а какая-то протестирована очень хорошо.

Последняя деталь из вот этой большой теории – ресурсы. Если мы просто попробуем все запустить, у нас все свалится.

1. Пусть сервер будет перегружен.

2. Если я начну выполнять тесты одновременно, которые работают с одной и той же базой – понятно. что у меня что-то будет. Нужно как-то их разграничить. Но нельзя отдавать это дело делать человеку. Конечная задача должна быть такая: темная комната, никто никого не знает, откуда-то кто-то пишет тесты, они где-то появляются, автоматически запускаются, но между людьми связи нет. Я знаю, что я пшу только код. Вася написал тест, куда-то его положил. И Петя написал тест. Они друг друга вообще не знают – они из разных стран, они просто зарегистрировали тест. Это все должно автоматически запускаться. Они даже не думают о том, когда это будет запускаться – они ничего не запускают. Они пишут тесты и все. Но в тесте они указывают – к тесту нужна база. Он эту базу будет ронять, поэтому она должна быть в эксклюзивном доступе. А к другому тесту сказано – я эту базу буду писать и удалять, поэтому мне тоже нужна база, но в общем доступе.

Поэтому все, что у нас есть – это ресурсы. каждый ресурс имеет номинальную мощность, например – 5. Что такое «пять» с точки зрения сервера? Значит, что последовательно нельзя запустить более пяти задач одновременно. Что значит «пять» с точки зрения базы? Нельзя, чтобы больше пяти тестов использовали базу. При этом каждая цель, которая выполняется, может указать, что ей нужны какие-то ресурсы. вот одна сборка может сказать. что ей нужна одна единица, одна ферма. А некоторые сборки могут сказать, что им нужно три фермы, потому что у них….. Это настраивается через ресурсы.

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

У нас пять операций. Их нужно было где-то описать в цепочке. Если у нас нет ресурса, мы говорим, что тест 1, например, требует монопольную базу для КРАШ теста. база должна быть поднята из снапшота. Снапшот лежит в каком-то месте. Тесту 2 требуется база для юнита, на базе должны быть некоторые наборы данных К. Мы эти ресурсы описываем отдельно. Дальше мы говорим, что на самом деле тес – это взять дистрибутив, выполнить тест 1, затем тест 2. Указываем, что в порядке, потому что первый тест занимает 4 минуты. а второй – 20 лет. чтобы не гонять сначала 20 лет, а потом выяснить, что мы на самом деле гоняли не то, мы их ставим в цепочку. Но внутри теста мы выбираем, что для его запуска нам нужен ресурс. Автоматически он должен быть активирован, база должна быть поднята, потом, когда мы закончили пользоваться, база должна быть опущена.

Итог

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

Регулярное тестирование. Очень важно выполнение маленьких регулярных тестов. Зачем? Что это дает мне конкретно? Естественно, выполняется это на всех подсистемах подходящего класса. Каждую ночь абсолютно отдельным процессом оно все штампует.

Орфография — полезная, но маленькая вещь. Я этот тест разрабатывал один день, он работает уже полгода, очень много раз спасал жизнь.

Web-части — кодировка и соответствие правилам разработки. В Web-части нигде не должно быть явного указания о том, что: font +2, цвет – такой-то – только класс и все. Никаких левых элементов, только класс и только в определенном месте.

Первую часть взяли ночью последнюю сборку и проверили просто по всем файлам: что там написал разработчик: поленился он завалить какой-то класс, или смотришь – а, у меня что-то не помещается, но я задам сверху два пикселя — никто не заметит. Нет, заметят. Очень полезный тест.

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

Исходный код — проверка изменения SLOC. Очень хорошо помогает перед начальством – как у нас растет маржинальность. как у нас хорошо работает сервер. Ну и матерный словарь.

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

Если не отключен режим автосборки – то собирать каждую ночь и выполнять все тесты.

Большие тесты. К примеру, по пятницам, то есть расписание необходимо задать.

У меня есть отчеты для руководства, которые собирают данные по всему продакшену. Время выполнения отчета – там сложные вычисления – минут 20. Сделать его интерактивным нельзя. И человек ждет 20 минут. А информация должна быть примерно актуальна. Поэтому каждые полчаса эта задача стартует и собирает последние изменения, сохраняет это в отчет, и этот отчет где-то там лежит. Но переделывается каждые 30 минут.

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

Автоматическая чистка процессов. Мы вообще все выполняем через SSH. На всех Linux он, понятно, есть, на Мac он тоже замечательно работает, на Windows есть WinSSHd – тоже замечательно работает. Т.е. для нас это все в соединениях. Есть по соединениям пользователей. Вот 50 пользователей. Когда любая задача стартует, она всегда требует обязательно системные ресурсы, имя пользователя, под которым зайти на сервер, т.е. ей выдается свобода пользователя. Идет постоянная чистка – всем становится очень хорошо.

Если в тайм-ауте сказано: через 20 минут закончить выполнение этой вещи – значит, через 20 минут, она не только будет завершена. но и все процессы будут убиты. Как это будет сделано – все равно.

Управление нагрузкой. Есть платформы, у каждой, предположим, по два абсолютно идентичных сервера. Выбираем, к примеру, менее загруженный. Вот текущая загрузка 2/5. Это значит, он рассчитан на поддержку пяти задач, сейчас нагружен двумя. Мы знаем о загрузке всех серверов, мы знаем пул задач впереди. Может потребоваться эксклюзивный захват сервера. Потребуется, мы перекинем задачу с одного на другой. Мы можем уничтожить, из снапшота поднять опять всю базу и запустить ее в другом месте.

Серверы могут быть в платформе еще и разные. Вот есть какая-то платформа с просто Windows, на ней – просто два сервера, но с другими переменными окружения.

Последний слайд как раз про отчеты. Получилось так, что мы начали использовать Microsoft Report Server. Нам его купили и сказали: «Используйте!». Я его использовал несколько дней и понял – нет, спасибо. Для того, чтобы составить всю эту штуку, он занимался построением отчета очень долго. Любой отчет - это цель. У нее есть тоже свои данные, для того, чтобы этот отчет где-то запустить, на базе, либо файл какой-то выполнить. На выходе этой цели обязательно должен быть файл index.html.

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