Где провести черту: системы контроля версий

Очень часто в повседневной работе возникает вопрос компромисса. Насколько глубоко нужно изучать предмет? Насколько в программе нужно предусматривать возможности расширения? Лучшее действительно враг хорошего? Когда нужно остановиться в улучшениях? Насколько ревностно стоит следовать стандартам форматирования кода? Действительно ли скобка поставленная не на той строке обозначает некоторую критическую проблему в ДНК человека, её поставившего? Все подобные вопросы объединились в моей голове под общим "заголовком" - "Где провести черту?"

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

Про то, что такое система контроля версий и зачем она нужна, я думаю все, кто когда либо программировал, знают. Ну, а если кто не знает, отошлю на википедию.

Несмотря на то, что подобные системы существуют уже очень давно, частенько возникают вопросы по правильному их использованию, а именно - вопросы типа "где провести черту".

Что должно находиться в системе контроля версий?

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

У меня на этот счёт очень простой взгляд. Мы занимаемся производством программного продукта. Производством того, что мы поставляем конечному пользователю (заметим, что конечный пользователь - это "роль" - им вполне можем быть мы сами). Поэтому в системе контроля за исходными текстами должно находиться все что нужно чтобы собрать версию нашего продукта заново. То есть это исходные тексты программы, документация, картинки, сборочные скрипты, тексты лицензионных соглашений и так далее. Очень просто проверить находится ли в системе исходных текстов все что нужно - необходимо взять "чистый" компьютер, поставить на него то программное обеспечение которое необходимо для сборки продукта, "взять" из системы управления версиями какую-то версию продукта и попробовать запустить процесс сборки (сетевой доступ к чему-либо, кроме системы контроля версий можно отменить). Если получится нормальная сборка продукта - значит в системе есть все что должно быть.

Должно ли в системе контроля версий быть что-то ещё? Вопрос вкуса. Мне кажется что на уровне общих "правил" не стоит пытаться засунуть туда все что можно себе представить.

В какой момент вещи должны попадать в систему контроля версий?

Здесь тоже есть масса мнений. Начиная с мнения - "положу перед релизом", до попыток положить каждое изменение, в том числе и неработающий код.

Заметим, что крайности бывают двух видов - "слишком редко" и "слишком часто".

Проблема "слишком редко", на мой взгляд, достаточно легко решается введением практики "ежедневной сборки". Если такая практика существует (даже если сборка не ежедневная, а просто производится достаточно часто), то трудность сама собой исчезнет.

Проблему слишком частого внесения изменений решить несколько сложнее. Часто вводят строгое правило - "не чекинить не работающий код", которое в результате может вылиться у людей в отторжение и даже боязнь внесения кода в систему контроля версий вообще. Данную проблему можно решить разными способами, но на мой взгляд самым простым является заведение в системе контроля версий "своей" ветки для каждого из разработчиков, в которой он сможет работать так, как ему удобно. В момент "сборки" можно просто переложить готовые файлы из личной ветки в общую (ну и сделать "merge" при необходимости).

Замечание для "администраторов"

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

Любая программная система требует регулярного обслуживания, резервного копирования, наличия достаточного места на диске, адекватной производительности компьютера на котором она работает и сети через которую в неё осуществляется доступ. К системам контроля версий это относится в полной мере.

Часто бывает так, что принимается решение не хранить какие-то виды документов или не создавать отдельных каталогов для пользователей из соображений "административного характера". А именно - не хватит места на дисках, резервное копирование будет занимать много времени, не хватит лент, используемая система контроля версий "плохая" и если хранить в ней двоичные документы, то ведёт себя плохо.

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