Она не должна быть сложной, но вам по крайней мере следует создать инфраструктуру, на основе которой начнётся строительство.
Мышцы
С продвижением проекта строительство продолжится на основе простой структуры, созданной вами, путём добавления сложных и утончённых элементов. Смысл в том, чтобы улучшать процедуру параллельно разработке проекта, т.е. сначала вы строите скелет, а со временем наращиваете его. Скажем, завершены новые компоненты, включена поддержка новых ОС или баз данных, упрощён текст лицензионных требований — вам нужно добавить новые файлы и изменить процедуру согласно новым требованиям.
Я не предлагаю проводить эту работу на сиюминутной основе — это вызовет только беспорядок. Следует добавлять компоненты в процедуру установки лишь по необходимости. Ваша задача — написать план разработки процедуры установки, обеспечивающий включение определённых компонентов и поддержки, необходимой для разработки и тестирования. Этот план должен помочь вам найти равновесие между двумя крайностями: ежедневного внесения изменений и несвоевременного приведения продукта в соответствие с требованиями.
Комплект
Это набор файлов, поставляемый пользователю. В процессе создания комплекта процедура установки связывается с устанавливаемыми файлами. Результатом часто является набор сжатых файлов, не представляющих того, что реально будет помещено на систему пользователя. Хорошо бы знать, что применяется в процессе создания комплекта и что получается на выходе. Неплохо разработать и тест, проверяющий наличие нужного числа файлов с приблизительно правильной датой и размером. Для этого могут быть очень полезны приложения, автоматически проверяющие содержимое комплекта.
Сбор всего вместе
Когда у вас есть сборки и процедура установки, следует собрать все вместе в автоматизированный конвейерный процесс. Процесс должен быть создан в самом начале проекта, возможно, это должно быть первой задачей.
Главные шаги цикла сборки таковы:
• сборка образов;
• создание комплекта;
• тестирование комплекта;
• отправка сообщения о прохождении теста или сбое;
• запуск базисных тестов для проверки сборки;
• если тест пройден удачно, копирование в каталог LKGB;
• отправка сообщения о прохождении базисного теста или о сбое.
Ежедневные сборки, комплекты и тесты
Ежедневный процесс сборки, создания комплектов и тестирования задаёт темп реализации проекта. Эти процессы надо запускать еженощно, а чтобы точно понять состояние проекта, — результаты просматривать каждое утро. Только тогда вы сможете принимать грамотные решения о необходимых изменениях. Без этих процессов вы будете действовать вслепую и никогда не узнаете, собирается ли проект воедино (и вообще сможет ли он заработать), пока не будет слишком поздно, и вы ничего не сможете поделать. Всё, что вам останется, — сдвинуть график.
Убеждение
В организациях, где уже приняли эти правила, люди знают, что сборки, установки и базисные тесты могут выполняться ежедневно. Но в других организациях сотрудники могут отнестись к этому скептично. Обычно они слишком заняты, у них нет ресурсов, и они противятся выполнению лишней работы. У кого есть время на эту ерунду? Я бывал в таких фирмах и знаю, что это сложно. Но выгода огромна, и вы можете внедрить эти принципы. Я рекомендую сначала убедить команду в этих идеях, а затем реализовывать их шаг за шагом: сначала создавать рабочие сборки, затем процедуры установки и, наконец, базисные тесты.
Из собственного опыта
Вначале принцип ежедневной сборки был новым для нашей компании. Мы были небольшой командой, и запускать процесс ежедневной сборки было сложно. Не хватало поддержки, достать сборочную среду, машины и наладить процессы было тяжело.
Однажды я спросил, была ли сегодняшняя сборка уcпешной. Коллега ответил: «Ты что, считаешь, что мы должны создавать эту сборку каждый день?» Да, каждый день. Это часть нашей модели разработки, и это критично для способа, которым мы работаем.
Спустя годы смешно оглядываться на те дни. Сейчас ежедневные сборки — часть нашей культуры, чему никто не сопротивляется. Это само собой разумеется, и когда в сборке происходит сбой, мы видим справедливый гнев всей команды.

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

Дисциплина
Ежедневное создание сборок, комплектов и тестирование требует много сил.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88