Групповая разработка и организация коллектива

Групповая разработка, управление версиями

Один из департаментов нашего коллектива разрабатывает ПО телефонных станций, которое включает в себя следующие компоненты:

• ОС реального времени;
• драйверы телефонного оборудования;
• функциональное ПО;
• программы рабочих мест операторов (РМО);
• БД конкретного экземпляра АТС.

Каждый компонент разрабатывается отдельным коллективом разработчиков, но все компоненты тесно связаны друг с другом. Более того, каждый компонент (кроме, пожалуй, драйверов) состоит из большого числа модулей, разрабатываемых разными специалистами. Таким образом, налицо проблема взаимодействия большого количества разработчиков, каждый из которых может находиться в своей фазе разработки, может внести в свою программу такие изменения, которые не позволят другому разработчику отлаживать его программу и т.д. К сожалению, и в нашем коллективе, в котором слово "технология" царит уже более 20 лет, нередки случаи, когда при выезде на объект БД не соответствует ФПО или версия РМО уже устарела. Наша техническая вооруженность позволяет быстро справляться с этими трудностями, но свести проблемы к нулю можно лишь жесткими организационными мерами, прежде всего, требуется преодолеть многие советские привычки и особенности нашего менталитета.

Еще 20 лет назад у нас в коллективе сложилась трехуровневая система версий, которая в том или ином виде актуальна до сих пор. Разработчик действует в своем файловом пространстве (раньше мы говорили "библиотека разработчика"), делает там, что хочет, и ни с кем ничего не согласовывает. Когда группа разработчиков решает, что какие-то модули отлажены (или когда их руководитель решает, что ждать больше нельзя, cроки поджимают), исходные тексты модулей передаются в библиотеку тестирования. Система или какой-то ее компонент проверяется на всех существующих тестах, причем библиотека тестирования остается фиксированной, все найденные ошибки заносятся в базу данных ошибок и исправляются в библиотеках разработчиков. Когда все тесты пропущены, библиотека тестирования вместе со списком найденных ошибок копируется в библиотеку предъявления, а библиотека тестирования готова к приему новой версии из библиотек разработчиков.

Подчеркнем еще раз, что в библиотеку предъявления перенос осуществляется сразу же, когда пропущены все тесты, а вот перенос в библиотеку тестирования – только по мере готовности группы разработчиков выдать новую версию системы.

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

Описанная выше трехуровневая система версий является слишком крупноблочной. В современных технологиях используются специальные инструментальные средства, позволяющие фиксировать каждое изменение и откатываться к нужной точке, например, Visual Source Safe или PVCS. Обычно такие системы версионирования устанавливаются на сервере, разработчики играют роль клиентов (тем самым автоматически решаются технические проблемы, например, разрешение конфликтов при одновременном обращении, вопросы back-up и др.), а система предоставляет следующие методы:

• Check-out: взять текст на исправление;
• Check-in: вернуть обратно;
• Undo check-in: отмена всех изменений, сделанных во время последней сессии;
• Get latest version: берется один файл или файлы целого проекта в том состоянии, в котором их застал последний check-in.

Последняя версия обычно хранится отдельно.

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

Насколько хорошо у нас поставлена система версионного контроля, как-то раз я убедился лично. Однажды поздно вечером я зашел за своей женой, которая также работает на нашем предприятии, и говорю: "Пошли домой, устал до смерти, больше не могу работать". Она мне: "Пока check-in не сделаю, уйти не могу, иначе меня завтра ждут большие неприятности". Это меня позабавило – я же генеральный директор, какие могут быть неприятности, если я сам о чем-то прошу? Она мне спокойно объясняет, что в данном случае никакой роли не играет, кто я и кто она. Каждую ночь у нас идет автоматическая сборка разрабатываемого продукта, затем автоматическое тестирование. Сборка начинается с перетрансляции абсолютно всех модулей (чтобы исходные тексты не разошлись с объектными модулями). Если в текстах есть формальные ошибки, трансляция завершится с аварийным кодом возврата, сборка выполняться не будет, а утром как виноватые исполнители, так и их руководители получат автоматически сгенерированные сообщения с исчерпывающим объяснением ситуации. Это какой-то страшный бездушный молох, машина, в которую даже генеральный директор влезть не может.

В результате мне пришлось прождать больше часа, пока все формальности не были выполнены.