Имеется пара программистов-phpшников. Работают над нашими сайтами. Работают в онлайне через FTP-доступ к хостингу. Хочется прикрутить к ним SVN, чтобы вести учет изменений и возможность отката к определенной версии. Да и сама схема работы в онлайне мне не очень нравится, т.к. при падении инета работа останавливается.
В связи с этим вопрос. У кого-то есть опыт налаживания такого процесса, чтобы программисты работали не через инет, но при этом файл при сохранении (или в какой-то определенный момент) попадал на хост и на SVN (CVS)? Поделитесь. Какой софт использовать, какие скрипты, и т.д.
Здравствуйте, Rett Pop, Вы писали:
RP>Memento mori, All!
RP> Имеется пара программистов-phpшников. Работают над нашими сайтами. Работают в онлайне через FTP-доступ к хостингу. Хочется прикрутить к ним SVN, чтобы вести учет изменений и возможность отката к определенной версии. Да и сама схема работы в онлайне мне не очень нравится, т.к. при падении инета работа останавливается. RP> В связи с этим вопрос. У кого-то есть опыт налаживания такого процесса, чтобы программисты работали не через инет, но при этом файл при сохранении (или в какой-то определенный момент) попадал на хост и на SVN (CVS)? Поделитесь. Какой софт использовать, какие скрипты, и т.д.
RP> Заранее благодарен.
RP>---------------------------- RP>WBR, Rett Pop
Закрыть досту на FTP, дать программистам адрес репозитария и ссылку где скачать SVN клиент. Написать командный файл, который будет выливать последнюю версию из репозитария на FTP.
По таймеру (at, cron итп) запускать этот файл.
gandjustas пишет:
> По таймеру (at, cron итп) запускать этот файл.
ага, а потом долго и больно бить по рукам того, кто закоммитил
непроверенный код в транк и увалил тем живой сайт
ИМХО, заливать на продакшен, равно как и откатывать потом в случае чего,
должен член команды разработки. В идеале — тимлид, или иное лицо,
отвечающее за разработку. Руками, сознательно отдавая себе отчет в том
что делает. А не когда "вечером вроде все работало, а в полночь случился
крон и все упало".
А вот заказчикам, самопроизвольно откатывающим изменения, а потом
предъявляющим багрепорты по позапрошлой версии, я бы руки пооткручивал
самолично
Здравствуйте, Роман Дубров, Вы писали:
РД>gandjustas пишет:
>> По таймеру (at, cron итп) запускать этот файл.
РД>ага, а потом долго и больно бить по рукам того, кто закоммитил РД>непроверенный код в транк и увалил тем живой сайт
А есть вообще способы проверить работоспособность сайта на PHP, кроме ручной проверки?
РД>ИМХО, заливать на продакшен, равно как и откатывать потом в случае чего, РД>должен член команды разработки. В идеале — тимлид, или иное лицо, РД>отвечающее за разработку. Руками, сознательно отдавая себе отчет в том РД>что делает. А не когда "вечером вроде все работало, а в полночь случился РД>крон и все упало".
Можно деплоить каждые 5 минут на стейджевый сервак и смотреть как работает. Стабильные версии переносить на live, тоже одним скриптом.
РД>А вот заказчикам, самопроизвольно откатывающим изменения, а потом РД>предъявляющим багрепорты по позапрошлой версии, я бы руки пооткручивал РД>самолично
Заказчиков вообще к внутренним процессам пускать нельзя.
Здравствуйте, gandjustas, Вы писали:
G>А есть вообще способы проверить работоспособность сайта на PHP, кроме ручной проверки?
кроме ручной проверки на продакшене есть еще ручная проверка на дев-сервере
G>Можно деплоить каждые 5 минут на стейджевый сервак и смотреть как работает. Стабильные версии переносить на live, тоже одним скриптом.
угу, вот только если проверка все равно руками — смысл заворачивать одну-единственную команду в скрипт? По крону такое все равно делать чревато...
G>Заказчиков вообще к внутренним процессам пускать нельзя.
да, и рутовый пароль от их сервака тоже надо принудительно отнимать