Сборки

We use cookies. Read the Privacy and Cookie Policy

Сборки

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

Почему они важны

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

Из собственного опыта

Когда я пришёл в NuMega, единственным человеком, способным собрать продукт целиком, был один из талантливейших инженеров — Мэт Питрек. Даже когда команда и продукты ещё были небольшими, среда разработки была чрезвычайно сложной. Только Мэт знал, что делать. Чтобы собрать программу, он уходил в свой кабинет и закрывал дверь. Он как помешанный колдовал над тремя разными компиляторами и дюжиной сценариев, вручную редактировал конфигурационные и другие файлы. Затем, после 3-4 часов интенсивной работы, он взмахивал волшебной палочкой, и обычно у нас появлялась готовая сборка. Мы предполагали, что он не нашёл никаких проблем.

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

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

Как их создавать

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

Утилита Make

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

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

Номера сборок

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

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

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

Сборочные машины и лаборатории

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

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

Оповещение и сбои

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

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

Проверка

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

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

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

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

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

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

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

Штрафы и измерения

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

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

Частота сдачи и проверки сборки

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

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

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

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

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