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

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

Далее приведён ряд рекомендаций о том, как сделать задачу создания сборки более простой и эффективной.

Поддерживает набор правил сборки и отношений в программе для всего приложения или компонента. Описав эти правила, Make может решить, какие образы необходимо собрать и какие исходные файлы должны быть откомпилированы или скомпонованы.

Make существует уже несколько десятилетий, всё началось в UNIX, а затем она появилась практически на всех остальных платформах. В течение многих лет её улучшали, и последняя версия — Nmake — входит в состав Microsoft Visual Studio. Обязательно изучите утилиту Make в вашей среде разработки и используйте её для автоматизации задач сборки ПО.

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

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

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

Сборочная среда — это набор приложений, инструментов, библиотек и компиляторов, нужных для компиляции и компоновки ПО. Часто лучше всего установить эту среду на нескольких выделенных сборочных машинах, которыми распоряжаются и управляют исключительно технологи по разработке ПО, изменения на этих машинах недопустимы. Важно обеспечить и регулярное резервное копирование дисков этих машин, чтобы восстановление было простым и быстрым. А чтобы избавиться от неожиданных трудностей, не забудьте установить антивирусное ПО.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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