Уважаемые гуру 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-ов с фиксами для неправильно обработанных данных, и вот как раз мы ленивые программисты и ищем путь не делать все это руками )


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


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

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

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

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



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

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