Symfony Модификация скриптов на живом сайте

[Allality]

Допустим, есть работающий, раскрученный сайт на Symfony 2, на котором необходимо производить какие-то либо модификации. Например, устранить ошибку или дописать скрипт.

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

В Symfony 2 есть “окружающие среды” (environments), которые вроде как служат как раз для этой цели (или нет?), но я никак не могу понять сам процесс. В сети есть очень много практического материала на тему использования “окружающих сред”, но ничего на тему самой основы работы над живым сайтом найти не могу. Т.е. мне ясно, что, к примеру, dev среда выводит более полные логи и пр., но мне не понятен сам процесс разработки сайта, где малейшая правка кода может привести к тому, что весь сайт или его часть умрет, выдавая какую-нибудь нелепую ошибку.

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

 

[Вурдалак]

Окружения к деплою отношения не имеют.

Для перевода сайта на новую версию (aka «тег») правильнее всего выложить код в новую папку. Прогреть кеш, сгенерить что нужно. И переключать document root (явно или через symlink) на неё. В таком случае переключение версии сайта произойдёт атомарно. См. например http://capifony.org/#4_setup_server

 

[hell0w0rd]

я делал так:
создавал две ветки, dev и master
на продакшене master, рядом в папке dev
dev.site.ru вел к папке с dev веткой, а site.ru к master ветке

 

[Вурдалак]

Окружения — это не столь интересно, ты само обновление как накатываешь? git pull шоле?

 

[hell0w0rd]

Окружения — это не столь интересно, ты само обновление как накатываешь? git pull шоле?

Ага, и там и там есть файлы с постфиксом dev, просто обращение к ним идет только на dev версии... config_dev и index_dev
git не для деплоя, но для не особо сложных случаев мне кажется самое то

 

[keltanas]

У симфони в продакшен-окружении, например, кэш не пересоздается, шаблоны не перекомпилируются, статика не собирается. После каждого пука надо пересоздавать кэш и статику.
В дев-окружении все пересоздается. Статитика берется через симлинки и скрипты ассетик-бандла.
Так что после того, как изменяешь что-то на продакшене, надо перекомпилировать все изменения. Собственно, это должно убедить разработчиков (которые любят править сайт прямо на живую), что править что-то на продакшене не нужно.
Для этого надо развернуть проект где-то в другом месте в дев-окружении. Отладить, проверить тесты. А потом глубокой ночью накатить на продакшен изменения, пересобрать все шаблоны, статику и кэш, накатить миграции. Если в это время перенаправишь сайт на заглушку, будет совсем хорошо.
Про использование VCS, надеюсь, не надо писать?

 

[Allality]

Для перевода сайта на новую версию (aka «тег») правильнее всего выложить код в новую папку. Прогреть кеш, сгенерить что нужно. И переключать document root (явно или через symlink) на неё. В таком случае переключение версии сайта произойдёт атомарно. См. например http://capifony.org/#4_setup_server

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

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

Т.е. все-таки нужно делать полную копию у себя на компьютере, но в dev окружении? Я думал этот подход устарел лет 5-7 назад.

Или это как-то по-другому выглядит? К примеру, есть сайт и мне необходимо дописать контроллер для раздела каталога, какие мои действия? Краткое колхозное объяснение без изобилия жаргона приветствуется.

Про использование CVS, надеюсь, не надо писать?

Нужно. Я не пользовался подобным софтом, т.к. писал всегда в одиночку все и необходимости не видел в этом. Мне даже в голову не приходило, что подобный софт можно использовать при разработке "тестовой версии" сайта. Как именно CVS помогает?


PS: А вообще, по какому материалы вы все учились разделению на dev/prod, работе с cvs, т.е. вообще знакомились с самой концепцией? Я к тому, что может мне (и другим новчикам) не стоит задавать здесь кучу глупых вопросов, а пойти и прочитать правильный материал по теме, если такой существует.

 

[Absinthe]

Я не пользовался подобным софтом, т.к. писал всегда в одиночку все и необходимости не видел в этом.

При одиночной разработке VCS тоже необходимы.

 

[keltanas]

А вообще, по какому материалы вы все учились разделению на dev/prod, работе с cvs, т.е. вообще знакомились с самой концепцией? Я к тому, что может мне (и другим новчикам) не стоит задавать здесь кучу глупых вопросов, а пойти и прочитать правильный материал по теме, если такой существует.

"Правильного" материала не существует. Что русскому хорошо, то немцу смерть. В каждой команде принимаются свои соглашения, которым команда следует, исходя из специфики проекта, предпочтений лида и популяции сусликов в западной Сибири. Так что лучший способ быстро во всем разобраться - пойти работать в какой-то проект джуниором. Желательно, чтобы проект уже работал и приносил прибыль, что будет в какой-то степени показателем успешности команды. В описании вакансии обычно пишут, что команда пользуется эджайлом, гитом, багтрекером, тдд и прочими словами.

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

Собственно, когда тем или иным привыкнешь к поставленному процессу, уже будет сложно делать как-то иначе.

ЗЫЖ Конечно, бывают случаи, когда просят подправить скрипты на каком-то сайте за 500 руб. Тут не стоит даже и пытаться завязываться на все, выше перечисленное, т.к. себе дороже. А если берешь проект на аутсорс, то без этого никуда.

 

[Allality]

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

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

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

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

 

[Redjik]

keltanas
чем собираешь - phing, ant или что-то не мейнстримовое?
какой build server юзаешь - teamCity, jenkins или см. выше?

 

[keltanas]

Redjik
Раньше пользовался Phing-ом, Ant - примерно тоже самое. Говорят, что Maven хорошая штука, но я не пробовал. Сейчас проекты маленькие, так использую либо bash-скрипт, либо вообще ничего. Мне на фрилансе не всегда рентабильно заморачиватся со сложными билдами.
Кстати с Phing намучился. Слишком много приходится делать телодвижений ради примитивных операций. Сайт с документацией периодически лежит.

Пользовался Jenkins, Travis, хотя для себя и не нашел в этом большого профита. Видимо, должен быть масштаб проекта покрупнее, чем мне выпадают ))
Кстати, ты работал с TeamCity? Мне очень нравится YouTrack, но я что-то не догняю, как с TeamCity работать на php?

 

[Redjik]

keltanas
Ага, как раз его сейчас ковыряю.
Отслеживает коммиты, на новый коммит делает билд - запускает задачи по порядку (можно phing, можно bash).
Я лично чищу кэш и тесты прогоняю. + много всяких модулей - типа codeInspection, чтобы знать, кто в команде пишет некрасивый код...
Куча статистики - еще не со всем разобрался.

 

[keltanas]

Redjik
Есть какое-то howdo по прикручиванию проекта на php к TeamCity?