Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 57
вы с заголовком не перемудрилти?
Да, но разработчику нужно ставить и настраивать всё необходимое ПО на свою машину. верно?
В статье рассмотрена схема, в которой разработчику не нужно ставить ничего, кроме IDE, возможно вы не внимательно прочитали.
вы «не догнали».
у каждого разработчика своя домашняя директория на сервере разработки, в которой лежат его рабочие копии проектов. эта директория примонтирована как сетевой диск на машине разработчика.
разработчик работает со в своей рабочей копии а результат работы смотрит по своему персональному урл в браузере типа http: / / superproject.kolja.mycompanydev.ru/
следовательно никогда не возникнет ситуации, что два человека правят один и тот же файл, так как они работают каждый со своей рабочей копией.
когда разработчик закрывает какой-то тикет, он комитит изменения из своей рабочей копии в репозиторий, на сам же продакшн эти изменения точно таже выписываются из репозитория.
у каждого разработчика своя домашняя директория на сервере разработки, в которой лежат его рабочие копии проектов. эта директория примонтирована как сетевой диск на машине разработчика.
разработчик работает со в своей рабочей копии а результат работы смотрит по своему персональному урл в браузере типа http: / / superproject.kolja.mycompanydev.ru/
следовательно никогда не возникнет ситуации, что два человека правят один и тот же файл, так как они работают каждый со своей рабочей копией.
когда разработчик закрывает какой-то тикет, он комитит изменения из своей рабочей копии в репозиторий, на сам же продакшн эти изменения точно таже выписываются из репозитория.
Да ладно. Ваш вариант, Zork(собственно у и меня все так сделано), более надежен.
А если интернет отвалился, то в варианте автора кодер идет пить пиво вместо работы.
А если дос атака на сайт?
А дырки временно появляющиеся в процессе разработки в рабочих версиях ставят под угрозу основной сайт?
Имхо, ненадежно все это.
А если интернет отвалился, то в варианте автора кодер идет пить пиво вместо работы.
А если дос атака на сайт?
А дырки временно появляющиеся в процессе разработки в рабочих версиях ставят под угрозу основной сайт?
Имхо, ненадежно все это.
«директория примонтирована как сетевой диск» — не знаю, как у других, а у меня Eclipse под Windows (XP & Vista) замирал на несколько секунд при сохранении на сетевой диск, а если к сети подключаешься через VPN, то вообще туши свет.
знаю, что другие так работают, но я не смог и сделал через svn — у меня локальная копия, по коммиту папка проекта апдейтится и на вебсервере. коммит занимает примерно столько же времени, как и обычное сохранение на сетевой диск, но на это время IDE не подвисает и можно продолжать работать, пока что-то коммитится в фоне.
знаю, что другие так работают, но я не смог и сделал через svn — у меня локальная копия, по коммиту папка проекта апдейтится и на вебсервере. коммит занимает примерно столько же времени, как и обычное сохранение на сетевой диск, но на это время IDE не подвисает и можно продолжать работать, пока что-то коммитится в фоне.
Я считаю, что комит на каждое нажатие ctrl-s полностью убивает идею контроля версий.
Проблему с сетевым диском можно решить так. Рабочая копия проекта помещается на локальный диск разработчика, а winscp контролирует изменения и переносит их в рабочую директорию на сервере.
При такой организации IDE совсем не подвисает при сохранении и поиск по файлам работает значительно быстрее. К сожалению winscp дает задержку в 0.5 — 1 секунды, но ее почти не заметно.
При такой организации IDE совсем не подвисает при сохранении и поиск по файлам работает значительно быстрее. К сожалению winscp дает задержку в 0.5 — 1 секунды, но ее почти не заметно.
так ему придется все равно что-то ставить себе.
Zork,
5-й пункт называется «Постоянная интеграция» (Continuous Integration, CI).
Вот это я понимаю, грамотный расклад. Мы сами автоматизировали почти весь процесс, чтобы исключить участие человека. У нас, кстати, в «5-м пункте» также запускается средство проверки уровня покрытия кода тестами, проверка оформления кода и автоматическая вставка комментариев в коде, если разработчик не оставил. Таким, образом, видно кто, когда и где не описал все тест-кейсы и не задокументировал код.
5-й пункт называется «Постоянная интеграция» (Continuous Integration, CI).
Вот это я понимаю, грамотный расклад. Мы сами автоматизировали почти весь процесс, чтобы исключить участие человека. У нас, кстати, в «5-м пункте» также запускается средство проверки уровня покрытия кода тестами, проверка оформления кода и автоматическая вставка комментариев в коде, если разработчик не оставил. Таким, образом, видно кто, когда и где не описал все тест-кейсы и не задокументировал код.
Интересно было бы узнать как вы это автоматизировали? Может поделитесь хотя бы ссылками на что-то похожее, если такое есть?
Да, конечно, Мартин Фаулер прекрасно и очень подробно описал постоянную интеграцию в своей статье Continuous Integration (последний апдейт документа — 1 мая 2006-го года).
А в качестве сервера CI, поскольку мы на .NET, используем CruiseControl.NET.
Еще очень распространен TeamCity.
Для сборки используем NAnt, для проверки уровня покрытия кода — NCover, для проверки соответствия кода правилам — fxCop и StyleCop, его же для проверки наличия комментариев у всех классов, а для автоматической генерации кода общего API — NDoc.
А в качестве сервера CI, поскольку мы на .NET, используем CruiseControl.NET.
Еще очень распространен TeamCity.
Для сборки используем NAnt, для проверки уровня покрытия кода — NCover, для проверки соответствия кода правилам — fxCop и StyleCop, его же для проверки наличия комментариев у всех классов, а для автоматической генерации кода общего API — NDoc.
Каждому разработчику по вмваре и вперед.
Ставит все, что нужно. Конфликты с другими отсутствуют напрочь.
Код хранится в репозитории, а тестируется на отдельной вмваре.
Ставит все, что нужно. Конфликты с другими отсутствуют напрочь.
Код хранится в репозитории, а тестируется на отдельной вмваре.
А если есть примерно деясток проектов и примерно столько же разработчиков (это совсем незначительные цифры даже для небольшой студии). Это около сотни доменов надо сделать?
Если вы внимательно посмотрите статью то поймёте, что домен нужно сделать один (например mycompanydev.ru), но отдать всю зону на айпишник вашего сервера разработки. После того как вы сконфиугрируете nginx (приведенный кусок конфига обсуживает все домены *.*.mycompanydev.ru) ничего руками создавать будет не нужно.
Да. Примерно так всё у нас сейчас и организовано. Вполне логичный вариант.
Почти так и работаем.
Причем, уже сложно представить, как можно работать иначе, если проект действительно большой и над ним одновременно работают несколько разработчиков.
За статью спасибо, многим будет полезно.
Причем, уже сложно представить, как можно работать иначе, если проект действительно большой и над ним одновременно работают несколько разработчиков.
За статью спасибо, многим будет полезно.
Ну это хорошо, если у вас только ваше приложение общее, и помещается на один сервер. А что делать с базой, демонами(memcached, sphinx), файловыми хранилищами?
Сейчас у нас везде раставлены опции на эти случаи. Например разработчики используют файлы, вместо memcached на рабочих машинах, благодаря абстракции от cache storage. Sphinx тоже окружен абстракцией и она отдает просто набор случайных id'шников, если указана соответствующая опция. И с базкой можно более менее все устаканить с помощью выделения миграций, и контроля версий структуры.
Только все эти абстракции разрабатывать надо. И ладно бы просто разрабатывать. Их потом еще поддерживать надо :)
Поэтому все чаще хочется поиспользовать виртуализацию для таких радостей.
Сейчас у нас везде раставлены опции на эти случаи. Например разработчики используют файлы, вместо memcached на рабочих машинах, благодаря абстракции от cache storage. Sphinx тоже окружен абстракцией и она отдает просто набор случайных id'шников, если указана соответствующая опция. И с базкой можно более менее все устаканить с помощью выделения миграций, и контроля версий структуры.
Только все эти абстракции разрабатывать надо. И ладно бы просто разрабатывать. Их потом еще поддерживать надо :)
Поэтому все чаще хочется поиспользовать виртуализацию для таких радостей.
Отличный комментарий.
Мемекеш можно поставить на сервер разработки, сфинкс тоже, а вот с файловым хранилищем сложнее и для себя мы эту проблему пока не решили. На adme.ru около 300 гигабайт статики, и разумеется держать все это добро на сервере разработки накладно. Было бы интересно узнать как другие разработчики решают проблему с файлами.
Мемекеш можно поставить на сервер разработки, сфинкс тоже, а вот с файловым хранилищем сложнее и для себя мы эту проблему пока не решили. На adme.ru около 300 гигабайт статики, и разумеется держать все это добро на сервере разработки накладно. Было бы интересно узнать как другие разработчики решают проблему с файлами.
Ну у нас это тоже опции :)
Одна для определения куда класть файлик (на продакшене rpc, у разработчиков — просто копирование), другая для резолвинга URL'а.
Насчет memcached, sphinx и базки. Хорошо пока они стоят на одном сервере. Хорошо ровно до того момента пока кто-то не решил что-то в них поменять. Вася вдруг правит структуру конкретного кэша, и у него все работает. А вот Петя уже обламывается, ибо Вася еще новый код для работы с этим кэшом не закомитил.
В общем проблема в том, что структура и данные одни на всех, а код у всех разный.
Одна для определения куда класть файлик (на продакшене rpc, у разработчиков — просто копирование), другая для резолвинга URL'а.
Насчет memcached, sphinx и базки. Хорошо пока они стоят на одном сервере. Хорошо ровно до того момента пока кто-то не решил что-то в них поменять. Вася вдруг правит структуру конкретного кэша, и у него все работает. А вот Петя уже обламывается, ибо Вася еще новый код для работы с этим кэшом не закомитил.
В общем проблема в том, что структура и данные одни на всех, а код у всех разный.
Полностью согласен.
Но можете ли вы что-то предложить для решения этой проблемы, при том что дамп базы пару гигабайт а файлов и того больше?
Но можете ли вы что-то предложить для решения этой проблемы, при том что дамп базы пару гигабайт а файлов и того больше?
Самым популярным решением, насколько я понимаю, является хранение и дистрибуция структуры данных совместно с кодом — так называемые миграции.
Расскажу, как это реализованно у нас.
Мы не храним данные и не делаем «обратных» миграций. Мы оптимисты :)
А для заполнения «каким-то» контентом мы используем генераторы. Для поднятия фикстур в тестах мы используем паттерн ObjectMother и его же очень приятно использовать для подобных генераторов.
Действующие лица теже — Вася и Петя. У каждого на своей машинке отдельная база. В базе есть таблица schema_info, с единственной записью, в которой хранится номер версии структуры его базы(у нас это просто timestamp, что вызывает некоторые проблемы).
Итак:
1. Вася удаляет ненужное свойство из кода, и поле из базы.
2. Вася выполняет скрипт create_migration.php, который:
— создает файл с sql-кодом, с помошью которого из предыдущей версии можно получить текущую — файл миграции структуры данных;
— изменяет его версию базы;
3. Вася делает коммит кода и полученного файла миграции.
4. Петя делает update и увидев, что приехал файлик c миграцией, запускает migrate.php, который:
— применяет sql код на базу
— «поднимает» Васину версию структуры БД.
5. Вася и Петя исполняют танец «удачной синхронизации структур данных».
Вот как-то так.
Расскажу, как это реализованно у нас.
Мы не храним данные и не делаем «обратных» миграций. Мы оптимисты :)
А для заполнения «каким-то» контентом мы используем генераторы. Для поднятия фикстур в тестах мы используем паттерн ObjectMother и его же очень приятно использовать для подобных генераторов.
Действующие лица теже — Вася и Петя. У каждого на своей машинке отдельная база. В базе есть таблица schema_info, с единственной записью, в которой хранится номер версии структуры его базы(у нас это просто timestamp, что вызывает некоторые проблемы).
Итак:
1. Вася удаляет ненужное свойство из кода, и поле из базы.
2. Вася выполняет скрипт create_migration.php, который:
— создает файл с sql-кодом, с помошью которого из предыдущей версии можно получить текущую — файл миграции структуры данных;
— изменяет его версию базы;
3. Вася делает коммит кода и полученного файла миграции.
4. Петя делает update и увидев, что приехал файлик c миграцией, запускает migrate.php, который:
— применяет sql код на базу
— «поднимает» Васину версию структуры БД.
5. Вася и Петя исполняют танец «удачной синхронизации структур данных».
Вот как-то так.
> — создает файл с sql-кодом, с помошью которого из предыдущей версии можно получить текущую — файл миграции структуры данных;
Что используете для реализации этой волшебной штуки? Чем генерируете alter table?
Что используете для реализации этой волшебной штуки? Чем генерируете alter table?
Если кратко, то анализ результатов SHOW CREATE TABLE, SHOW FULL FIELDS, SHOW INDEX. Подробнее можно посмотреть в коде (многа букаф и код сторонних лиц).
У нас примерно также, но столько автотулз нету. Альтеры пишем либо руками, либо то что meta-генератор отдает (http://svn.shadanakar.org/listing.php? repname=onPHP&path=%2Ftrunk%2Fmeta%2F#_trunk_meta_).
Все клево, но есть 1 нюанс.
Человек часто ошибается. Поэтому когда проект большой людей много, то имеет место тенденция появления альтеров на альтер :-) В принципе, все бы ничего, пока не доходит до выкладки на прод. Когда альтеров много, это весьма неудобно и опасно (в плане того, что lock на субд будет весьма долго).
Все клево, но есть 1 нюанс.
Человек часто ошибается. Поэтому когда проект большой людей много, то имеет место тенденция появления альтеров на альтер :-) В принципе, все бы ничего, пока не доходит до выкладки на прод. Когда альтеров много, это весьма неудобно и опасно (в плане того, что lock на субд будет весьма долго).
Виртуализация всех спасет. «Большой» сервер-ферма под виртуальники. Отдельный виртуальник под базы (postgres, mysql), отдельный под рабочие копии (там же memcached — общий), если возникает необходимость — легко поднимаются еще виртуальники (файловые хранилища, sphinx и т.д.), благо стандартные образы под это дело всегда под рукой. Естествено, отдельный офисный svn. Так и работаем.
Для тестирования — отдельный физический сервер (или несколько), максимально повторяющий конфигурацию боевой среды.
Для тестирования — отдельный физический сервер (или несколько), максимально повторяющий конфигурацию боевой среды.
Ну у нас не такой длинный … бюджет :)
Да-да.
Ну, я же говорил про большой проект. :)
Если же проект не большой, то и описанные вами проблемы реже возникают, и разработчиков по-меньше, а значит и ресурсы нужны скромнее.
В разработке мы используем «облегченный» дамп боевой базы, и тормозов по-меньше, и можно несколько копий поднять. Если требуется внести серьезные изменения в базу, разработчик разворачивает свой дамп базы, меняет реквизиты базы в конфиге своей копии, и правит структуру там, никому не мешая, потом комминтит изменения. Да, всё равно, конфликты могут быть, но редко и решаются быстро.
А вот много гигабайт статики на сервере разработки тоже не храним, конечно. Тут есть варианты.
Если же проект не большой, то и описанные вами проблемы реже возникают, и разработчиков по-меньше, а значит и ресурсы нужны скромнее.
В разработке мы используем «облегченный» дамп боевой базы, и тормозов по-меньше, и можно несколько копий поднять. Если требуется внести серьезные изменения в базу, разработчик разворачивает свой дамп базы, меняет реквизиты базы в конфиге своей копии, и правит структуру там, никому не мешая, потом комминтит изменения. Да, всё равно, конфликты могут быть, но редко и решаются быстро.
А вот много гигабайт статики на сервере разработки тоже не храним, конечно. Тут есть варианты.
> А вот много гигабайт статики на сервере разработки тоже не храним, конечно. Тут есть варианты.
Какие? Не томите, говорите уже.
Какие? Не томите, говорите уже.
А это смотря что нужно получить.
Думаю, что _вся_ статика в рабочей копии просто не нужна никогда, достаточно, чтобы сохранялась структура хранилищ, это можно сделать созданием виртуальника-хранилища с ограниченным набором файлов, достаточным для разработки (скажем, выборка по базе — только за последнюю неделю).
Для тестирования можно настроить nginx на отдачу статики с боевого хранилища, а upload новых файлов — на тестовое.
Думаю, что _вся_ статика в рабочей копии просто не нужна никогда, достаточно, чтобы сохранялась структура хранилищ, это можно сделать созданием виртуальника-хранилища с ограниченным набором файлов, достаточным для разработки (скажем, выборка по базе — только за последнюю неделю).
Для тестирования можно настроить nginx на отдачу статики с боевого хранилища, а upload новых файлов — на тестовое.
Для небольших проектов описанный вариант вполне подойдет!
Спасибо, до фичи с nginx сам не додумался, руками делал :)
Спасибо, до фичи с nginx сам не додумался, руками делал :)
Мы используем похожую схему, только БД у нас не одна на всех, а у каждого разработчика своя копия. Это позволяет избежать проблем при изменениях, затрагивающих структуру БД.
В apache это ищите в help`е по пути:
Apache > HTTP Server > Documentation > Version 2.0 > Virtual Hosts
Dynamically configured mass virtual hosting
Apache > HTTP Server > Documentation > Version 2.0 > Virtual Hosts
Dynamically configured mass virtual hosting
Интересно :)
У нас похожая ситуация… только несколько иная реализация.
Важно было, чтобы домен не менялся, т.е. всегда и для всех оставался domain1.ru, а не domain1.petya.ru.
Один дев сервер, на нем самба, веб сервер, база, свн и т.п.
Все разработчики и дизайнеры работают локально (в одной сети с девом).
На сетевом диске, в директории вебсервера заведены папки вида 192.168.0.XXX/domain1.ru/html
В конфиге сервера прописаны правило для mod_rewrite:
И на машине разработчика, весь список нужных доменов (domain1.ru, domain2.ru, etc) перечислен в файле .../system32/.../hosts и указывает на айпи адрес сервера разработки. В итоге каждому отдается его версия сайта, с одного сервера.
У каждого есть доступ по сети (через самбу) до своей копии проектов :) и есть единая база данных.
У нас похожая ситуация… только несколько иная реализация.
Важно было, чтобы домен не менялся, т.е. всегда и для всех оставался domain1.ru, а не domain1.petya.ru.
Один дев сервер, на нем самба, веб сервер, база, свн и т.п.
Все разработчики и дизайнеры работают локально (в одной сети с девом).
На сетевом диске, в директории вебсервера заведены папки вида 192.168.0.XXX/domain1.ru/html
В конфиге сервера прописаны правило для mod_rewrite:
RewriteCond /data/www/%{REMOTE_ADDR}/%{HTTP_HOST}/html -d
RewriteRule ^/(.*) /data/www/%{REMOTE_ADDR}/%{HTTP_HOST}/html/$1 [QSA]
И на машине разработчика, весь список нужных доменов (domain1.ru, domain2.ru, etc) перечислен в файле .../system32/.../hosts и указывает на айпи адрес сервера разработки. В итоге каждому отдается его версия сайта, с одного сервера.
У каждого есть доступ по сети (через самбу) до своей копии проектов :) и есть единая база данных.
Недостатки вашего способа:
1. кокнретную рабочую копию нельзя показать клиенту (наружу не вынесено)
2. нельзя зайти на рабочую копию другого сотрудника, например своим браузером
3. приходится прописывать в hosts домены
а в остальном вполне жизнеспособная схема.
1. кокнретную рабочую копию нельзя показать клиенту (наружу не вынесено)
2. нельзя зайти на рабочую копию другого сотрудника, например своим браузером
3. приходится прописывать в hosts домены
а в остальном вполне жизнеспособная схема.
Цель как раз, изолировать рабочие копии разных разработчиков :)
Смотреть ее можно после commit + update svn, в своей рабочей версии
А для прописывания в hosts, созданы два бат файла, вроде hosts_on.bat и hosts_off.bat
Показать клиенту — можно созданием простого создания линка папки с нужным айпи адресом и прописыванием у него хостов…
Но, нам необходимо было сохранение доменов как на продакшен сервере, поэтому на продакшен сервере всегда работает последняя стабильная версия :)
Смотреть ее можно после commit + update svn, в своей рабочей версии
А для прописывания в hosts, созданы два бат файла, вроде hosts_on.bat и hosts_off.bat
Показать клиенту — можно созданием простого создания линка папки с нужным айпи адресом и прописыванием у него хостов…
Но, нам необходимо было сохранение доменов как на продакшен сервере, поэтому на продакшен сервере всегда работает последняя стабильная версия :)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как организовать рабочие копии множества проектов для множества разработчиков на одном сервере разработки