Наша довольно небольшая компания (3-4 программиста и 3-4 дизайнера сайтов), которая разрабатывает одноцелевое веб-приложение на PHP, которое обеспечивает функциональность примерно 100+ веб-сайтам. Мы работали в течение пары лет в отдельной среде разработки и производства, которая зарекомендовала себя довольно хорошо. Всегда было достаточно отдельных функций, чтобы разработчики никогда не сталкивались друг с другом, и было удобнее работать без системы управления версиями; даже несмотря на то, что он имел риск потери данных, и у нас была значительная часть файлов, пропавших без вести в результате непреднамеренного перемещения.
Другое соображение заключается в том, что наши дизайнеры не разбираются в технологиях (я представил им разметку HTML вместо использования WYSIWYG). Это одна из причин, по которой не решались переходить на управление версиями.
Однако теперь, когда мы достигли 100+ сайтов и команда разработчиков растет, я пытаюсь стандартизировать наши процедуры, и контроль версий кажется логичным шагом для программистов. Я надеюсь, что это также ускорит развертывание патчей.
К сожалению, у меня очень ограниченный опыт настройки системы управления версиями. Что мне любопытно услышать от людей с аналогичной настройкой или имеющих опыт переключения:
1) Все ли вы версируете (сайты, css, html-шаблоны и код приложения) и тем самым заставляете дизайнеров изучать управление версиями? Или над кодом приложения работают только разработчики?
2) Какие подводные камни следует избегать при первоначальной настройке системы управления версиями?
3) Развертывание dev => продакшн для управления версиями.
Спасибо за понимание.
Изменить 1: Черт. Пока все рекомендуют контролировать все. Из-за этого я рано потеряю волосы. Вероятно, в ближайшем будущем это вызовет новый вопрос. Спасибо за совет, продолжайте!
Изменить 2: много хороших ответов, и мы рассмотрим различные системы контроля версий. Всем спасибо за ответы!
Даже для дизайнеров полезно иметь версии для всего. И я думаю, что они сочтут это более полезным, чем обременительным, если оно будет реализовано хорошо при хорошем обучении.
Если вы только начинаете, я настоятельно рекомендую использовать распределенная система контроля версий лайк мерзавец или ртутный. Это общая тенденция в мире, и у нее много преимуществ. Легко работать в автономном режиме, без зависимости от сети и с возможностью выполнять частную неотредактированную работу, все еще находясь под контролем версий, проверяя все централизованно, когда оно готово.
И не прибегать к апелляциям к властям или чему-то еще, но проверить, что Джоэл Спольски должен сказать по теме. (Выборочная цитата: «Subversion = Leeches. Mercurial и Git = Antibiotics.») Среди прочего, он отмечает интересный момент, что эти новые системы используют новую ментальную модель, отличную от традиционного контроля версий - вот почему подход с самого начала - это победа.
Я бы сказал, поставить все под контроль версий. Как только все заработает, вы можете скопировать его в тег, который для большинства систем SCM не требует большого дискового пространства на сервере.
Что касается начальных ошибок, вам не стоит сильно беспокоиться; передать все на сервер, и если это не правильно, вы можете перетасовать это и удалить лишнее позже. Единственное, что я бы не стал фиксировать, - это артефакты, созданные из исходного кода, то есть файлы кода Java принадлежат системе контроля версий, но не скомпилированные классы или целые ISO / DVD двоичных файлов, созданных из исходного кода.
От разработки до продакшена легко, на каждом важном этапе создавайте ветку. Структура каталогов в системе контроля версий обычно выглядит примерно так:
/ ствол / проект / ветви / проект / версия1 / ветки / проект / версия2 / ветви / проект / версия3
Допустим, вы нашли ошибку в версии 2 продукта, вы переходите в эту ветку, исправляете ее и выпускаете версию 2.1. Все время, пока вы работаете над папкой / trunk / project для новой версии 4, вам решать, какие функции будут объединены в прямом и обратном направлениях.
Не позволяйте любителям SCM kool-aid вводить вас в заблуждение, между популярными системами контроля версий, а именно Subversion и Git, очень мало функциональных различий. Самым важным для вашей команды будет то, насколько хорошо эти серверы интегрируются с вашими существующими инструментами. Мне тоже не нравятся WYSIWYG, но было бы неплохо иметь eclipse-php или другие IDE, совместимые с сервером.
Я разработчик и раньше работал ИТ-администратором.
Чтобы ответить на ваши конкретные вопросы:
1) Да, версия для всего.
2) Предложите вам создать фиктивный репозиторий управления версиями и фиктивный проект, чтобы люди могли учиться.
3) Отметьте версии, которые будут запущены в производство. даже испытания. Тогда вы всегда можете проверить конкретную версию, которую кто-то использует.
Я вижу, вы отметили вопрос CVS.
Я предлагаю вместо этого серьезно взглянуть на Subversion в сочетании с TortoiseSVN, что делает его очень простым в использовании. Также существует TortoiseCVS.
Я предлагаю вам запустить собственное руководство по контролю версий. Я буду удивлен, если ваши разработчики / дизайнеры не сталкивались с этим раньше. Tortoise просто делает его очень удобным.
Также может быть полезно установить один из веб-интерфейсов в cvs или 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-websites
С большим уважением к большей части мудрости, которая появляется выше - и это является разумно - развертывание контроля версий похоже на развертывание систем мониторинга. Мои клиенты говорят «что я должен контролировать», и очевидный ответ - «контролировать все». Но это неприятные новости: у них 350 систем, каждая из которых имеет 20-30 системных переменных плюс множество переменных, специфичных для использования, и все они могут быть с пользой отслежены; но есть только один из меня, и они хотели бы увидеть какие-то результаты в течение двух недель.
Поэтому, хотя я согласен с тем, что лучше всего контролировать все версии, если это нецелесообразно в первую очередь, начните с контроля над теми вещами, отсутствие контроля которых доставляло вам больше всего проблем до сих пор.
Если большинство сбоев вызвано кодом приложения, начните с его контроля; если большинство из-за незапланированных исправлений CSS, контролируйте это; и так далее.
Это не только даст вам наилучшую окупаемость вложенного времени, но и даст вам, в свою очередь, веские причины для расширения использования контроля версий в будущем: «Поскольку мы добавили контроль версий в код приложения, незапланированные простои в течение 30 минут упало с 11 в месяц до 2. Эти два были вызваны статическими изменениями HTML, поэтому мы намерены управлять версиями в следующих случаях. ".
Поэтапное внедрение также дает вам опытных пользователей внутри организации. Да, вы должны были научить всех шести разработчиков приложений, как пользоваться системой, но они научились, и они согласны с этим; Теперь, когда пришло время передать систему команде CSS, у вас на шесть штатных экспертов больше, чем три месяца назад. К этому времени у вас могут быть даже обращенные; разработчик, чья задница была спасена благодаря способности быстро отменить опасные изменения, вполне может быть вашим лучшим проповедником команде CSS.
Редактировать 1: если вы решите пойти по этому пути, нужно добавить дешевую опцию растяжка сверху, по крайней мере, на производственной коробке. Таким образом, если что-то сломается, но VCS скажет, что в настоящее время она не несет ответственности, вы сможете быстро определить, что имеет изменено, что ускоряет исправление и предлагает вашего следующего кандидата для управления версиями.
Контроль версий все. Нет смысла держать файлы HTML под контролем версий, а затем полностью облажать сайт из-за неконтролируемого изменения CSS, которое не может быть легко отменено.
Ловушки: я лично не сталкивался ни с чем во время своего довольно ограниченного использования контроля версий.
Развертывание: в настоящее время я использую Subversion, размещенную на компьютерах с Windows, как на работе, так и дома. Windows только потому, что это то, что доступно. В противном случае это могла бы быть другая ОС. Ключ для нетехнических пользователей - предоставить им простой инструмент на основе графического интерфейса для обработки импорта, экспорта, фиксации, сравнения и т. Д. Какой инструмент использовать, будет немного зависеть от используемой ОС и системы VCS.
Использование: Когда я вношу изменения в код, я часто тестирую и фиксирую. Это позволяет мне возвращаться настолько далеко, насколько это необходимо, когда я ошибаюсь. Кроме того, сравнивая различные версии и копируя части кода, мне не нужно терять каждое изменение только потому, что мне нужно вернуться к предыдущей версии, чтобы исправить некоторые проблемы в другой части кода.
Дополнительное преимущество: вы можете предоставить доступ к исходному репозиторию через VPN или безопасное соединение, позволяя пользователям работать из дома или в другом месте. например Я мог бы получить идею дома и отредактировать свой рабочий код тут же, прежде чем я потеряю эту мысль.
Версия все.
Развертывание зависит от того, сколько вам нужно «настроить» для каждого из этих сайтов. Если они идентичны, за исключением конфигурационного файла или двух, вы можете просто проверить копию кода для них и внести незначительные изменения. При необходимости запустите команду обновления вашего контроля версий для каждого из клиентов.
Если вы выберете модель распространения «оформление заказа прямо на сайт клиента», вы захотите убедиться, что ваш сервер исключает доступ к каталогам управления версиями, чтобы люди не могли просматривать их http://example.com/.git/ и заглянуть внутрь себя. Кроме того, я бы определенно иметь тестовый и рабочий виртуальный хост для каждого клиента, чтобы убедиться, что обновление сайта не сработает. Особенно, если вы вносите индивидуальные изменения в файлы отдельных клиентов, вам нужно будет уладить конфликты, прежде чем изменения вступят в силу. В этом случае вы должны проверить / обновить тестовый виртуальный хост, и когда все будет работать правильно, вы скопируете тестовый виртуальный хост на рабочий виртуальный хост.
Все, что люди говорят о том, какая версия есть, - хорошо.
Если вы решите пойти на подрывную деятельность, могу ли я порекомендовать попробовать стек Bitnami Trac; http://bitnami.org/stack/trac
Он упрощает настройку Subversion для вас, поставляется с системой тикетов (которую вы можете использовать на этом этапе или нет) для отслеживания изменений и ошибок, а также вики, которую вы можете использовать для документирования того, как вы хотите, чтобы ваши разработчики использовали система.
Дайте всем своим разработчикам Windows TortoiseSVN. Научите всех основам работы с командной строкой svn.
В конце концов, инструмент менее важен, чем образ мышления, который вам нужно привить своим разработчикам. Надеюсь, они скоро увидят, что контроль версий - это хорошо, потому что он останавливает их потерю работы и позволяет им вернуться из тупика, который никуда не ведет обратно к заведомо хорошему состоянию. Выгоды перевешивают (небольшие) накладные расходы.