Эд Салливан - Время — деньги. Создание команды разработчиков программного обеспечения

С ростом числа ваших сборочных машин потребуется целая сборочная лаборатория. Лаборатория полезна, когда нужно параллельно собирать действительно большие программы или большое количество программ (возможно, по ночам). Сборочная лаборатория поможет обезопасить наши машины и предотвратить посторонние вмешательства, способные привести к сбою.

О завершении сборки команду надо оповестить. Извещение может быть послано в список рассылки всей команды проекта или для этих целей может быть создан свой список рассылки.

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

Созданная сборка должна быть помещена на сетевой диск с совместным доступом, где она будет проверена при помощи автоматических тестов, созданных командой тестирования. Проверка — очень важный этап, так как наличие готовой сборки ещё не означает, что продукт в рабочем состоянии. Вы знаете только то, что можете компилировать, и компоновать все нужные файлы.

Один из лучших способов проверить сборку — установить продукт и запустить базисные тесты (см. о них главу 6). Для эффективного управления этим процессом для сборок следует завести два каталога.

• Самая последняя сборка (MRB)

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

• Последняя хорошая сборка (LKGB)

Здесь хранится последняя хорошая сборка. Убедившись в том, что текущая сборка находится в хорошем состоянии (она установилась и прошла базисные тесты), скопируйте содержимое каталога MRB в каталог LKGB.

Для своей повседневной работы команда должна производить установку из каталога LKGB. Обычно команда, отвечающая за контроль качества, перемещает последнюю сборку в LKGB сразу после её проверки. Если в последней сборке обнаружены проблемы, команда все равно может работать, так как сборка в каталоге LKGB является рабочей.

Как я говорил в главе 5, в NuMega решили обойтись без большого числа технологических приёмов (процессов). Но к процессам, которые у нас имелись, мы относились очень серьёзно и следовали им. Сборка являлась одним из них. Мы решили, что если кто-то ломает сборку, то на следующее утро он покупает пончики на всю команду. Такая простая, но эффективная стратегия подчеркнула необходимость работы над сборкой должным образом и установила наказание за её порчу. В тех командах, где не было технологов, сломавший сборку брал на себя обязанности по технологической поддержке до следующего сбоя.

Другим способом подчеркнуть важность процесса сборки является его измерение. Следите за тем, сколько раз за период времени в сборке происходит сбой, и, возможно, за тем, из-за кого сбои происходят чаще всего. Знание того, что за процессом сборки наблюдают, подстёгивает людей к самодисциплине при сдаче исходных файлов. Также вы можете наблюдать за тем, сколько времени команда работает, не ломая сборку, и предложить стимулы для достижений в этой области. В больших организациях можно подумать об организации соревнования с другими командами.

Чтобы не сломать сборку, ответьте на следующие вопросы.

• Когда я должен сдать мой код?

Сдавайте свою часть кода, когда у нас есть что добавить к проекту. Это может быть сосём простое добавление, скажем, набор заглушек API, или очень сложное, например, крупный компонент. Но вы должны сдавать свой код часто. Смысл в том, чтобы как можно раньше заставить работать код, созданный разными людьми.

• Как я могу быть уверен в том, что не испорчу сборку?

Если возможно, для проверки кода осуществите локальную сборку программы. Вы как обычно берете код из системы управления исходным кодом, интегрируете ваш код и возвращаете его в систему. В большинстве проектов эта процедура выполняется просто, и это отличный способ гарантировать то, что вы не испортите сборку. Дополнительно, чтобы убедиться в отсутствии новых ошибок, можно запустить входные тесты (см. главу 6).

Процедура установки важна не только для потребителя проектах в последнюю очередь, от чего может пострадать весь проект. Здесь я расскажу, почему процедура установки так важна и как строить процедуру установки параллельно разработке ПО.