Чтобы несколько программистов могли без проблем работать над одним проектом, необходимо выполнить как минимум два условия:
Системы управления исходным кодом достаточно просты в использовании, поэтому с первым пунктом достаточно просто разобраться. А вот второй пункт может вызвать затруднения, поэтому я поделюсь своим опытом работы в различных командах. Будем надеяться, что этот опыт поможет вам выработать наиболее эффективную стратегию управления исходным кодом.
Наиболее популярной программой для управления проектами является разработка Microsoft – Visual SourceSafe (или просто VSS). Нельзя сказать, что этот продукт обладает лучшими возможностями, есть разработки и получше, но, как и большинство продуктов этой компании, Visual SourceSafe становиться законодателем моды.
Установка VSS максимально упрощена и ее нет смысла описывать. Дальнейшая работа также не содержит ничего сложного, поэтому мы кратко пробежимся по основным функциям и перейдем к более интересному. Пакет VSS нужно устанавливать на каждом компьютере программиста, и одну полную копию желательно установить на выделенном сервере.
Почему исходные коды должны быть именно на сервере, а не на компьютере одного из программистов? Как показывает практика, программисты очень часто издеваются над своими компьютерами, устанавливают нужный и ненужный софт, постоянно изменяют настройки и конфигурацию и поэтому такие компьютеры больше подвержены краху. Выделенный сервер редко использую не по назначению, и он будет более устойчив к сбоям, а значит, драгоценный исходный код будет находиться в большей безопасности и более доступным.
Когда файлы находятся на выделенном сервере, ими проще управлять с точки зрения безопасности и надежности. К этому серверу можно жестко прописать доступ только программистам и не связывать его с Интернетом (запретить доступ сетевым экраном и правами доступа), чтобы код невозможно было украсть. Что мы понимаем под надежностью? Любой компьютер подвержен ошибкам и сбоям. Жесткий диск может развалиться в любой момент, и когда данные находятся на выделенном компьютере, удобнее и проще наладить резервное копирование данных.
Защищая исходные коды на сервере, не забывайте, что у каждого программиста есть локальные копии всех файлов проектов, над которыми он работает. Таким образом, хакеры могут украсть исходные коды у программистов, без обращения к центральному хранилище. Защищать нужно все.
Для работы VSS не нужен сверх мощный компьютер, достаточно самой простой рабочей лошадки со старым Windows, поэтому затраты на хранение лишнего системного блока будут минимальны.
После установки, необходимо на сервере запустить утилиту Visual SourceSafe Admin и добавить всех пользователей, которые будут иметь доступ к исходному коду и должны иметь возможность работать с ним. Все функции по управлению пользователем находятся в меню User. Чтобы добавить нового программиста в команду, выбираем меню Users/Add user. По умолчанию пользователь получит права чтения и записи, но можно ограничить его только чтением (Read only).
Когда на сервере настроены все учетные записи для программистов, переходим к работе на клиентской стороне. Для этого запускаем Visual SourceSafe Explorer. Для начала необходимо указать базу данных исходных кодов, с которой будем работать. Для этого нужно выбрать меню File/Open SourceSafe Database. Откроется окно, в котором можно выбрать уже существующую базу или можно создать новую. Для создания новой щелкаем по кнопке Browse, и ищем файл srcsafe.ini на сервере. Если вы знаете точное расположение файла и к нему есть доступ, то в поле для ввода файла можно явно указать путь, например:
\\192.168.0.1\VSSFolder\srcsafe.ini
В данном случае, будем считать, что 192.168.0.1 – это IP сервера, и там есть открытая папка VSSFolder. Когда база данных открыта, с ней можно начинать работать.
Принцип работы VSS достаточно банален. На сервере сохраняется последняя копия файлов исходного кода, а также все промежуточные копии, то есть история изменений. По истории изменений достаточно легко вычислить – кто и что натворил в исходном коде. Так что, когда над кодом работает команда, можно легко вычислить, кто накидал в исходный код жучков.
Теперь посмотрим, что находиться в окне программы VSS Explorer. Слева можно увидеть дерево директорий, как и в простой файловой системе. Выбирая директории, справа можно увидеть, содержащиеся в ней файлы. Чтобы добавить новые файлы или директории в SourceSafe достаточно только перетащить их из файлового менеджера или проводника.
Все, что мы видим сейчас в VSS, находиться на сервере, а чтобы начать работать с исходным кодом, его нужно забрать. Для начала нужно указать, куда должен забираться код. Для этого заранее создайте директорию на своем компьютере, куда нужно будет складывать код, а потом щелкните правой кнопкой по корню дерева директорий и выберите меню Set Working Folder. В появившемся окне указываем папку на собственном компьютере.
Рабочую директорию установили, теперь щелкаем правой кнопкой по нужной папке (которую нужно забрать с сервера) и выбираем пункт Get last version. Если забираемая директория содержит поддиректории, то в появившемся окне необходимо выбрать Recursive, чтобы с сервера были скопированы все папки рекурсивно.
Когда файлы копируются с сервера на локальную машину, то им банально устанавливается признак – только для чтения. Никто не мешает снять этот признак в любом файловом менеджере и изменить исходный код. Да, это вполне возможно, но рекомендуется к использованию только в очень крайних случаях. Например, когда кто-то из программистов заблокировал файл под собой и ушел в отпуск, а вам нужно исправить баг и обновить версию программы.
В штатном режиме, прежде чем вносить изменения в исходный код, необходимо сначала забрать необходимые файлы из базы данных VSS. Для этого, выделяем нужные файлы, щелкаем правой кнопкой и выбираем Check out. В VSS такие файлы будут помечены красным цветом, а в колонке User появиться имя пользователя, который забрал файл. Одновременно, со всех файлов, которые вы забрали, будет автоматически снят признак Read only, и файлы можно будет смело изменять.
Когда изменение файлов завершено, их нужно отпустить. Для этого снова выделяем нужные файлы и в контекстном меню выбираем Check in. Измененная версия будет закачена на сервер, а локальные копии тут же станут доступны только для чтения.
Во-первых, перед каждым блокированием, я бы порекомендовал всегда забирать последнюю версию. Заведите привычку, после выделения файлов, перед блокировкой сначала выбрать из контекстного меню Get last version. По идее, во время операции Check out программа VSS должна проверять наличие на сервере более новой версии и обновлять ее. Но на практике это бывает не всегда. Если какой-то файл не будет обновлен, то изменения могут быть потерянными. Да, их можно будет потом найти в истории, но сливать с вашими изменения может быть проблематично.
Когда забираете модуль, то обязательно забирайте связанные файлы. Для C++ это значит, что нужно забирать не только .cpp файл, но и .h.
Для Delphi это более важно, потому что .pas и .dfm файлы очень сильно связаны. Если забрать только визуальную .dfm форму и поставить на нее компонент, то в исходном коде .pas информация о компоненте будет отсутствовать из-за того, что он доступен только для чтения. Проект после этого не соберется.
Теперь поговорим о том, что необходимо размещать в базе данных VSS, а что не стоит. Конечно же, на сервер должны заливаться все файлы исходного кода, и вспомогательные модули. Для Delphi это файлы .dfm и .pas, а для С++ это .cpp и .h файлы. Я не рекомендую помещать на сервер промежуточные файлы и те файлы, которые генерируются во время компиляции. Например, если в VSS будут лежать файлы .obj (для С++) или .dcu (для Delphi), то локальные копии автоматически будут помечены, как доступные только для чтения. Зачем? Ведь у нас есть исходный код, и промежуточные файлы во время компиляции всегда могут быть созданы и всегда будут корректны. Иначе, компиляция может быть завершиться провалом, только из-за одного некорректного промежуточного файла.
Конечный (исполняемый) файл также нет смысла выкладывать в VSS. В этом случае, компилировать сможет только один человек, который заблокировал исполняемый файл под собой. Остальным придется снимать признак Read only в своей локальной файловой системе.
Внимание!!! Если ты копируешь эту статью себе на сайт, то оставляй ссылку непосредственно на эту страницу. Спасибо за понимание
Паника, что-то случилось!!! Ничего не найдено в комментариях. Срочно нужно что-то добавить, чтобы это место не оставалось пустым.
Программист, автор нескольких книг серии глазами хакера и просто блогер. Интересуюсь безопасностью, хотя хакером себя не считаю
Copyright © 2024 Михаил Флёнов. Тираж 1 штука. Отпечатано на ноутбуке. А за права отвечаю, или постараюсь.
А здесь еще и копирайт поставлю: Professional Web Development.
На сайте используются Cookie. Если вы из ЕС или Калифорнии США, то вы должны согласиться с их использованием - Согласен. Если вы из нормальной страны, то вам пох.
Добавить Комментарий