Без дизайна иконок: Репозиторий Subversion на своем компьютере
Хотели бы Вы знать, кто и когда поменял строчку n в одном из файлов исходного кода вашей программы или сайта? Хотели бы Вы иметь возможность отменить изменения в коде, сделанные неделю назад, уже после того, как была готова новая фича? Хотели бы Вы сделать работу двух или более программистов над одним проектом прозрачной, простой и легко контролируемой? А может Вы хотите иметь возможность иметь доступ к исходникам строй версии программы при этом, не заботясь о своевременных бэкапах?
Хорошие новости: все это, возможно, более того, это просто и бесплатно. В данной статье я расскажу, как это сделать.
А причем тут студия дизайна иконок?
Прежде всего, хочу объяснить, почему некто из студии, основной задачей которой является дизайн как таковой и дизайн иконок в частности, пытается давать советы программистам. Ответ очень прост, я и сам программист, шароварщик, который не так давно «дорос» до использования Subversion. Пока впечатление от работы с Subversion свежи, спешу поделиться ими, а то подом просто не будет желания.
А что до дизайна иконок, то в данной студии я лишь менеджер, а дизайном занимаются дизайнеры под моим руководством. Так что в данном случае с Вами говорит «коллега по цеху».
Кому это надо?
Данная статья писалась для тех, кто еще не пользуется системой контроля версий. Возможно, не слышал о таковых, а возможно боялся поставить, думая, что это очень сложно или требует каких-то особенных технических средств (своего сервера и т.п.).
Тем шароварщикам, кто дорос до уровня, когда самому писать код уже лень, а доходы позволяют нанять кого-то себе в подмогу, статья будет вдвойне полезна, поскольку я расскажу о варианте налаживания рабочего процесса с наемными людьми, когда задачи и их выполнение отслеживаются при помощи СВЯЗКИ багтрекера Mantis и Subversion.
Итак, приступим…
История о нас
Не так давно я «дорос» до уровня, когда могу позволить себе нанять людей для написания кода моих программ. Первый мой сотрудник - это студент 2го курса, который умел программировать. Я ему писал задания, он их выполнял, приходил ко мне и показывал, что сделал. Мы обсуждали недостатки и достоинства программы, и он уходил ее доделывать. Найденные ошибки и пожелания записывались в TXT файл, а когда студент приходил ко мне вновь с новой версией программы, в этом фале уже стояли «+» и «-» напротив каждого из заданий.
Очень быстро стало понятно, что так работать нельзя . Отслеживать, что было сделано не так, пожелания по отдельным конкретным недостаткам, было очень неудобно. Часть терялась, часть удалялась нечаянно и т.д. Не помог даже переход на Word… J
Решением проблемы стала установка Mantis. Mantis – это система для работы с ошибками, расположенная на сервере. Проще говоря, удобный интерфейс, который позволяет отслеживать работу над конкретной ошибкой и комментировать процесс выполнения. База данных расположена на сервере, поэтому, все, что Вам нужно для работы с Mantis – это подключение к интернету. Это не единственная такая система, есть целая куча аналогов. Из них самый популярный – это BugZilla. Но лично мне по удобству Mantis нравится больше, поэтому выбор остановился на нем.
После установки Mantis процесс работы стал происходить по-другому:
- Я пишу техническое задание, даю его программисту.
- В процессе выполнения, он делает промежуточные версии, которые присылает мне по почте.
- Я проверяю их и все ошибки и пожелания, которые у меня возникают, я заношу в Mantis.
- В следующий раз я получаю программу, где выполнен еще какой-то кусочек ТЗ, плюс закрыты все или часть ошибок в Mantis. Я проверяю программу вновь. Через Mantis я закрываю ошибки, если вижу, что они исправлены. Если нет - то открываю ошибку вновь и добавляю свой комментарий, что мне не нравится. В результате программист опять получает список исправлений, которые он должен внести.
- Все повторяется по кругу до тех пор, пока ТЗ не будет выполнено полностью и все ошибки не будут закрыты.
Такой подход просуществовал более года. Действительно это тот минимум, который позволяет отслеживать процесс выполнения и примерно планировать сроки. Но недостатки такого подхода заставляют искать новый вариант организации труда:
- Мне приходится ждать, пока программист пришлем мне новую версию кода, в которой аккумулированы десяток-другой, изменений. Т.е. я не могу сразу приступить к проверке.
- Учитывая, что я получаю сразу много исправлений, проверять код программиста практически невозможно: сложно проследить логику.
- Приходится накапливать архивы для каждого нового билда, который мне присылает программист. Очень внимательно надо нумеровать версии, чтоб потом понять, что за чем шло. А воссоздать, что было сделано на этапе версии 0.0.6, когда вы уже работаете над 0.0.12 архисложно.
- При таком подходе работа двух программистов над одним проектам затруднена настолько, что можно считать, что она просто невозможна. Это самое главное!
Последний недостаток исправляется при помощи Subversion. О нем мы поговорим ниже. Но помимо него, еще есть ряд мелочей, которые делают работу нескольких программистов не просто возможной, но и удобной! Чтобы понять это, я поработал на нескольких работодателей. Результат, о котором я рассказываю сейчас – это опыт, который у меня появился благодаря «работе на дядю». Могу сказать, что далеко не у всех сделано так удобно, как у меня, и я этим безумно горжусь :).
Организация рабочего процесса в ArcticLine Software
Вот как процесс создания программы организован у нас сейчас.
- Я пишу техническое задание. Задание разбивается на подзадачи. Все подзадачи заносятся отдельными багами в Мантис. Помимо этого, для каждой задачи проводится оценка времени и данная оценка заносится в Excel (увы, пока только в него :(, можно и удобнее…). Благодаря Excel я примерно представляю, когда я получу готовую первую версию программы, а программист имеет список задач в Mantis и техническое задание, где подробно описано что и в каком порядке делать.
- Для каждой новой программы я создаю новый Subversion репозиторий (хранилище для кода). Добавляю аккаунты для себя и программиста.
- Программист создает у себя рабочую копию репозитория, в которой и работает в дальнейшем.
- Выполнив какую-то подзадачу, программист делает Commit в репозиторий и закрывает багу. Во время Commit-а, автоматически:
- В хранилище кода сохраняются все изменения в исходниках, касающиеся только данной подзадачи
- В Mantis, в ту багу, которая связана с данной подзадачей, автоматически добавляется комментарий, в котором описано, кто, когда делал Commit и в какие файлы были внесены изменения.
- Мне на почту приходит сообщение о изменениях, которые были сделаны с подзадачей в Mantis
- Получив письмо, я могу сразу же обновить рабочую версию кода у себя, проверить ту часть кода, что была изменена (т.е. связана с конкретной задачей) и написать какой-то комментарий, если это требуется, или переоткрыть ошибку.
Такой способ организации позволяет достичь следующего:
- Над проектом могут работать много людей.
- Помимо того, что тестеру (у нас в его роли выступаю я) не надо ждать новой версии, удается добиться снижения затрат времени программиста на ее дополнительное исправление (когда баг переоткрывается): программисту легче внести дополнительные изменения «по горячим следам».
- Получить все бонусы от работы с Subversion (бэкап кода, отслеживание его изменений, возможность привлечь к работе несколько людей, которые не имеют доступа к коду друг друга и т.д.), плюс, правильно и логично сформированный журнал изменений.
В большинстве фирм программист добавляет комментарий к Commit-у так, как он хочет. У нас же, помимо самого комментария идет четкая привязка к багу в Mantis. Это дает возможность быстро понять, зачем делались изменения в коде, даже по прошествии нескольких месяцев.
- Для каждой ошибки автоматически создается история изменений, связанная с нею. Это дает возможность отследить, как проходило исправление ошибки шаг за шагом.
- В комментариях, которые автоматически добавляются к багу, присутсвует номер ревизии. Это дает возможность прочитать подробное описание бага (а не скупой комментарий при камите) и сделать осознанный code review.
А теперь, самое интересное…
Что нужно для организации труда нескольких программистов над одним проектом, и сколько это стоит?
Ответ весьма радует. Если вы читаете эту статью, значит, у Вас уже есть все, что нужно: компьютер с подключением к интернету. Не нужен даже выделенный IP адрес :). Ну, разве что для Mantis нужен обычный виртуальных хостинг за $1-$5/мес. Но если Вы шароварщик, то это у Вас есть наверняка.
Сразу оговорюсь, что про установку Mantis я не буду рассказывать. Этот процесс описан во многих статьях, достаточно погуглить немножко. Скажу лишь, что для установки каких-то особых навыков не требуется. Сама установка занимает 20 минут – час. Если Вы не работали с системой, то на то, чтоб разобраться с ней Вам понадобится где-то день.
Будем считать, что у Вас есть свой виртуальных хостинг и на нем уже установлен Мантис. Вы решили организовать работу нескольких программистов над одним проектом. Для этого Вам понадобится Subversion.
Что такое Subversion?
Subversion—это свободная система управления версиями с открытым исходным кодом. Subversion позволяет управлять файлами и каталогами во времени. Дерево файлов помещается в центральное хранилище, которое похоже на обычный сервер файлов с тем отличием, что оно запоминает каждое изменение, внесённое в файл или каталог. Это позволяет восстановить ранние версии данных, исследовать историю изменений данных. Благодаря этому, многие считают систему управления версиями своеобразной «машиной времени».
Subversion разработана специально для замены CVS, самой распространённой открытой системы управления версиями. Она обладает всеми основными функциями CVS (хотя некоторые из них выполняет другими способами) и лишена ряда её недостатков.
Subversion часто называют «svn», по названию клиентской программы, входящей в её дистрибутив.
Где можно установить Subversion?
В идеале – на сервере, который работает только на внутрикорпоративную локальную сеть. Но у меня другой случай: все сотрудники удаленщики, поэтому сервер должен предоставлять доступ к репозитарию через интренет.
В моей ситуации, удобно установить Subversion на сервере у хостера. Тогда репозитарий будет доступен 24 часа в сутки с приличной скоростью. Но, увы, тут есть свои недостатки. Если Вы работаете над коммерческим проектом, то кража исходников может нанести весьма ощутимый урон Вашему бизнесу. Дабы защититься от кражи, Вам нужен не виртуальных хостинг, а ВИРТУАЛЬНЫЙ СЕРВЕР. А это удовольствие стоит от 30$/мес. и до ого-го. Кроме того, размещение исходников даже на виртуальном сервере не защищает от нечестного админа, который может слить весь репозитарий на флешку, прямо с компьютера (возможно и паранойя, но мало ли…). При этом ни один хостер своими деньгами и юридически не будет гарантировать сохранность данных :(.
Я выбрал другой способ – держать данные у себя на компьютере с Windows XP. У этого способа есть несомненный плюс – все исходники у тебя и никто их у тебя не украдет. Но скорость доступа к Вашему компьютеру наверняка будет меньше той, которую может дать хостер, да и работать репозиторий у Ваших сотрудников будет только тогда, когда Ваш компьютер включен.
Установка Subversion у себя на компьютере с Windows XP минимальной кровью. Пошаговая инструкция.
1. Качаем необходимый софт
Нам необходимо загрузить сам сервер и клиент для работы с ним. В качестве клиента рекомендую воспользоваться tortoiseSVN, в котором максимально быстро разберется новичок и. Кроме того, для этого клиента доступен русский язык.
Итак, качаем последнюю stable-версию сервера, клиент и русификацию к нему.
Это для самого Subversion. Дополнительно нам понадобится следующий софт:
- No-IP Client – маленькая программка, которая позволит нам избавится от необходимости иметь выделенный IP адрес.
- SVN + Mantis tools, которые включают:
- SVN+Mantis Shell – моя самописная программа, которая позволяет объединить работу Subvesion и Mantis.
- SVNcheckin – модифицированный PHP скрипт из Mantis для тех же целей
- post-commit – BAT файл, для орагинизации связи Mantis+Subvesion на Windows XP.
2. Регистрируемся на No-IP и устанавливаем No-IP Client
Если у Вас есть выделенный IP, то этого делать не надо. К Вам на компьютер можно попасть по нему, а если IP адрес хостер Вам формирует динамически, то без подобной программки не обойтись. Суть сервиса состоит в том, что Вы ставите у себя на компьютер программу, которая постоянно узнает Ваш IP адрес и в случае, если он меняется, отправляет данные на сервер. Обращение происходит через адрес, который Вы выбираете на сервере. Таким образом, к Вашему компьютеру происходит через постоянный «серверный адрес», который связан с Вашим реальным на данный момент IP адресом.
Заходим на http://www.no-ip.com и создаем там бесплатный аккаунт. В аккаунте нажимаем на Add Host. В качестве HostName вбиваем имя вашей компании. В выпадающем списке выбираем понравившееся имя домена. Например, no-ip.biz.
Ставим No-IP Client и вбиваем в него данные только что созданного аккаунта. Все, теперь для того, чтоб кто-то мог обратиться к Вашему компьютеру, достаточно вбить адрес вроде
YourCompanyName.no-ip.biz
3. Устанавливаем Subversion сервер и клиент
Установка проходит легко и непринужденно, везде достаточно нажимать “Next”. Сначала надо устанавливать сервер, потом клиент, затем, если надо, русификацию к клиенту. Я русификацией не пользуюсь. Мне не нравится.
Во время установки не меняйте стандартных путей, которые предлагает инсталлятор.
4. Создаем первый репозитарий (хранилище)
Создаем папочку C:\svn-store\
Заходим в консоль (Пуск->Выполнить, cmd) и пишем:
svnadmin create c:/svn-store/my_project
Обратите внимание на слеши! Они должны указываться именно так, на манер unix. В случае успешного создания репозитория никаких ошибок не появится.
Открываем файл C:/svn-store/my_project/conf/svnserve.conf и раскомментируем строчки:
anon-access = none
auth-access = write
Т.е. мы разрешаем скачивать/закачивать файлы из репозитория только зарегистрированным пользователям. Анонимные пользователи вообще не имеют доступа к репозиторию. Шароварщиками чаще всего используется именно такая политика. Данные о пользователях лежат в файле, который указывается в строчке (которую также нужно раскомментировать):
password-db = passwd
Т.е. так мы показываем, что в папке C:\svn-store\my_project\conf лежит файл passwd c указанием логинов и паролей зарегистрированных пользователей.
Идем в C:\svn-store\my_project\conf\passwd, открыв его любым текстовым редактором, и создаем учетные записи пользователей в секции users. Формат их таков:
UserName1 = UserPassword1
UserName2 = UserPassword2
5. Устанавливаем Subversion как службу Windows*
Это нужно для того, чтоб не надо было запускать сервер каждый раз, как Вам он нужен. Subversion сервер будет автоматически стартовать при запуске.
Заходим в консоль (Пуск->Выполнить, cmd) и пишем:
sc create SVNserve binpath= "C:\Program Files\Subversion\bin\svnserve.exe --service -r C:\svn-store" displayname= "My Repository" depend= Tcpip
Данная команда создаст новый сервис с именем «My Repository». Если в будущем его захотите удалить, то надо будет остановить службу, а в консоли набрать:
sc delete SVNserve
Идем в окно управления службами: Пуск> Выполнить>Набираем services.msc. В открывшемся окне находим службу My Repository, заходим в ее свойства и выбираем тип запуска Авто.
Стартуем службу.
* Комментарий: С выходом версии 1.5, SVN и так ставит себя как службу, этот шаг можно пропустить.
6. Заполняем репозиторий исходными данными
Нам необходимо произвести импорт, начальное наполнение нашего репозитария. Для этого создаем папку C:\Repository, а в ней три пустые подпапки: trunk, branches и tags. Заходим в папку C:\Repository, щелкаем правой кнопкой мыши на свободном месте и выбираем TortoiseSVN->Import…
В качестве URL вводим:
svn://YourCompanyName.no-ip.biz/my_project/
Как видите, это тот УРЛ, который мы определили на втором шаге, плюс имя папки, где хранится репозиторий.
Нажимаем OK. У вас должны спросить логин и пароль. Указывайте те данные, которые внесли в C:\svn-store\my_project\conf\passwd. Если вместо окошка для ввода логина и пароля вы не увидели, возвращайтесь к пунктам про правку C:\svn-store\my_project\conf\svnserve.conf и C:\svn-store\my_project\conf\passwd - вы либо не раскомментировали строчки, либо не указали логины/пароли.
В случае успешного заполнения вы увидите нечто подобное:
7. Настраиваем Subversion для работы с Mantis
1) Создайте временную папку C:\Temp. Выделите папку правой кнопкой мыши и в контекстном меню выберите SVN Checkout…
В качестве URL of repository введите svn:// YourCompanyName.no-ip.biz/my_project/. Checkout directory должен быть равен C:\Temp. Других настроек не меняйте и нажмите OK. В результате в папке C:\Temp появится три папки, созданные на прошлом шаге, и служебная папка .svn. Не трогайте ее в будущем.
2) Нажимаем правой кнопкой мыши опять на C:\Temp и выбираем TortoiseSVN->Properties. В появившемся окне выставляем свойства так, как показано на рисунке. При этом ОБЯЗАТЕЛЬНО при добавлении каждого нового свойства выставляйте галочку «Apply property recursively»:
Теперь нажимаем правой кнопкой мыши на C:\Temp и выбираем SVN Commit…
После ввода комментария как на рисунке, нажимаем OK. TortoiseSVN ругнется, что мы не ввели номер ошибки. Игнорируем это.
3) Заливаем на сервер скрипт svncheckin.php. Он должен находится в подпапке core той папки, где установлен Mantis. В результате путь обращения к скрипту будет выглядеть как:
http://URL-TO-MANTIS/core/svncheckin.php
4) Идем в папку C:\svn-store\my_project\hooks и копируем туда файлы
- post-commit.bat
- svn_checkin_shell.exe
- svn_checkin_shell.ini
Открываем svn_checkin_shell.ini и вставляем туда правильный путь к svncheckin.php. Проверяем другие пути в INI файле. Если Вы все делали, как я писал раньше, то ничего менять не надо. Если Вы меняли какие-то пути, то их также надо будет подправить в файле post-commit.bat.
5) Идем в Mаntis, логинимся в него под админом и создаем нового пользователя: “SVN Bot”. Назначаем ему права Developer-а и назначаем его НА ВСЕ активные проекты. Все автоматические комментарии теперь будут писаться от имени SVN Bot.
Также создаем в нашем проекте новый баг. Называем его, например, «Тестирование связки SVN + Mantis». Запоминаем номер бага.
7. Импортируем исходный код проекта в репозитарий
Процесс аналогичен шагу 6. 1) Идем в папку с проектом, щелкаем правой кнопкой мыши на свободном месте и выбираем TortoiseSVN->Import…
В качестве URL вводим:
svn://YourCompanyName.no-ip.biz/my_project/trunk
Обратите внимание, в конце указана папка trunk. Нажимаем ОК.
Теперь выполняется заливка данных в репозитарий. Если у Вас большой проект и много фалов, то скорее всего она займет много времени.
После того, как увидите надпись «Completed At revision…» можете вздохнуть с облегчением. Подготовительный этап работ закончился :).
Повседневная работа с tortoiseSVN
Мы выполнили все необходимые действия. Теперь я вкратце расскажу, о рутине: повседневной работе.
Вся работа с кодом проходит в рабочих копиях проекта. У каждого из разработчиков своя рабочая копия. Поэтому первое, что должен сделать разработчик, для того, чтоб приступить к работе над проектом – это создать у себя локальную рабочую версию.
Затем, каждый раз перед тем, как начать работу над новой фичей или багом, программист обновляет рабочую копию (SVN Update). После того, как изменения кода закончены, разработчик делает SVN Commit. Если так делать, то над проектом спокойно могут работать несколько человек. Это очень кратко. Подробнее написано в электронной книге по tortoiseSVN. Ссылка на нее расположена в конце статьи.
Что ж, выполним одну итерацию для того, чтоб проверить, что все настроено правильно.
1. Создаем рабочую копию репозитория на локальном компьютере.
Создайте пустую папку и вызовите в ней по правой кнопке мыши “SVN Checkout…”. URL тот же:
svn:// YourCompanyName.no-ip.biz/my_project/trunk
Так вы загрузите в данную папку рабочую копию проекта из репозитария. Кроме файлов проекта в ней появится скрытая папка “.svn” - ее ни в коем случае не трогайте, она используется SVN во время фиксации (commit’a) изменений в репозитарий.
Сейчас все папки помечены зелеными галочками. Это значит, что ни один файл не был изменен. Когда мы внесем изменения в какой-то из файлов, он автоматически будет отмечен красным восклицательным знаком. Это очень удобно.
2. Вносим изменения в проект, чтоб убедится в правильности работы SVN
Вы можете делать хоть что (не считая папки .svn и ее содержимого, которые трогать нельзя) - создавать/править/удалять файлы проекта. Я ограничился изменением содержимого одного текстового файла.
Для записи изменений в репозитарий щелкните правой кнопкой мыши в папке и выберите “SVN Commit …”. Введите описание камита в поле Message и ОБЯЗАТЕЛЬНО номер тестовой багги, которую мы создали в Mantis.
Нажмите OK.
После того, как закончится добавление данных в репозитарий, откройте Mantis и зайдите в тестовый баг. Последним комментарием будет автоматически сгенерированный отчет о камите от SVN Bot. Будет что-то на подобии этого:
Для написания статьи использовались материалы
Update
Упустил одну тонкость. Чтобы все работало, надо поправить в mantis файл config_inc.php. Нужно добавить строчки:
$g_source_control_account = 'svn';
$g_source_control_regexp = '/\b(?:bug|issue)\s*[#]{0,1}(\d+)\b/i’;
Спасибо за Ваши комментарии.
--
Спасибо за внимание, успехов
Роман Рудник
** Перепечатывание материала статьи допускается только с разрешения автора (пишите через контактную форму на сайте) и с обязательной ссылкой на сайт студии.
|
