Преобразование группы разработчиков с FTP на систему управления версиями

Вопросов:

1. У вас (у них) никогда не было катастрофы, когда вам (им) нужно было вернуться к предыдущей версии веб-сайта, но не смогли, потому что они ее сломали?

2. Используют ли они промежуточный веб-сервер для проверки изменений?

3. Конечно, они не изменяют код на производственном сервере без какого-либо тестирования?

Я подозреваю, что ответ на первый - «да (у них были бедствия)», а на второй - «нет», и я не решаюсь угадать ответ на третий (но… судя по его звукам, ответ может быть «да, они действительно делают "). Если это так, я восхищаюсь их бравадой и удивляюсь, что они никогда не ошибаются. Я бы никогда не рискнул вносить изменения прямо на действующем веб-сайте.

Я бы рекомендовал самостоятельно использовать систему контроля версий или VCS (любую VCS). Устраните неровности кода, за которым вы следите, и разработайте удобный дистрибутив, который упрощает (возможно, все еще с использованием SFTP) распространение кода VCS на веб-сайт. Но также покажите, что сохранение предыдущих версий имеет свои достоинства - потому что вы можете восстановить, кто что и когда делал. Для начала вы можете обнаружить, что вам нужно загрузить текущую версию любой страницы (файла), над которой вам нужно работать, и поместить эту последнюю версию в VCS, прежде чем вы начнете изменять страницу, потому что кто-то другой мог ее изменить, поскольку она последний раз обновлялся в вашем главном репозитории. Вы также можете ежедневно «очищать» файлы, чтобы получить текущие версии и отслеживать изменения. У вас не будет ни «кто», ни точно «когда» (лучше, чем до ближайшего дня), ни «почему», но у вас будет (совокупное) «что» из изменений.

Отвечая на комментарии в вопросе, Олафур Вааге пояснил, что у них были бедствия из-за отсутствия VCS.

Обычно это значительно облегчает жизнь. Они дурачились; они не могли избавиться от глупостей - они, вероятно, рассердили клиентов, и им следовало бы быть невероятно раздраженными на себя. VCS значительно упрощает восстановление после таких ошибок. Очевидно, что для любого настроенного сайта вам потребуется (центральная) резервная копия «правильной» или «официальной» версии этого сайта, доступной в VCS. Я бы, вероятно, выбрал единый репозиторий для всех клиентов, используя VCS, который имеет хорошую поддержку для ветвления и слияния. Поначалу с этим может быть труднее справиться (пока люди привыкают к использованию VCS), но, вероятно, в долгосрочной перспективе это приведет к лучшим результатам. Я бы серьезно подумал об использовании одной из современных распределенных VCS (например, мерзавец), хотя многие люди тоже используют SVN (даже если это не распределенная VCS).

вы можете использовать tortoise svn client для создания и работы с репозиторием на вашем локальном компьютере на каком-либо другом пути к файлу, тогда ваш рабочий путь ...

возможно, попробуйте настроить и использовать это для себя и через некоторое время показать им, что он может для вас сделать. еще одна интересная вещь может быть установка trac (http://trac.edgewall.org/) на вашем сервере, если у вас есть доступ и привилегии для этого, или, может быть, на какой-то виртуальной машине на вашей собственной машине разработки. вы можете сопоставить trac с вашим svn и получить изменения svn в веб-интерфейсе, которые вы можете показать менеджеру проекта. возможно, он поймет, что сможет легко видеть изменения кода через веб-интерфейс. конечно, вы можете сделать это только с модулем apache + svn, но это лучше, поскольку он предлагает путь к продаже билетов и дорожному картированию (этапы и прочее, что менеджеры могут раскопать: o)) ..

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

Вы можете установить SVN в своей локальной системе для демонстрации. Есть несколько инструментов для интеграции Zend и Eclipse в SVN. Я думаю, что в дополнение к демонстрации SVN вам, вероятно, следует рассказать им о некоторых преимуществах, которые он принесет (возможно, во время демонстрации).

Перейдите по этой ссылке, чтобы получить некоторые идеи: Мне действительно нужен контроль версий?

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

Похоже, что все эти сайты связаны между собой - настроенными версиями одной и той же CMS. В этом случае вы должны поместить все сайты в один репозиторий в дополнение к ненастроенному продукту CMS. Затем вы можете настроить их все как филиалы одного центрального продукта. Если вы используете отдельные репозитории, не существует простых способов создания веток, чтобы связать настройки с основным продуктом. (Я думаю, что вы может делаете это с Subversion и, скорее всего, с другими, но это сложно и ненужно, если все разработчики работают в одной организации.)

VisualSVN Server и TortoiseSVN - две программы, которые я использую, они обе хорошо документированы и так хорошо интегрируются с Windows Explorer и Visual Studio.

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

Вот одна хитрость, которая понравится всем:

Я включаю этот «плагин» в большинство своих производственных сайтов: Конечно, для этого сначала необходимо создать svn-аккаунт робота с ограниченными правами, и svn должен быть установлен на сервере.

    echo(' updating from svn<br>' );
    $username = Settings::Load()->Get('svn','username');
    $password = Settings::Load()->Get('svn','password');
    echo(" <pre>" );
    $repos = Settings::Load()->Get('svn' , 'repository');
    echo system ("svn export --username = {$username} --password {$password} {$repos}includes/ ".dirname(__FILE__)."/../includes --force");
    echo system("svn export --username = {$username} --password {$password} {$repos}plugins/ ".dirname(__FILE__)."/../plugins --force");

    die();

Убедитесь, что вы разместили это за сайтом .htpasswded, и убедитесь, что вы не обновляете «производственные настройки» из SVN. Et voila, вы обновляете свою полную базу кода с помощью одного HTTP-запроса к своему сайту :) SVN автоматически перезаписывает файлы, не остается никаких скрытых файлов или папок, и его легко адаптировать для обновления или возврата к определенной версии. Теперь все, что нужно сделать вашей команде, это зафиксировать в своем репозитории SVN, запустить этот фрагмент кода в тестовой среде, убедиться, что все работает, а затем запустить его на производстве :)

Просто поместите SVN посередине.

Команда разработчиков взяла новый материал на подрывную работу, а затем у вас есть сценарий, который экспортирует материал из svn и отправляет его на веб-сервер.

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

/ Йохан