Переход к исходному контролю

Наша небольшая компания (3-4 программиста и 3-4 дизайнера сайтов) разрабатывает специализированное веб-приложение на PHP, которое обеспечивает функциональность для более чем 100 веб-сайтов. Мы работали в течение нескольких лет в отдельной среде разработки и производства, которая работала довольно хорошо. Всегда было разработано достаточно отдельных функций, чтобы программисты никогда не сталкивались, и было удобнее работать без контроля исходного кода; даже при том, что у него был риск потери данных, и у нас была большая доля файлов, пропавших без вести в результате непреднамеренного движения.

Другое соображение заключается в том, что наши дизайнеры не разбираются в технологиях (я ввел их в html-разметку вместо использования WYSIWYG). Это было одной из причин колебаться при переходе на управление версиями.

Однако теперь, когда мы достигли более 100 сайтов и команда разработчиков растет, я пытаюсь стандартизировать наши процедуры, и контроль исходного кода кажется логичным шагом для программистов. Я надеюсь, что это также ускорит развертывание наших патчей.

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

1) Делаете ли вы все версии (сайты, CSS, HTML-шаблоны и код приложения) и таким образом заставляете дизайнеров изучать управление версиями? Или это просто разработчики, которые работают над кодом приложения?

2) На какие подводные камни стоит обратить внимание при первоначальной настройке управления источником?

3) Развертывание dev => производственных советов для контроля версий.

Спасибо за все понимание.

Изменить 1: Dang. Все до сих пор рекомендуют все контролировать. Это заставит меня рано потерять волосы. Это, вероятно, вызовет новый вопрос в ближайшем будущем. Спасибо за совет, продолжайте!

Изменить 2: много хороших ответов, и мы будем изучать различные системы контроля версий. Спасибо всем за ответы!

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

Если вы только начинаете, я настоятельно рекомендую использовать распределенную систему контроля версий, такую ​​как git или mercurial . Это общая тенденция в мире, и есть много преимуществ. Работать в автономном режиме легко, без сетевой зависимости и возможности выполнять частную, неполированную работу, все еще находясь под контролем версий, проверяя все централизованно, когда он будет готов.

И не для того, чтобы прибегать к призывам к власти или чему-либо еще, но посмотрите, что Джоэл Спольски должен сказать по этой теме . (Выборочная цитата: «Subversion = Пиявки. Mercurial и Git = Антибиотики».) Среди прочего, он делает интересный вывод, что эти новые системы используют новую ментальную модель, отличающуюся от традиционного контроля версий - именно поэтому, попадая в этот вид подход с самого начала является победой.

Я бы сказал, поставить все под контроль версий. Как только все это заработает, вы можете скопировать его в тег, который для большинства систем SCM не требует много дискового пространства на сервере.

Что касается первоначальных ловушек, вам не нужно сильно волноваться; Зафиксируйте все на сервере, и если это не правильно, вы можете перемешать это и удалить лишние вещи позже. Единственное, что я не стал бы фиксировать, - это артефакты, созданные на основе исходного кода, то есть файлы кода Java относятся к управлению версиями, но не к скомпилированным классам или целым ISO / DVD-дискам «созданных из исходного кода» двоичных файлов.

Разрабатывать производство легко, на каждом важном этапе создайте ветку. Структура каталогов в системе контроля версий обычно выглядит примерно так:

/ ствол / проект / ветки / проект / версия1 / ветки / проект / версия2 / ветки / проект / версия3

Допустим, вы нашли ошибку во второй версии продукта, перешли к этой ветке, исправили ее и выпустили версию 2.1. Все время вы работаете над папкой / trunk / project для новой версии 4, и вам решать, какие функции объединяются вперед и назад.

Не позволяйте тем, кто пьет помощь от SCM, обмануть вас, между популярными системами контроля версий, а именно Subversion и Git, очень мало функциональных отличий. Самым важным для вашей команды будет то, насколько хорошо эти серверы интегрируются с вашими существующими инструментами. Мне также не нравятся WYSIWYG, но было бы неплохо иметь eclipse-php или другие IDE, совместимые с сервером.

Я разработчик и раньше работал ИТ-администратором.

Чтобы ответить на ваши конкретные вопросы:

1) Да, версия все.

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

3) Отметьте версии, которые будут запущены в производство. даже испытания. Тогда вы всегда можете проверить конкретную версию, которую кто-то использует.

Я вижу, вы пометили вопрос CVS.

Вместо этого я предлагаю серьезно взглянуть на Subversion в сочетании с TortoiseSVN, что делает его очень простым в использовании. Существует также TortoiseCVS.

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

Также может быть полезно установить один из веб-интерфейсов в cvs или subversion.

Причина, по которой я предлагаю использовать Subversion по сравнению с CVS, заключается в том, что, хотя CVS очень хорош, у него есть серьезные проблемы с дизайном и реализацией. Для меня важными моментами были: 1) Вы не можете создавать версии каталогов 2) Обработка двоичных файлов не слишком хороша, так как многие вещи по умолчанию являются текстовыми. 3) Нет атомных коммитов. 4) Я часто вспоминаю, как все портит и оставляет файлы блокировки, которые мне приходилось удалять вручную из хранилища кодов. В этом было место для коррупции, так как вы блокировали файлы. 5) поддержка SSL и управление пользователями / паролями

Subversion в основном исправляет все эти проблемы, вероятно, многие другие. У этого также есть много продвинутых функций как внешние (которые я действительно использую). И возможно связать пользователей / группы с активным каталогом, который может оказаться полезным. В то время я использовал CVS, который не был доступен. Это может быть сейчас, я не проверял.

Вероятно, самая большая разница в использовании SVN - это то, что вы не создаете теги. Вместо этого вы создаете то, что выглядит как копии, где каталог проекта копируется в папку «Теги» и получает имя. Посмотрите в документации, и вы поймете, что я имею в виду. Я знаю, это выглядит странно, но ты к этому привыкла.

Этот веб-сайт может принести некоторую пользу (хотя я не могу за это ручаться): Создание модульного svn-хранилища для php-сайтов http://www.howtoforge.com/set-up-a-modular-svn-repository-for -PHP-сайты

С большим уважением к много мудрости , которая появляется выше - и это является мудрым - свитка контроля версий, как развертывание систем мониторинга. Мои клиенты говорят «что я должен контролировать», и очевидный ответ - «контролировать все». Но это нехорошая новость: у них есть 350 систем, каждая из которых имеет 20-30 системных переменных, а также набор переменных, специфичных для использования, и все они могут быть с пользой для мониторинга; но есть только один из меня, и они хотели бы увидеть некоторые результаты в течение двух недель.

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

Если большинство сбоев вызвано кодом приложения, начните с его контроля; если большинство незапланированных патчей CSS, контролировать это; и так далее.

Это не только даст вам наилучшую отдачу от затрат времени, но и даст вам веские причины для расширения использования контроля версий в будущем: «Поскольку мы добавили контроль версий в код приложения, незапланированные сбои в течение 30 минут сократились с 11 в месяц до 2. Эти два были вызваны статическими изменениями HTML, поэтому мы намерены контролировать версии в следующем. "

Постепенное развертывание также дает вам опытных пользователей внутри организации. Да, вы должны были научить всех шести разработчиков приложений использовать систему, но они научились, и они в порядке с этим; Теперь, когда пришло время внедрить систему в команду CSS, у вас есть на шесть внутренних экспертов больше, чем три месяца назад. К этому времени у вас могут быть даже новообращенные; разработчик, которому удалось спасти свою задницу благодаря возможности быстро отреагировать на разрушительные изменения, может стать вашим лучшим евангелистом в команде CSS.

Правка 1: если вы решите пойти по этому пути, то в качестве дешевого фишки нужно добавить Tripwire сверху, по крайней мере, на производственную коробку. Таким образом, если что - то перерыв , но VCS говорит , что не было ничего , что в настоящее время несет ответственность за, вы можете быстро определить , что уже изменились, что и ускоряет исправление и предлагает свой следующий кандидат для контроля версий.

Контроль версий все. Нет никакого смысла в том, чтобы HTML-файлы находились под контролем версий, а затем полностью завинчивали сайт из-за изменения в CSS, которое не контролируется и поэтому не может быть легко отменено.

Подводные камни: лично я не сталкивался ни с кем во время моего довольно ограниченного использования контроля версий.

Развертывание. В настоящее время я использую Subversion, размещенный на Windows-боксах, как на работе, так и дома. Windows только потому, что это то, что доступно. Иначе это могла бы быть просто другая ОС. Ключ для нетехнических пользователей - дать им простой инструмент на основе графического интерфейса для обработки импорта, экспорта, фиксации, различий и т. Д. Какой инструмент будет использовать, будет немного зависеть от используемой ОС и системы VCS.

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

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

Версия все.

Развертывание зависит от того, сколько вам нужно «настроить» для каждого из этих сайтов. Если они идентичны, за исключением одного или двух конфигурационных файлов, вы можете просто проверить копию кода и внести незначительные изменения. При необходимости выполните команду обновления вашего контроля версий для каждого из клиентов.

Если вы используете модель распространения «оформить заказ непосредственно на сайте клиента», вам нужно быть уверенным, что ваш сервер исключает доступ к каталогам контроля версий, чтобы люди не могли перейти по адресу http://example.com/. мерзавец / и заглянуть в ваши внутренние органы. Кроме того, я определенно хотел бы иметь тестовый и рабочий виртуальный хост для каждого клиента, чтобы убедиться, что обновление сайта не идет наперекосяк. Особенно, если вы вносите пользовательские изменения в файлы отдельных клиентов, вам нужно будет обработать конфликты, прежде чем изменения вступят в силу. В этом случае вы извлекаете / обновляете тестовый виртуальный хост, а когда все работает правильно, вы копируете тестовый виртуальный хост на рабочий виртуальный хост.

Все, что люди говорят о том, что для версии хорошо.

Если вы решили использовать Subversion, я могу порекомендовать попробовать стек Bitnami Trac; http://bitnami.org/stack/trac

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

Дайте всем своим разработчикам Windows TortoiseSVN. Научите всех основам командной строки SVN.

В конце концов, инструмент менее важен, чем мышление, которое нужно привить своим разработчикам. Надеюсь, они скоро увидят, что контроль версий - это хорошо, потому что он останавливает их потерю работы и позволяет им вернуться из тупиков, которые никуда не ведут к известным хорошим состояниям. Преимущества перевешивают (незначительные) накладные расходы.