2008-12-28 4 views
6

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

Команда работает в Zend Studio 5.5, подключенной к серверу Live через FTP или SFTP. То, что им нравится, это скорость их развертывания кода (с момента его изменения только живого кода).

Но, конечно, это не хорошо по многим очевидным причинам.

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

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

Что бы я сделал, это создать эту установку на моей машине, а затем показать ее.

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

UPDATE (для ответа Джонатана Леффлера):

  1. Да
  2. Нет
  3. Да, они действительно

Вопрос также, студия делает централизованную систему CMS, размещенную на сотнях сайтов им нужно модифицировать отдельные сайты, если сайты находятся в главном редакторе или в их собственном?

+0

Ответ на вопрос Q1 «Да, у них никогда не было катастрофы»? Или это «Да, у них были катастрофы, где они не могли вернуться»? Извините, вопрос неоднозначен. –

+0

Ответ на ваш вопрос «несколько сайтов в главном хранилище» - «это зависит». Но мне было бы крайне неудобно с системой, в которой разработчики не имели хорошего VCS на месте * моего * сайта и моей CMS. Он должен находиться под VCS. –

+0

Ответ: да, у них были катастрофы. –

ответ

7

Вопросы:

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

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

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

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

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


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

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

+0

Спасибо за ваше обновление и ответ. –

2

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

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

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

+0

Люблю комментарий о подключении к trac, спасибо. –

+0

Я обожаю программное обеспечение, смотрел его некоторое время и просто получил его 2 недели назад, и с тех пор я самый счастливый человек ... :). простой, полезный, простой в использовании ... и с 0.11.x прост в установке. я получил его и работал в чистом debian, установленном в VM менее чем за полчаса. – zappan

2

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

Перейти к этой ссылке для некоторых идей: Do I Really Need Version Control?

1

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

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

+0

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

0

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

0

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

+0

Другие потоки возможны, конечно. – Brody

2

Вот один трюк, который все будут любить:

Я включил этот «плагин» в большинстве моих производственных площадок: Ofcourse, вам необходимо создать учетную запись с ограниченными правами робот СВН для этого первого и СВН должна быть установленных на сервере.

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, запустить этот кусок кода в тестовой среде, убедиться, что все работает, а затем запустить его на производство :)

+0

Очень круто, я даю вам больше +, если бы мог. –

0

Просто положите i.e SVN посередине.

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

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

/Johan