Pull to refresh

Организовываем работу небольшой команды программистов на opensource

Reading time7 min
Views2.6K
Хотели бы Вы знать, кто и когда поменял строчку n в одном из файлов исходного кода вашей программы или сайта? Хотели бы Вы иметь возможность отменить изменения в коде, сделанные неделю назад, уже после того, как была готова новая фича? Хотели бы Вы сделать работу двух или более программистов над одним проектом прозрачной, простой и легко контролируемой? А может Вы хотите иметь возможность иметь доступ к исходникам строй версии программы при этом, не заботясь о своевременных бэкапах?
Хорошие новости: все это, возможно, более того, это просто и бесплатно. В данной статье я расскажу, как это сделать.

Кому это надо?


Данная статья писалась для тех, кто еще не пользуется системой контроля версий. Возможно, не слышал о таковых, а возможно боялся поставить, думая, что это очень сложно или требует каких-то особенных технических средств (своего сервера и т.п.).
Тем айтишникам, кто дорос до уровня, когда самому писать код уже лень, а доходы позволяют нанять кого-то себе в подмогу, статья будет вдвойне полезна, поскольку я расскажу о варианте налаживания рабочего процесса с наемными людьми, когда задачи и их выполнение отслеживаются при помощи СВЯЗКИ багтрекера Mantis и Subversion.
Итак, приступим…

История о нас


Не так давно я «дорос» до уровня, когда могу позволить себе нанять людей для написания кода моих программ. Первый мой сотрудник  - это студент 2го курса, который умел программировать. Я ему писал задания, он их выполнял, приходил ко мне и показывал, что сделал. Мы обсуждали недостатки и достоинства программы, и он уходил ее доделывать. Найденные ошибки и пожелания записывались в TXT файл, а когда студент приходил ко мне вновь с новой версией программы, в этом фале уже стояли «+» и «-» напротив каждого из заданий.
Очень быстро стало понятно, что так работать нельзя. Отслеживать, что было сделано не так, пожелания по отдельным конкретным недостаткам, было очень неудобно. Часть терялась, часть удалялась нечаянно и т.д. Не помог даже переход на Word… J
Решением проблемы стала установка Mantis. Mantis – это система для работы с ошибками, расположенная на сервере. Проще говоря, удобный интерфейс, который позволяет отслеживать работу над конкретной ошибкой и комментировать процесс выполнения. База данных расположена на сервере, поэтому, все, что Вам нужно для работы с Mantis – это подключение к интернету. Это не единственная такая система, есть целая куча аналогов. Из них самый популярный – это BugZilla. Но лично мне по удобству Mantis нравится больше, поэтому выбор остановился на нем.
После установки Mantis процесс работы стал происходить по-другому:
  • Я пишу техническое задание, даю его программисту.
  • В процессе выполнения, он делает промежуточные версии, которые присылает мне по почте.
  • Я проверяю их и все ошибки и пожелания, которые у меня возникают, я заношу в Mantis.
  • В следующий раз я получаю программу, где выполнен еще какой-то кусочек ТЗ, плюс закрыты все или часть ошибок в Mantis. Я проверяю программу вновь. Через Mantis я закрываю ошибки, если вижу, что они исправлены. Если нет — то открываю ошибку вновь и добавляю свой комментарий, что мне не нравится. В результате программист опять получает список исправлений, которые он должен внести.
  • Все повторяется по кругу до тех пор, пока ТЗ не будет выполнено полностью и все ошибки не будут закрыты.

Такой подход просуществовал более года. Действительно это тот минимум, который позволяет отслеживать процесс выполнения и примерно планировать сроки. Но недостатки такого подхода заставляют искать новый вариант организации труда:
  • Мне приходится ждать, пока программист пришлем мне новую версию кода, в которой аккумулированы десяток-другой, изменений. Т.е. я не могу сразу приступить к проверке.
  • Учитывая, что я получаю сразу много исправлений, проверять код программиста практически невозможно: сложно проследить логику.
  • Приходится накапливать архивы для каждого нового билда, который мне присылает программист. Очень внимательно надо нумеровать версии, чтоб потом понять, что за  чем шло. А воссоздать, что было сделано на этапе версии 0.0.6, когда вы уже работаете над 0.0.12 архисложно.
  • При таком подходе работа двух программистов над одним проектам затруднена настолько, что можно считать, что она просто невозможна. Это самое главное!

Последний недостаток исправляется при помощи Subversion. О нем мы поговорим ниже. Но помимо него, еще есть ряд мелочей, которые делают работу нескольких программистов не просто возможной, но и удобной! Чтобы понять это, я поработал на нескольких работодателей. Результат, о котором я рассказываю сейчас – это опыт, который у меня появился благодаря «работе на дядю». Могу сказать, что далеко не у всех сделано так удобно, как у меня, и я этим безумно горжусь :).

Организация рабочего процесса у нас



Вот как процесс создания программы организован у нас сейчас.
  1. Я пишу техническое задание. Задание разбивается на подзадачи. Все подзадачи заносятся отдельными багами в Мантис. Помимо этого, для каждой задачи проводится оценка времени и данная оценка заносится в Excel (увы, пока только в него :(, можно и удобнее…). Благодаря Excel я примерно представляю, когда я получу готовую первую версию программы, а программист имеет список задач в Mantis и техническое задание, где подробно описано что и в каком порядке делать.
  2. Для каждой новой программы я создаю новый Subversion репозиторий (хранилище для кода). Добавляю аккаунты для себя и программиста.
  3. Программист создает у себя рабочую копию репозитория, в которой и работает в дальнейшем.
  4. Выполнив какую-то подзадачу, программист делает Commit в репозиторий и закрывает багу. Во время Commit-а, автоматически:
  5. Получив письмо, я могу сразу же обновить рабочую версию кода у себя, проверить ту часть кода, что была изменена (т.е. связана с конкретной задачей) и написать какой-то комментарий, если это требуется, или переоткрыть ошибку.

Такой способ организации позволяет достичь следующего:
  • Над проектом могут работать много людей.
  • Помимо того, что тестеру (у нас в его роли выступаю я) не надо ждать новой версии, удается добиться снижения затрат времени программиста на ее дополнительное исправление (когда баг переоткрывается): программисту легче внести дополнительные изменения «по горячим следам».
  • Получить все бонусы от работы с 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 у себя на компьютере...

UPD: Вторая сатья с пошаговым писанием процесса установки Subversion на Windows XP и инструкцией по привязыванию камитов к Mantis находится тут. Если кому хочется держать код своей программы у себя и при этом хочется удобной организации работы — статья для вас.
Tags:
Hubs:
Total votes 28: ↑14 and ↓140
Comments25

Articles