Начало
Около более года назад на предприятии был начат новый проект, и который вот уже закончен. Поручили выполнять его мне и моему коллеге.
В качестве основы разработки была выбрана библиотека Qt, Так как до этого все проекты на предприятии велись в Delphi, мы стали первооткрывателями этого мощнейшего инструмента. До этого никто из нас не занимался разработкой коммерческих продуктов с использованием библиотеки Qt.
Систему контроля версий мы выбрали быстро — SVN. Потому что у нас уже был некоторый опыт работы с ней, а также потому что надо было с чего-то начинать. Как ни странно это звучит, до этого момента на нашем предприятии не было внедрено ничего похожего на систему контроля версий (СКВ), кроме архива на сервере, в котором у каждого программиста была своя директория, и в которой он был хозяином.
Все описанное ниже относится к практическому опыту использования SVN в проектах на Qt c примесью современных бизнес реалий.
Разработка структуры репозитория (хранилища)
После анализа предстоящей работы, мы быстро создали все основные папки для исходников в хранилище (каждый отдельный репозиторий я буду называть хранилищем) на моей машине, начиная с пресловутых trunk, branches, tags и заканчивая различной спецификой. Договорились об именовании папок, файлов и стилевому оформлению кода. В этом нам очень помог разработанный ранее документ по стилевому оформлению кода С++ на предприятии. Все новички в команде знакомились с этим документом перед работой и вопросов в дальнейшем почти не возникало. Затем мы добавили пользователей и начали работу.
Начало проблем
Через месяц разработки у нас на сервере было уже несколько хранилищ. Одно крупное для основного проекта. В нем располагались две основные программы, имеющие множество общих компонентов. Остальные были созданы для создаваемых инструментов, крупных подсистем, которые предполагалось использовать и в других проектах.
И тут возникла первая проблема. Я создал простое хранилище у себя на машине и предоставил своему коллеге доступ к нему с помощью VisualSVN. До создания отдельного хранилища на сервере в тот момент руки не доходили. Наши администраторы и руководство напрочь игнорировали просьбы организовать отдельный сервер с автоматическим резервированием для централизованного хранения не только нашего проекта, но и всех последующих. Какое-то время я справлялся с администрированием хранилища, созданием резервных копий на съемный винчестер.
Дело в том, что мне пришлось переехать в другое помещение. А это смена ip-адреса. Для хранилища это не только пресловутый relocate, но и еще правка всех свойств папок, содержащих svn:externals. Эта небольшая неприятность была быстро побеждена и работа продолжилась дальше. Хранилище осталось на моей машине.
Вердикт: Необходимо организовать отдельный сервер для хранилища.
Дальше — больше
Второй проблемой стали разногласия в организации структуры хранилищ подпроектов. Для некоторых подпроектов мы создали также популярную структуру папок: trunk, tags, branches. Хотя в при сборке всегда использовался trunk, и во всех pro-файлах фигурировал очень не красивый путь, содержащий trunk. Решено было создать папку со всеми необходимыми внешними включениями для каждой из двух программ в этом хранилище. В этой папке также были созданы pro-файлы для сборки общего проекта. С учетом выбранной модели, один проект — одно хранилище, никаких негативных последствий от такого решения в дальнейшей разработке мы не испытали.
Вердикт: Если используется подход один проект — одно хранилище, то папки trunk, tags, branches лучше размещать только в корне хранилища.
В процессе работы над проектом к нам в разное время присоединялось еще 3 программиста, все были начинающими. Двое разрабатывали определенный ограниченный функционал — модули, библиотеки, которые редко соприкасались с чем либо, и один участвовал наравне с нами в разработке основной системы. Они также как и мы вносили изменения и новый код в хранилище. Также со временем менялись требования, в некоторых областях значительно, поэтому структура хранилища немного изменялась, переносились подпроекты, правился код.
И где-то через 8 месяцев с начала разработки (группы тестирования у нас нет, поэтому тестами занимаются программисты), когда над проектом снова начало работать два программиста, мы поняли, что совершили еще одну серьезную ошибку. Если слить себе содержимое хранилища, то собрать что либо без дополнительных манипуляций не представлялось возможным и при этом каждый программист знал как собирать только свои модули. Ситуацию усугубляло большое количество кода, большое количество модулей и их зависимостей. Решение оказалось на поверхности.
Во-первых, мы начали создавать различные pro-файлы для одних и тех же модулей, но с различными путями компиляции, и различным местоположением конечных бинарных файлов. Во вторых все подмодули начали помещаться в хранилище со своими pro-файлами, если это библиотека, либо с pri-файлами, если это просто код, который необходимо куда то включить. Теперь основной pro-файл перед сборкой основного проекта собирал все зависимые библиотеки.
Во-вторых, мы создали в корне папки, где лежали самые главные pro-файлы папки include и lib. В папку include мы стали помещать заголовочные файлы без расширения с одной строчкой приблизительно такого содержания: #include “../modude1/src/modile1.h”. Это позволило для работы включать всего одну директорию с заголовочными файлами и не беспокоиться, где лежат нужные файлы. А в папку lib помещались все собираемые библиотеки из подпроектов. Тем самым прописав в пути всего одну директорию мы исключили все зависимости от библиотек.
Вердикт: Крайне важно поддерживать принцип: слил из хранилища и собрал без проблем.
Идея создания цивилизованного хранилища для нашего когда назревала все больше к приближению окончания разработки. С одним из программистов мы нашли простаивающую машину. На нее был поставлен Debian, SVN, FTP. Переведены все хранилища на нее. Через пару месяцев на моей рабочей машине вышел из строя винчестер, поэтому значимость резервных копий и централизованного архивирования наработанного кода нельзя отрицать.
Вердикт: Необходимо не просто завести отдельный сервер для хранения кода, но и важно настроить его архивирование.
За контроль за архивами и работоспособностью сервера, после ухода инициатора создания сервера, приходится отвечать мне.
Зимой мой коллега-баскетболист открыл для себя волейбол и на второй неделе порвал связки на ноге. Вообще проект достаточно травматичный. До этого главный конструктор сломал ногу. Еще одного программиста сбила машина, благо не сильно — вышел на работу через неделю. Уже осень — без происшествий! В общем выбыл наш программист из строя на три месяца, но продолжил работу дома.
Это единственный момент, когда мы почувствовали нехватку распределенной системы контроля версий. По возвращению коллеги, код был успешно добавлен в хранилище методом грубой силы, то есть руками.
Вердикт: Нужно научиться работать с патчами и делать слияния.
Почти конец
А на прошлой неделе надо было собрать весь проект воедино и тут пришлось попотеть. Не смотря на то, что практически все уже собиралось по принципу: слил версию и собрал, некоторые части (самые свежие наработки) вообще еще не были добавлены в хранилище. В некоторых местах были некорректные конфигурационные файлы или были не добавлены тесты в хранилище.
Вердикт: Начал работу над задачей — помести ее прежде всего в хранилище.
Выводы
Вот уже почти закончен проект. Мы пережили постоянный недостаток информации, меняющиеся требования, сбои машин и горелое оборудование, быстрые темпы разработки в маленькой команде. Сегодня успешно прошла предварительная приемка, всем все понравилось, ПО отработало без ошибок и сбоев, впереди госкомиссия. Хранилище исходных кодов почти приведено в порядок. Видно что в этом проекте мы набили себе достаточно шишек на ошибках в работе с SVN и впредь, надеюсь, их не будем повторять. Удачной командной работы в системах контроля версий!
