Comments 67
UFO just landed and posted this here
UFO just landed and posted this here
читал
Кидать ссылку без сопроводительной информации, даже без пары слов — по-моему, не очень красиво.
А вообще, по ссылке выше идёт более узкоспециализированная информация, причем немного отдалённая от сути этого топика.
Я, например, думаю, что человек с удалённым сервером найдёт, как туда поставить lamp.
А в этом топике опускаются ненужные тонкости, что повышает её ценность, т.к. рассказывается именно подход. Причём поэтапно.
Это ведь тоже немаловажно. Если другая ide, или отсутствие тестового сервера — все факторы тем не менее позволят настроить и понять как пушить всем разом на удалённый сервер из среды разработки. Странно читать о настройках php 5.x и php.ini, если нужно настроить совместный удалённый контроль версий.
Так что каждому — своё, а автору — плюс.
А вообще, по ссылке выше идёт более узкоспециализированная информация, причем немного отдалённая от сути этого топика.
Я, например, думаю, что человек с удалённым сервером найдёт, как туда поставить lamp.
А в этом топике опускаются ненужные тонкости, что повышает её ценность, т.к. рассказывается именно подход. Причём поэтапно.
Это ведь тоже немаловажно. Если другая ide, или отсутствие тестового сервера — все факторы тем не менее позволят настроить и понять как пушить всем разом на удалённый сервер из среды разработки. Странно читать о настройках php 5.x и php.ini, если нужно настроить совместный удалённый контроль версий.
Так что каждому — своё, а автору — плюс.
Не могли бы вы чуть подробнее расписать вот эту схему:
===
Теперь после каждого push'а все файлы на сервере будут приводится к файлам из репозитория, можно такой же подход реализовать и на тест сервере, но в этом случае если один разработчик имеет незапушеные файлы, то на сервере они затрутся и их придется заново загружать.
===
?
Просто если бы содержимое тест-сервера обновлялось только по push-ингу из локальных репозиториев разработчиков, то ошибки из-за незапушенных файлов уже проявлялись бы на момент тестирования на тест-сервере.
А может я просто не до конца представляю себе схему взаимодействия для этого случая? )
===
Теперь после каждого push'а все файлы на сервере будут приводится к файлам из репозитория, можно такой же подход реализовать и на тест сервере, но в этом случае если один разработчик имеет незапушеные файлы, то на сервере они затрутся и их придется заново загружать.
===
?
Просто если бы содержимое тест-сервера обновлялось только по push-ингу из локальных репозиториев разработчиков, то ошибки из-за незапушенных файлов уже проявлялись бы на момент тестирования на тест-сервере.
А может я просто не до конца представляю себе схему взаимодействия для этого случая? )
подразумевается что в пуш попадают уже законченные, протестированные фичи
т.к. разработка ведется на одном удаленном сервере — всю работу сразу же видно и сразу же можно её протестировать, до отправки в репозиторий и на продакшн соответственно
т.к. разработка ведется на одном удаленном сервере — всю работу сразу же видно и сразу же можно её протестировать, до отправки в репозиторий и на продакшн соответственно
Я про вот эту ситуацию:
==
можно такой же подход реализовать и на тест сервере
==
==
можно такой же подход реализовать и на тест сервере
==
задачи практически не пересакаются, поэтому ошибки не появились бы из-за удаленных и незапушеных файлов чьих-то, но вообще автопул на тестовом сервере не очень удобно из-за того что в момент работы другого человека его правки могут удалиться с сервера
Все ж таки, не совсем понятно. В первоначальном варианте данные из IDE пользователя сохраняются на тестовом сервере при сохранении (CTRL+S). Когда рассматривается «такой же подход на тестовом сервере» — как это выглядит? Данные на тестовый сервер поступают только при push-ах из локальных репозиториев разработчиков? И как тогда в этом случае выполняется отладка изменений перед push-ингом?
Вообще, PHPStorm умеет выгружать и на выбранный сервер при коммите. Собственно так и работаю как у вас, но не нужна «Настройка автопула на боевом сервере» и тех танцев, что у вас описаны. Проще, без заморочек, потери времени и прочего. Но для саморазвития полезно. Спасибо.
Тестовый сервер (проект на нём) один для всех разработчиков без контроля версий?
один сервер для всех разработчиков, но с системой контроля версий, как показала практика в небольшой команде это хорошо работает и легко настраиватся и поддерживается
Хм, из статьи не видно, что по Ctrl+S будет автоматом комит на тестовый сервер.
при Ctrl+S будет аплод только на тест сервер, чтобы было видно результат работы, коммит будет при коммите
Вот это меня и беспокоит, разве на тестовом сервере нету конфликтов в коде от разных разработчиков?
нету, об этом и речь, иначе мы бы не смогли использовать такую схему
задачи не пересекаются по файлам
задачи не пересекаются по файлам
Всё же тестировать на одном общем сервере чревато не только конфликтами в исходниках. Как правило первое исполнение своего кода приводит к ошибкам. А тут ещё непроверенный код от других разработчиков в любую секунду появляется.
Обычно, у каждого разработчика своя песочница на тестовом сервере, а окружение одно. И много проблем даже из-за того, что кто-то при тестирование добавил неверные данный в базу/кеш/файловое хранилище/итп. Такое метод применяют только потому, что на проектах с большим стеком технологий (практически весь хайлоад) настроить окружение не так просто, да и требования к локальной машине поболее.
Но что бы еще и код был один и тот же — это очень специфичное и бессмысленное решение, да и подойдет только единичным проектам.
Но спасибо за мануалы, мне очень помог по XDebug, не мог у себя настроить, долго мучился без него.
Но что бы еще и код был один и тот же — это очень специфичное и бессмысленное решение, да и подойдет только единичным проектам.
Но спасибо за мануалы, мне очень помог по XDebug, не мог у себя настроить, долго мучился без него.
А как происходит обновление удалённой директории когда меняется бранч?
Т.е. я локально работаю с TortoiseHG, меняю в нём бранч… как обновить удалённую директорию?
Второй вопрос
Почему не дать каждому разработчику свою директорию, в которой каждый будет работать в своём бранче?
Т.е. я локально работаю с TortoiseHG, меняю в нём бранч… как обновить удалённую директорию?
Второй вопрос
это позволит узнать если кто-то правил тот же файл
Почему не дать каждому разработчику свою директорию, в которой каждый будет работать в своём бранче?
IDE позволяет одновременно делать выгрузку по FTP
Там есть опция Upload, если в контекстном менб проекта и папок, но при выполнении этого действия аплоадятся 1) только новые файлы, т.е. изменённые с переключением на другой бранч все изменённые файлы в удалённую директорию не попадают. 2) Старые файлы которых нет в бранче на который переключился — не удаляются.
т.е не понятно как без сторонних тулз сделать удалённую директорию точно такой как в бранче при переключении.
т.е не понятно как без сторонних тулз сделать удалённую директорию точно такой как в бранче при переключении.
сложность в организации, настройке и поддержке(если не понятно какие сложности возникают могу пояснить), проще использовать один общий тест-сервер
Так вы всё это время про тест сервер говорили, или про дев?
Даже если про тест, не знаю насколько велика ваша команда, но у нас 10 тест енвейрментов.
Даже если про тест, не знаю насколько велика ваша команда, но у нас 10 тест енвейрментов.
у нас один тест-сервер, общий для всех 3-4 человек
Так а что с синхронизацией кода с сервером при смене бранча, как вы это делаете?
тест-сервер ничего не знает о бранчах и репозитории — на него просто загружают файлы по Ctrl+S
Понятно что он не знает.
Я выше в комментарии описал суть проблемы, как переключившись на бранч ЛОКАЛЬНО заапплоадить все изменившиеся файлы локально, удалить с сервера не нужные файлы, т.е. привести директории в соответствие.
Я выше в комментарии описал суть проблемы, как переключившись на бранч ЛОКАЛЬНО заапплоадить все изменившиеся файлы локально, удалить с сервера не нужные файлы, т.е. привести директории в соответствие.
Там есть опция Upload, если в контекстном менб проекта и папок, но при выполнении этого действия аплоадятся 1) только новые файлы, т.е. изменённые с переключением на другой бранч все изменённые файлы в удалённую директорию не попадают. 2) Старые файлы которых нет в бранче на который переключился — не удаляются.
т.е не понятно как без сторонних тулз сделать удалённую директорию точно такой как в бранче при переключении.
Это можно сделать средствами PHPStorm — Synchronize directory
Тем временем другой разработчик (у вас ведь их 3-4) будет синхронизировать другую ветку… очередной конфликт командной разработки.
Один тестовый сервер сойдет для тестов перед выпуском проекта. Для разработчиков нужно иметь своё окружение. У них и так на локале код проекта, среда разработки. Почему оказывается накладно для разработчика установить ещё http сервер и субд?
Один тестовый сервер сойдет для тестов перед выпуском проекта. Для разработчиков нужно иметь своё окружение. У них и так на локале код проекта, среда разработки. Почему оказывается накладно для разработчика установить ещё http сервер и субд?
у нас просто нет необходимости создавать бранчи, поэтому для нас этот подход работает, если все работают с одними файлами тогда конечно — создание бранчей, индивидуальное окружение, просто надо понимать чтобы бывают разные проекты и бывают разные, рабочие решения
Я даже не знаю что сказать… работа без бранчей для меня давно кажется… противоестественной =)
Даже если бы я работал один — я бы делал бранчи для новых фич.
Вдруг что-то нужно захотфиксить в проде, а ты в этот момент делаешь новую фичу?.. Быстро сделал бранч из продового тэга, задеплоил, потом замерджил апдейт в свой фичебранч… короче процесс… не понимаю как можно по другому… без бранчей =)
Даже если бы я работал один — я бы делал бранчи для новых фич.
Вдруг что-то нужно захотфиксить в проде, а ты в этот момент делаешь новую фичу?.. Быстро сделал бранч из продового тэга, задеплоил, потом замерджил апдейт в свой фичебранч… короче процесс… не понимаю как можно по другому… без бранчей =)
В 99% случаев можно поправить прямо в продовом бранче (именно бранче, тэги тут не очень и нужны), проверить, закоммитить и выложить на прод, как обычно. Не нужно ответвлять что-то от продового бранча (на то они и срочные фиксы, чтобы быть маленькими). Но дев-бранч и прод-бранч обязаны быть разными, конечно, без этого никак.
именно бранче, тэги тут не очень и нужны
Если теги не нужны, как потом откатываться, если релиз оказался неудачным?
Точнее до чего откатываться? Для этого релизы фиксируются тегами и в логе прода можно посмотреть в каком порядке релизы попадали в прод и откатиться до предыдущей версии. В нашем случае — одной кнопкой rollback в деплоере.
Не нужно ответвлять что-то от продового бранча
Ну у нас это формальный процесс, поэтому так. На самом деле сделать бранч — дело двух минут. Ишу в багтрекере, новый бранч из id ишу, пишем в него фикс, коммитим, деплоим. При желании даже тут есть место автоматизации, сделать какой-то UI, который будет по нажатию кнопки создавать ишу в багтрекере и бранч из продового тега с нужным именем. Останется только переключиться на него, вписать фикс и запушать/задеплоить.
О, может быть, вы — тот единственный человек, который на практике откатывает релизы в веб-проектах! Я давно вас ищу. Опровергните меня аргументированно тогда, пожалуйста.
Так вот, лично мое мнение заключается в том, что откатывать ничего и не нужно, потому что после релиза чего-то на веб-проект это в общем случае и невозможно соткатить. Код-то откатить не проблема. Но беда в том, что в каждом релизе (практически) меняется схема БД, которую откатить либо невозможно, либо очень сложно и долго по времени. Откатывать же БД с прямо с данными из бэкапа нельзя, т.к. а) потеряются данные пользователей за последние минуты, и б) это просто может занять несколько часов. В может ли старый код (откаченный) работать с новой структурой базы так, чтобы потом не возникло кучи нестгласованности в данных? Чаще всего — нет.
Соответственно, чтобы при накате релиза спать спокойно, надо этот накат вначале отрепетировть на каком-то тестовом кластере (это третий кластер: первый — дев, второй — прод), и на этот тестовый кластер должна быть развернута точная копия (пусть и сокращенная) продакшена.
Так вот, лично мое мнение заключается в том, что откатывать ничего и не нужно, потому что после релиза чего-то на веб-проект это в общем случае и невозможно соткатить. Код-то откатить не проблема. Но беда в том, что в каждом релизе (практически) меняется схема БД, которую откатить либо невозможно, либо очень сложно и долго по времени. Откатывать же БД с прямо с данными из бэкапа нельзя, т.к. а) потеряются данные пользователей за последние минуты, и б) это просто может занять несколько часов. В может ли старый код (откаченный) работать с новой структурой базы так, чтобы потом не возникло кучи нестгласованности в данных? Чаще всего — нет.
Соответственно, чтобы при накате релиза спать спокойно, надо этот накат вначале отрепетировть на каком-то тестовом кластере (это третий кластер: первый — дев, второй — прод), и на этот тестовый кластер должна быть развернута точная копия (пусть и сокращенная) продакшена.
Сорри за опечатки, писал с телефона.
Я думаю, что как всегда — всё зависит от ситуации.
Команда в которой я работаю имеет два основных проекта, один публичный портал, другой внутренний.
Внутренний — гораздо больше. Им пользуются сотрудники компании и мы в принципе берём за основной девиз велосити и готовы к тому, что иногда что-то ломается. Во внутреннем портале у нас больше велосити, меньше QA, во внешнем — больше QA меньше велосити. Поскольку для внутреннего портала релизы зачастую тестируются только разработчиками — то откаты там случаются до пары раз в месяц. Когда сразу — выкатили, опачки, один из сервисов некорректно работает (а мы работаем с десятком внутренних же сервисов) — откатили, другие откатываются через часы после релиза, позже — обычно скрипя зубами фиксим, так как за это время уже другие люди могли накидать своих хотфиксов сверху (не обязательно фиксов, микрорелизов).
Что касается базы, не все релизы связаны с некой записью-чтением БД, иногда она никак не затрагивается и откатывать можно спокойно, есть другие сервисы с которыми мы работаем и при этом в них ничего не пишем или такие сервисы куда пишем но структуру/апи почти никогда не меняем. Поэтому чтобы нужно было откатывать БД такое случается довольно редко. Большинство изменений связанных с БД происходят с добавлением новых полей и таблиц, которые в продакшен ухотят и так за некоторое время до релиза, в котором они нужны и откат можно провести не трогая бд — поля и таблицы так и останутся в проде.
Ну и если всё плохо, конечно откатываем, накатываем определённые таблицы БД обратно.
Реально доставляющие проблемы релизы случаются довольно редко, мы к ним готовимся, делаем бекапы, скрипты отката, ставим портал в мейнтененс мод или рид-онли, релизим, QA прогоняют автоматические тесты и если всё более менее ок тогда открываем портал и т.д.
Команда в которой я работаю имеет два основных проекта, один публичный портал, другой внутренний.
Внутренний — гораздо больше. Им пользуются сотрудники компании и мы в принципе берём за основной девиз велосити и готовы к тому, что иногда что-то ломается. Во внутреннем портале у нас больше велосити, меньше QA, во внешнем — больше QA меньше велосити. Поскольку для внутреннего портала релизы зачастую тестируются только разработчиками — то откаты там случаются до пары раз в месяц. Когда сразу — выкатили, опачки, один из сервисов некорректно работает (а мы работаем с десятком внутренних же сервисов) — откатили, другие откатываются через часы после релиза, позже — обычно скрипя зубами фиксим, так как за это время уже другие люди могли накидать своих хотфиксов сверху (не обязательно фиксов, микрорелизов).
Что касается базы, не все релизы связаны с некой записью-чтением БД, иногда она никак не затрагивается и откатывать можно спокойно, есть другие сервисы с которыми мы работаем и при этом в них ничего не пишем или такие сервисы куда пишем но структуру/апи почти никогда не меняем. Поэтому чтобы нужно было откатывать БД такое случается довольно редко. Большинство изменений связанных с БД происходят с добавлением новых полей и таблиц, которые в продакшен ухотят и так за некоторое время до релиза, в котором они нужны и откат можно провести не трогая бд — поля и таблицы так и останутся в проде.
Ну и если всё плохо, конечно откатываем, накатываем определённые таблицы БД обратно.
Реально доставляющие проблемы релизы случаются довольно редко, мы к ним готовимся, делаем бекапы, скрипты отката, ставим портал в мейнтененс мод или рид-онли, релизим, QA прогоняют автоматические тесты и если всё более менее ок тогда открываем портал и т.д.
Ага, колонки добавляются заранее, до релиза, и так, чтобы они не портили совместимости с существующим (в будущем — старым) кодом. Но возникает вопросы: а как же с разными constraint-ами (например, not null)? И как, меняя базу, быть уверенными, что это изменение, накаченное отдельно, не сломает существующий код?
Сдается мне, что все разрешенные изменения в структуре БД при этой схеме сводятся к 2 операциям:
1. Создание новой nullable колонки, причем такой, что код умеет правильно null-ы там интерпретировать, даже если по логике предметной области их там быть не может.
2. Добавление новой таблицы.
Сдается мне, что все разрешенные изменения в структуре БД при этой схеме сводятся к 2 операциям:
1. Создание новой nullable колонки, причем такой, что код умеет правильно null-ы там интерпретировать, даже если по логике предметной области их там быть не может.
2. Добавление новой таблицы.
как же с разными constraint-ами (например, not null)
Ну если нул -то понятно в колонках будет нул до релиза, если не нул — обычно ставится default "...".
Иногда при релизе готовится какой-то транзишен/релиз скрипт, который прописывает что-то осмысленное в колонки.
И как, меняя базу, быть уверенными, что это изменение, накаченное отдельно, не сломает существующий код?
Ну новая колонка/таблица точно ничего не сломает, модификация полей происходит редко.
В целом по обоим пунктам — может мы просто не ставим никаких строгих условий, но не помню чтобы с этим были какие-то проблемы.
Сдается мне, что все разрешенные изменения в структуре БД при этой схеме сводятся к 2 операциям
Ну да, или nullable или дефолт, если это подходит.
Опять таки, в любом случае, если релиз откачен и задеплоен заново — можно прогнать скрипт, который проставит значения.
Проставит-то он проставит, да вот только за промежуток времени, когда он уже закончит работу, а новый релиз еще не накачен, в новых колонках опять образуются несогласованные данные, с которым новому коду (после релиза) надо будет иметь дело. В принципе, можно снова скрипт запустить, чтобы он по оставшимся (новым) данным прошелся, но все же это как-то сложно все… Шаг в сторону нестрогой схемы данных и отсутствия контроля целостности со стороны БД, что ли, хотя, конечно, на больших базах без асинхронного скрипта-пробивателя в любом случае не обойтись.
Ну, скрипт можно запустить после того как релиз накачен, если условиями это позволяется. У нас это обычно так. В крайнем случае, как я упоминал выше — ставится мейнтенанс мод и никакие новые записи не появляются. Опять таки в нашем конкретном случае можно себе это позволить. Для тех у кого система вечно живая и её невозможно остановить — ну да, нужно догонять, досинхронизировать. Ну, это уже всё такая теория… что на любой абстрактный вариант можно придумать любую абстрактную проблему, такие вещи нужно придумывать подкладывая к реальному случаю, реальной системе =)
Почему накладно установить http сервер и субд?
потому что вместе с этим нужно будет ставить:
redis
sphinx
IIP
видео утилиты (у нас свой видео хостинг)
прорву модулей для PHP
настраивать как-то выполнение утренних крон-задач(очень ресурсоемких) — т.к. иначе на следующий день просто не будет множества данных которые каждый день агрегируются
ну и плюс к этому нужно постоянно будет синхронизировать конфиги, модули, доп. ПО серверное, общие файлы
На мой взгляд идеальное решение это один сервер, на котором у каждого разработчика своя песочница, но окружение при этом общее, возможно мы скоро это организуем, но пока наше решение у нас работает
а вот создавать каждому верстальщику виртуальную машину — бред.
потому что вместе с этим нужно будет ставить:
redis
sphinx
IIP
видео утилиты (у нас свой видео хостинг)
прорву модулей для PHP
настраивать как-то выполнение утренних крон-задач(очень ресурсоемких) — т.к. иначе на следующий день просто не будет множества данных которые каждый день агрегируются
ну и плюс к этому нужно постоянно будет синхронизировать конфиги, модули, доп. ПО серверное, общие файлы
На мой взгляд идеальное решение это один сервер, на котором у каждого разработчика своя песочница, но окружение при этом общее, возможно мы скоро это организуем, но пока наше решение у нас работает
а вот создавать каждому верстальщику виртуальную машину — бред.
Верстальщиков я не имел в виду, им xDebug не нужен. В чём накладно теперь понятно. А не расскажете, как делаются «песочницы»?
я бы делал такт:
на каждого разработчика создаем все домены проекта в http серверах, например
vasya.video.project.ru
vasya.travel.project.ru
petya.video.project.ru
petya.travel.project.ru
и т.д.
но не прописываем их в днс, а прописываем только в hosts(для простоты) на локале, далее файлы так организовываем
1. файлы из репы заливаем в рабочую директорию веб-сервера и настраиваем свою IDE на работу со своей песочницей
2. общие файлы(аплод, кеш и пр.) — делаем симлинки на основную директорию где все это есть
3. конфиги создаем индивидуально
т.о. у каждого своя песочница, при желании можно поправить конфиг и юзать собственную изолированную БД, или допустим вместо симлинка на кеш создать собственный кеш, при этом никто никому не мешает, но имеет общее окружение
на каждого разработчика создаем все домены проекта в http серверах, например
vasya.video.project.ru
vasya.travel.project.ru
petya.video.project.ru
petya.travel.project.ru
и т.д.
но не прописываем их в днс, а прописываем только в hosts(для простоты) на локале, далее файлы так организовываем
1. файлы из репы заливаем в рабочую директорию веб-сервера и настраиваем свою IDE на работу со своей песочницей
2. общие файлы(аплод, кеш и пр.) — делаем симлинки на основную директорию где все это есть
3. конфиги создаем индивидуально
т.о. у каждого своя песочница, при желании можно поправить конфиг и юзать собственную изолированную БД, или допустим вместо симлинка на кеш создать собственный кеш, при этом никто никому не мешает, но имеет общее окружение
А зачем ставить всё это по отдельности? По сути просто папки и тестовые домены. Вебсервер работающий в подобном проде енвайрнменте. Синхронизировать заливать продовую базу с дев раз в какое-то время.
База на всех одна, как и прочие сервисы.
База на всех одна, как и прочие сервисы.
>> Если отладку можно получить с помощью Xdebug, а скорость переехав на другой сервер, то третье преимущество..
… можно сохранить, используя ферму виртуальных машин?
… можно сохранить, используя ферму виртуальных машин?
По идее необходимо в гите держать три ветки -stable/test/dev и уже из них выгружать на тестовый сервер и на продакшн.
А что касаемо рабочего места, то пожалуй для веб-разработки (для проектов на *nix хостинге) лучше использовать linux + phpstorm(linux) или netbeans (и локально поднятый LAMP) и отказаться от windows более чем полностью (я говорю о программистах, не дизайнер или верстальщик, в их случае с этим посложнее).
А что касаемо рабочего места, то пожалуй для веб-разработки (для проектов на *nix хостинге) лучше использовать linux + phpstorm(linux) или netbeans (и локально поднятый LAMP) и отказаться от windows более чем полностью (я говорю о программистах, не дизайнер или верстальщик, в их случае с этим посложнее).
А для чего нужна ета схема с git reset --hard и копированием только .git и .gitignore?
git reset --hard как и удаление файлов из git status нужно чтобы pull прошел без ошибок, если на сервере есть какие-либо правки(например срочно что-то правили, а только потом внесли в репу)
копирование .git и .gitignore нужно т.к. проект уже рабочий и он лежит себе в своей директории веб-сервера, при этом нужно файлы из репозитория скопировать с заменой в директорию вебсервера(при первичном подключении репы), можно конечно просто скопировать, а можно скопировать только .git и .gitignore и запустить git reset --hard — результат будет один и тот же
Если у Вас код хранится на BitBucket, то можно использовать для автодеплоя jenkins (или другой CI-сервер). Он опрашивает репозитарий и при появлении новых коммитов делает git pull.
У нас такая схема вполне прижилась.
У нас такая схема вполне прижилась.
Sign up to leave a comment.
PHPStorm + XDebug + Bitbucket: разработка на удаленном сервере в небольшой команде