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

Eclipse + Ant.

Сделана на Ant задача по сборке всего архива(zip) проекта и частичного архива, из измененных после какой-то даты.

Архив заливается на сайт по ftp с помощью Total Comander'а. Очень удобно 
FTP-плагин для eclips'а оказался неудобен, слишком жесткий, не работает через прокси... 
У меня есть локальный сервер для отладки,  демонстрационный, на котором показывается и доводится проект и боевой, который на момент отладки проекта может быть еще даже и не известен. На каждый из них возникает желание "пробросить" изменения...

База сливается Sypex dumper'ом. PHPMyAdmin не годится для слива действительно больших баз...

Существует множество систем. Есть громоздкие, многофункциональные, которые позволяю, буквально, что угодно. А есть небольшие и удобные.

Мы пользуемся довольно простым вариантом:

1. Вся разработка ведется в Subversion (системе контроля версий).
2. Каждый девелопер имеет свой JAIL в FreeBSD с приближенными к PRODUCTION условиями.
3. Существует тестовый сервер, на котором производится тестировние.
4. Выкладка на PRODUCTION осуществляется через скрипты с набором команд "svn export". На каждом сервере свой набор скриптов и свой набор выгружаемых апликаций. Можно стартовать скрипты на каждом сервере ручками, либо использовать самописную утилиту, которая это сделает за нас.
5. Существует система выкладки hot fix-ов, позволяющая разливать небольшие изменения (по файлу, например).

Вот, вроде бы и вся техника.

Предварительно ничего не собирается. По триггеру на коммит в SVN в ветку production код автоматом разворачивается на сервер.

IZ@TOP, SamDark, вы упустили самый неприятный момент -- синхронизация баз. Мы обчно пишем вручную update скрипты, но это жуть как неудобно. Особенно если система хранит в базе не только банные но и настройки (обновлять таким образом проект на друпале просто тихий ужас). Как эту проблемму решаете?

Видимо, следует еще уточнять примерный срок изготовления/активной отладки проекта и количество человек в команде. 
В моем случае 1-3 недели + 1 человек ;-) После этого - эпизодические нерегулярные апдейты.

У нас 3 прокси, 8 веб-морд, 15 mysql серверов, 90+ файловых помоек и несколько серверов приложений, процесс выкладки занимает около часа. Production-версия сохраняется в теге как release-дата. Впрочем, о чем говорить, если у каждого девелопера в песочнице поднято как минимум две инстанции Memceched и с пяток MySQL, а сам проект насчитывает возле восьми виртуальных хостов под разные приложения проекта.


2 дня-неделя. До кризиса было 9 человек в команде, сейчас 2-е. Тестами занимается отдел тестирования, обычно на один проект выделяется от 2-х и до 5 человек.

Добавлено @ 15:21

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

 Иногда как-то не с руки десяток мегабайт заливать, чтобы после непредвиденной ошибки(да например разные данные в БД) заливать снова через минуту.

 Нет желания ворочать гигабайты данных ;)
Крупный проект - десятки гигов.

Это сообщение отредактировал(а) nerezus - 28.3.2009, 23:43

nerezus, 

Архив содержит, как правило, только измененные файлы. Полный архив качается только один раз. В TC - одно окно с корнем сайта, другое окно - "раскрытый" архив (с сохранением структуры каталогов).

Внесение изменений в структуру в соответствии с новым кодом, изменение данных (в основном служебных)

Представляю. И что это меняет? Менять то ее все равно прийдется.

Все зависит от проекта. Обин из проектов попал к нам уже состоявшимся и вот уже год как три фултайм девелопера его развивают. Релиз каждый месяц и изменений вносится дай боже. И этот "раз в месяц" синхронизировать базу не очень то приятно руками.


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

Это сообщение отредактировал(а) solenko - 29.3.2009, 12:53

Не, ну запихать юзеров в ридонли и прогнать на мастерах несколько апдейтов не проблема. А служебные данные - отдельный разговор.


Обновлять структуру - одно. Синхронизировать полностью БД dev-test-production - совсем другое.


Раз в месяц - не вижу сложности. Вы просто не видели, например, как проходит выкладка на огромных проектах. Например на **** выкладка контекстной рекламы не просто выкладка файликов, это тесты кода, компиляция демонов и все это на лету, с "мягким" перезапуском сервисов и много чего еще.


Не представляю, какого рода баги  Мы, к примеру, программисты ленивые, потому, вместо тягания тудым-сюдым данных, предпочитаем курнуть error_log на продакшне.


Что значит, готовить руками patch? В моем представлении, это просто файлик, в котором собрано несколько ALTER'ов и CREATE TABLE.

 Зачем?
Зачем на дев. компах иметь реальную базу?

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

У нас проект скорее из сферы data-mining потому баг это не креш, а непавильная циферка вобном из отчетов. 


Несколько ALTER, иногда update-ов с фиксами для неправильно обработанных данных, и вот как раз мы ленивые программисты и ищем путь не делать все это руками )


См. сообщение предидущее сообщение и начало этого )


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

А может попробовать сделать так, что бы ошибочек в данных не возникало?

Хотя мне кажется, что подобные вещи лучше автоматизации не доверять. Если правите данные запросами на живой БД, лучше это делать человеку с руками и головой 

Не понял фразы.



Лучше/хуже -- это смотреть нужно. Пока даже придумать не смогли как автоматизировать, т.е. и выбирать особо не из чего.

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

Я говорил об этом

Неправильная циферка откуда-то же берется? Так вот, не лучше ли сделать так, что бы всегда получалась правильная циферка?

У нас, к примеру, если вдруг возникнет необходимость править данные на живой БД, это повлечет за собой еще и сброс Memcached'ов. Что, в общем-то не страшно, но не желательно.


А сами не пробовали написать?


  так точно

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



Не пробовали. Потому как, опять же 

Помнится, делал как-то грабилку с афиши, по кино, театрам, выставкам и даже местам (кинотеатрам, концертным залам) с одноименного сайта. Потом эти данные интегрировались с mos2.ru. И... не знаю, чудо или нет, все жило без постороннего вмешательства 
Впрочем, каждому проекту свои особенности и тяжкое бремя 

Проект предпочитаю вести используя SVN
Заливать данные на сервер уж лучше через WinSCP как по мне куда надежнее.
Бывает что один человек из команды хватанет вирус который потом ифремы лепит во 
все файлы и потом скриптами чистим. После последнего такого случая все перешли на WinSCP.
Если править файлы нужно на сервере (ну очень редко, лучше патчами) то используем плагин 
в Zend Studio for Eclipse.

Atlete, И как WinSCP помогает защитится от вирусов? 
Кстати, он у меня не пошел с http прокси. Просто не сохраняет его и, соответственно, не коннектится... Так и должно быть?

Всем высказавшимся большое спасибо!