Управлять наёмными рабочими и распределенными проектами — это просто и весело. Стоп, что за чушь? На помощь приходит хороший контроль версий — именно то, что вам нужно, чтобы правильно вести ваши проекты.
Далее — перевод статьи Collaborate and Connect with Subversion. Это мой первый перевод, поэтому был бы очень рад вашим замечаниям.
Представьте, что у вас своя веб-студия. Быть может, это лишь вы и еще пара людей. Из-за столь небольшого состава вы часто прибегаете к помощи наёмных рабочих (субподрядчиков). Благодаря этому, вы можете браться за большее количество проектов, зарабатывать больше денег и аккуратно масштабировать свой бизнес. Однако управление даже небольшим количеством наёмных рабочих требует большого напряжения и сил. На определенном этапе вы столкнетесь с тем, что субподрядчик не выполняет свои обязанности в срок, не соблюдает ваши стандарты качества, или, что еще хуже, исчезает, так и не завершив работу. Вам могут помочь тщательные проверки данных, твердые соглашения и активный менеджмент. А технологии, в свою очередь, могут улучшить совместную деятельность для того, чтобы ваши проекты всегда были под контролем. Встречайте — Subversion.
Subversion (SVN) — это система контроля версий, которая позволяет хранить и следить за изменениями вашего кода, совместно использовать файлы проекта и предоставлять к ним доступ. Это очень просто. Вы пишете код и отправляете (commit) его в ваш SVN-репозиторий (место, в котором хранятся файлы проекта). Участники вашей команды могут скачать эти файлы, посмотреть, что вы сделали, внести свои изменения и затем, снова отправить эти изменения SVN-репозиторию. Каждый такой «commit» считается ревизией. SVN отслеживает эти ревизии и присваивает им номера, так что вы всегда можете «откатиться» к предыдущей версии вашего кода.
Благодаря Subversion, все участники вовлечены в проект: как только кто-то вносит изменения, остальные сразу могут их увидеть (см. ниже Необходимые инструменты). Если у вас надежные субподрядчики, вы не будете лишний раз волноваться. Однако, при работе с непроверенными людьми, такая видимость позволяет избежать всех разногласий, проблем в проекте и ошибок в коде до того, как настанет время принимать работу.
Если субподрядчики действительно хотят сотрудничать с вашей студией, заставьте их следовать вашему рабочему процессу и использовать те же средства. Различия могут серьезно затруднять деятельность небольших компаний, особенно компаний по работе с клиентами.
Некоторые наёмные рабочие, быть может, захотят отправить вам результаты работы . zip-файлом по почте или выложить их на удаленном сервере, чтобы вы скачали и посмотрели. Это, конечно, хороший способ, но так принадлежащий вам код находится за пределами вашей организации. Фактически, вы теряете контроль над проектом. Каково же решение? Сделайте SVN частью вашего рабочего процесса. Помимо обычных преимуществ, вроде версионности и одновременной работы множества людей над проектом, SVN заставляет ваших субподрядчиков быть более ответственными, а также позволяет держать код и файлы для ваших клиентов под контролем и в вашей собственности.
Поскольку вы — наниматель, вы имеете полное право оговорить правила сдачи, используемые средства, а также когда и как работа должна быть сделана. Ваши субподрядчики оценят серьезный рабочий процесс и будут более ясно осознавать, что действуют вместе с вами.
Процесс не должен быть применен только потому, что это процесс. В зависимости от уровня ответственности наёмного рабочего, вы можете решить не включать его в ваш SVN. А когда это сделать — вы увидите сами.
Каждый использует Subversion по-разному. Кто-то любит отправлять изменения проекта по несколько раз за день. Другие же предпочитают работать над проектами и отправлять изменения в конце рабочего дня. Многое зависит от типа проекта, над которым вы работаете, а также от количества людей, работающих над одним и тем же кодом. Я обнаружил, что чем ближе завершение проекта, тем больше изменений, происходящих в течение короткого периода времени. На этом этапе я отправляю изменения в SVN чаще.
Установите, насколько часто вы ожидаете обновлений от ваших наёмных работников. Я рекомендую не менее одного раза в день, пока они работают над проектом.
Мы ведь не просто получаем больше управления в свои руки? Конечно. Теперь вы можете оценивать качество и количество выполняемой субподрядчиками работы за определенное время. Вы способны быстро оценивать продуктивность ваших наёмных рабочих, и им это тоже полезно — вам не нужно приставать к ним с просьбами закончить работу, пока вы работаете вместе.
Субподрядчики могут беспокоиться, что при таком порядке им не заплатят за работу. Ведь, действительно, если у вас последняя версия их исходных кодов, что мешает вам присвоить себе работу, не заплатив при этом. Subversion, сама по себе, не разрешает данную ситуацию, хотя мошенничество может иметь место при любой другой организации рабочего процесса. Убедитесь, что в вашем контракте четко описаны правила сдачи и порядок оплаты работы. В интернете полно ресурсов, где вы можете узнать, как правильно составлять контракт, чтобы полностью защитить себя. Если вы все еще работаете с субподрядчиками без контракта, вам впору задуматься о том, все ли правильно вы делаете.
Чтобы начать пользоваться SVN и понять её основы, прочтите статью «I Wonder What This Button Does» автора Mike West. Ещё один хороший и бесплатный ресурс — O’Reilly «Version Control with Subversion». Не забудьте прочитать хороший обзор по работе с SVN в главе Фундаментальные понятия.
SVN, сама по себе, может быть сложной при попытках управлять пользователями с различными правами доступа. К примеру, вы наверняка захотите, чтобы ваш субподрядчик имел доступ только к тому проекту, над которым он работает, а не ко всему репозиторию. Для упрощения работы с репозиторием и управлением пользователями я рекомендую Warehouse, веб-интерфейс к Subversion от Active Reload. Warehouse позволяет вам легко управлять репозиторием, следить за изменениями, и, самое важное, добавлять пользователей и устанавливать им права доступа. Управление пользователями в SVN может быть довольно утомительным, но, благодаря данному интерфейсу, вы можете легко добавлять и удалять их. Он также предоставляет RSS-ленту с изменениями репозитория, которая позволит вам и вашей команде отслеживать файлы, над которыми ведется работа в данный момент, а также все изменения, происходящие в системе. Существуют также решения, использующие свой хостинг, например, Beanstalk. Они будут располагать у себя ваш SVN-репозиторий и предоставлять пользовательский интерфейс к нему.
Хотя я настоятельно призываю людей сначала научиться пользоваться SVN из командной строки, вы также можете попробовать новое приложение под Mac OS X — Versions (в настоящее время в бета-версии). Оно предоставляет графический интерфейс к большинству команд SVN.
Добавление Subversion в ваш текущий рабочий процесс не должно происходить со скрежетом. При наличии определенных навыков, можно соединить SVN с вашими инструментами управления проектами. Существуют так называемые «события репозитория», при возникновении которых, SVN позволяет запускать любые ваши скрипты. Например, скрипт, который будет писать новое сообщение в приложение-чат Campfire от 37Signals каждый раз, когда вы отправляете изменения в SVN-репозиторий. Таким образом, вы оповещаете ваших сотрудников о сделанных вами изменениях. С помощью Google, вы найдете множество других скриптов, написанных под различные инструменты, включая интеграцию средства управления проектами Basecamp с SVN.
Существует несколько различных типов встраивания SVN, но, всё же, наиболее распространен тот, что запускает скрипт после успешной отправки изменений репозиторию. Благодаря таким скриптам, возможности по совместному использованию SVN и ваших привычных рабочих средств практически неограниченны.
Subversion — это не только отличное средство для версионности и контроля кода ваших проектов, оно также позволяет контролировать и улучшать взаимодействие между вами, вашими сотрудниками и наёмными рабочими. Пора немного улучшить жизнь себе, своей компании и своим субподрядчикам — начните применять SVN в своей работе уже сейчас.
Оригинал статьи — Collaborate and Connect with Subversion.
Translated with the permission of A List Apart Magazine and the author[s].
комментарии (94)
Ответ на вопрос, что позволяет делать тот или иной инструмент, к процессу отношения не имеет.
почему-то западные "специалисты" любят разводить такой трёп.
Перевод хороший, но лучше заниматься переводом мануалов чем такой ерунды.
Хотелось бы более подробного описания использования инструментов для решения задач.
И по самой статье насчет ожиданий:
Я считаю, что коммиты должны быть не "каждый час" или "после каждых 100 строк код", а логически целостными: то есть решил какую-то задачу (пусть даже исправил важную ошибку всего в одной строке) — закоммить и прокомментрируй что сделал. В этом случае процесс разработки будет представлять собой последовательность целостных шагов. В последствии может оказаться так, что какие-то шаги были ошибочными, их можно будет откатить. А если коммит делался абы когда зато по графику, чтобы показать активную работу, то шаги и откаты будут бредовые.
Ну и считается полезным коммитить к конце рабочего дня. Из тех же соображений, что элементарная задача не должна занимать больше 8 часов.
Когда мне потребовалось внести большие изменения в проект (в котором я единственный разработчик) я сделал отдельную ветку, все сделал, протестил и потом слил с основной.
Вопрос: нафига такие мучения?
Во-первых, это оказалось совсем несложно - merge и все ок.
Во-вторых, изменения заняли порядком времени, параллельно в основной ветке я решал основные рабочие задачи (которые нужно было сделать к определенному сроку). Если бы я делал все одновременно, то получил бы жуткую кашу в проекте и проблемы с работоспособностью в переходный период.
Но все же мне не показалось это настолько сложным: вначале copy, а потом merge. Или у вас возникали конфликты при слиянии веток? В этом плане у меня ситуация проще.
я умом вроде понимаю что ничего тут страшного нет, и что это хорошо и правильно. Наверное просто был отрицательный опыт который не хочется повторять.
когда меняются интерфейсы\слои.
http://en.wikipedia.org/wiki/Comparison_of_revision_control_software
http://www.collab.net/downloads/subversi… - сервер и консольный клиент
http://tortoisesvn.tigris.org/ - визуальный клиент под винду
А также многие IDE поддерживают работу с сервером.
Я как раз подбираю средство для удобного просмотра репозитария и упрвления багами. Пока хочу попробовать Trac.
По описанию очень похожий инструмент. В чем его преимущество?
Понравилось наличие календаря и встроенного Ганта, только последний показался крайне сложным в поддержании адекватной структуры задач.
А какие еще аналоги знаете, чтобы можно было сравнить и подобрать для себя оптимум?
Мы используем в качестве багтрекера Atlassian JIRA. Очень, очень навороченный продукт
(легко настраиваемый впрочем).
Есть интеграция с SVN - можно в коммитах забивать номера карточек
и собственно в карточках просматривать чего там девелоперы накоммитили.
Посмотрите, триал-версия полностью функциональна и разворачивается на раз.
На самом деле написать подробный комментарий требует на 1 минуту больше, а вспомнить через полгода зачем ты это сделал - минут 15 :)
Т.е. не требовать развернутого комментария в момент коммита, пусть пишет «Task 1235» (а это проверяется регэкспом хук-скрипта на pre-commit), а суть изменений фиксирует в логе задачи. Тогда становится легко по каждой задаче вытащить список ревизий и даже патч.
Но надо понять в чем его кардинальные преимущества лично для нас.
Эх.. ещё бы сделали что-нибудь подобное для БД....
Мержить в ручном режиме тоже.
http://tortoisesvn.net/docs/release/TortoiseSVN_en/tsvn-automation.html
можно повесить на обычный ярлык коммит всей папки проекта
итого требуется два клика: запуск коммита и нажатие ОК
а если использовать Komodo Edit, то можно там сделать запуск комманды через Alt+S
а если еще и в Linux'e работать, то никакого ОК не надо жать! =)
у нас он тупит на коммитах хотя хост локальный (192.168...)
просто берет и на пару (две-пять, как когда) секунд замирает.
Возможно кто-то сталкивался с этой проблемой.
Подскажите, пожалуйста, решение (гуглил)
p.s. и я знаю, это не форум, но это проблема svn и кому-то информация может пригодиться =)
svnserve -d, standalone, не резолвит ИП клиентов
а что имеется ввиду под локальной ДНС зоной? у нас коммиты идут к локальному ip
Единственное что не удаеться решить с ее помощью - это синхронизацыю бд между разработчиками. Писать в комментариях при коммитах sql-запросы всеже не очень удобно.
Может есть у кого опыт решения подобной проблеммы?
Можно вести историю изменений базы в SQL-скриптах и в коммитах кода давать номера ревижнов, которые надо применить.
Это скорее не технологическая а административная проблема :)
Как вариант: складываем скриптики для изменения базы в отдельную папку. Каждое изменение — в свой скрипт под номером.
Умеет сравнивать структуры двух баз по дампам и выдавать «патч» — sql-скрипт, применив который, вы приведете базу к нужной структуре.
Если бы еще прикрутить ее ввиду плагина к SVN, чтобы можно было получать такие патчики.
для баз со сложной структурой (~1000 таблиц,~500 вьюх и огромное количество API-шных пакетов).
Причём, зачастую приходится отслеживать не только структуры - но и сами данные
(метаинфа, классификаторы и справочники).
В таких случаях спасает только внесение изменений базы в отдельную ветку репозитория(SQL-скрипты с изменениями относительно пустой модели данных или же дампы)
В наличии версии для MySQL, SQL Server, PostgreSQL, InterBase/Firebird, Oracle и DB2
Выводит все различия между базами и сразу предлагает изменения в виде sql-запросов.
Как вы предлагаете использовать эти утилиты в случае если база-источник изменений в одном городе
а базы-потребители - в других? ;)
Imho какой то сомнительный способ синхронизации баз для использования
в качестве решения.
Как разовый вариант - не спорю, полезная фича.
И, сия тулза сравнивает структуры или может и данные сравнивать?
Как вариант, я думаю, можно настроить репликацию.
Слишком много телодвижений и, как следствие,
бардак. Проще всё же не "тулзы" использовать
а написать регламент по порядку внесения изменений
в БД и следовать ему,
выкладывая изменяющей стороной дампы И/ИЛИ SQL-скрипты,
актуализующие состояние БД.
Система управления версиями. При чём тут "контроль"?