Те, кто занимаются оптимизацией производительности, знают, что round robin это простейший способ распределения данных между потоками обработки.
В нашей команде за этим понятием прочно закрепился и другой смысл – честное распределение рутинной работы между членами команды.
Например, у нас есть просто замечательная обязанность – запускать ежедневные тестовые билды.
Занятие, в общем-то, рутинное. Нажать на кнопку, подождать, проверить, нажать на еще одну кнопку, подождать, убедиться, что все в порядке, на следующий день посмотреть, что все завершилось, доложить о результатах на ежедневном собрании, послать письмо. Скука.
Однако с определенной частотой эта скука превращается в мини-кошмар – билд падает. Его чинят. Иногда билд падает снова. Иногда снова и снова. Бывает ведь черная полоса в жизни? Одну проблему исправили, кто-то что-то изменил, билд падает уже по другой причине – на то они и нужны, эти билды, чтобы падать и вскрывать проблемы. Пораньше. Бывает, что эти падения становятся критичными, ведь у нас же время для еженедельного или месячного релиза, а уже 3й день к ряду все падает. Надо чтобы кто-то взял все в руки, объявил комендантский час, и все усилия были направлены на стабилизацию.
На такую важную задачу хочется выделить достойного кандидата, чтобы не подвел в ответственный момент. Так мы и сделали.
Сочетание рутины и перманентного ощущения муравейника под задним местом – очень опасно. Месяц, другой, третий – результат не заставил себя долго ждать. Человек с железными нервами пришел и выдвинул ультиматум. Не могу, давайте кого-нибудь другого назначим. Или сами знаете что.
Да, точно. Давно уже понятно было, что подход дает трещину. Только кого? Еще одного железного парня, чтобы таким же образом испортить ему мотивацию?
К счастью, решение было найдено быстро. Round robin.
Мы много работаем с производительностью и параллелизацией, поэтому понятно, почему мы это называем round robin, остальным же будет ближе школьное понятие “who is on duty today?” или кто сегодня моет доску.
Да, все настолько просто – детские школьные принципы. Берется журнал и по алфавиту – сегодня Дима моет доску, завтра Миша, послезавтра Наташа. Наташа знает, что порядок фиксирован, и ей мыть доску в среду, поэтому отговорки «а я не знала» приниматься не будут. Помыв доску, Дима передает повязку Мише, показывает, где лежит тряпка и говорит о том, что классная будет проводить завтра в 10 контрольную и к 10 доска должна быть идеально чистой. Миша не против и даже немного гордится тем, что ему нужно будет мыть доску, ведь не каждый же день выпадает такая возможность поважничать – я сегодня дежурный. Если во время Мишиного дежурства Дима с Наташей начнут играть в квача тряпкой от доски и их застукает классная, то она делает выговор Мише. Однако все знают, что завтра они будут на месте Миши и им придется нести ответственность, поэтому к приходу классной все заканчивается.
Резюмируя:
- Порядок дежурства должен быть строго определен и выполняться неукоснительно, все должны участвовать и каждый должен быть в курсе, когда ему нужно будет готовиться к дежурству
- Все знают, кто сегодня дежурит и кого можно призвать к ответственности за беспорядок
- Рутинная работа перестает быть рутинной, если она выполняется не каждый день
- Передача обязанностей должна быть строго регламентирована, все, что требуется знать следующему по списку для дежурств, передается ему предыдущим дежурным
- Ответственность за результат распределяется по всей команде и все чувствуют причастность к процессу
И что самое главное, все наши гениальные новые идеи – это просто хорошо забытые старые. Встретили проблему? Что-то напоминает? Не ленитесь покопаться глубже в своей памяти и решение не заставит себя ждать.
Хороший подход. Правда, иногда приходится пинать тех, кто выше тебя по иерархии, потому что ты им, типа, не указ, зато они тебя могут "закидать тряпками"
ОтветитьУдалитьУ нас для этих целей поднят CI сервер. На каждый push в рабочую\релизную ветки запускаются все модульные и интеграционные тесты. У всех в трее висит нотфикатор, который показывает что там сейчас происходит + рассылка в jabber/почту о упавшем билде.
ОтветитьУдалитьЗабыл добавить - тестовый\релизный билд строиться по расписанию ночью. Все также с рассылкой уведомлений. В день релиза нужно только прийти и распакавать архив:)
ОтветитьУдалитьCI сервер и у нас поднят, компиляция + юнит тесты отлично работают с рассылками куда нужно. Просто это не работает в случае интеграционного рана, который занимает несколько часов. Цена ошибки высока, поэтому надо более методичный подход.
ОтветитьУдалитьИнтеграционные тесты прогоняются ночью:)
ОтветитьУдалить:) У нас проект разбит на 4 локейшина: Лондон, Минск, Пекин, Нью-Йорк. Понятие ночного билда становится очень относительным.
ОтветитьУдалитьМожно выделить определенное время и обозвать его "ночь".
ОтветитьУдалитьИ, я вроде правильно понял, что круговая порука по запуску интеграционных тестов выполняется только в Минском офисе?
В общем я за автоматизацию.
1. Автоматизация и так есть, всё делается автоматически, просто две кнопки нажать на странице СС. Вопрос в том, что есть очень опасная стадия работы интеграционного билда, когда он удаляет старые артефакты, устанавливает новые версии компонент и запускает это всё. Вот тут потенциально могут возникать проблемы, которые автоматически не решишь. Например, Чун Шен Чен зашёл на бокс и открыл посмотреть конфиг компоненты, потом его отвлекли и он забыл закрыть редактор, в результате файл залочен и uninstall запущенный СС падает и всё стопается. Вот именно в этот момент нужен дежурный, который и станет разрешать эту ситуацию или искать виновника, а не вся команда будет бегать с воплями и криками, как же так, билд упал. И таких ситуаций бывает море.
ОтветитьУдалить2. Кроме того, такие интеграционные запуски обычно требуют определённой конфигурации. Например у нас это может быть версия данных, которые используется для тестирования. И эта версия определяется на митинге. Как это автоматизировать? В любом случае нужен человек, который настроит пару параметров перед нажатием кнопки для запуска СС проекта.
3. Важно не только запустить интеграционный тест, но если он упал разобраться в причинах падения, выяснить виновника. И это может быть вовсе никто из нашей команды, так как в этом запуске участвует много сторонних компонент других команд. Кроме того, если это наша проблема, то также необходимо выяснить кто это поломал и пнуть его на активную работу. Это всё делает дежурный и я не представляю как это автоматизировать.
3. Ну там на dev.by Андрей уже писал, что запуск по времени не очень кошерное решение. Потому как например, кто-то на полчасика опаздывает с коммитом. И в случае дежурного, он может подождать и запустить проект, когда всё уже будет в репозитории. Так как лучше подождать полчасика и это вошло в этот дейли, чем потом день ждать, раньше выявятся проблемы.
Не все автоматизируется. Например, troubleshooting. Цена ошибки высока, поэтому и назначается отдельный человек, чтобы этим заниматься.
ОтветитьУдалить