Comments 86
скриптик cifs_mount.sh
VBoxLinuxAdditions из коробки
ввести svn up или git pull origin master
То есть, без версий продукта, тестов и миграции БД? Горячо любимая HHP методология :)
Пожалуй самое лучшее из того что я знаю — OpenServer. Еще очень неплох AppServ, я его даже использовал в реальном проекте, где нужен был локальный web-сервер в сетке из десятка windows-машин.
Ну а для окончательного тестирования в продакшене все равно придется на реальный хостинг закачивать:)
https://www.ansible.com/
Проекты в production у нас работают или на одном сервере, или если серверов несколько, в Amazon Beanstalk, который берет управление развертыванием на себя.
А на локальных компах огород городить — это как-то несовременно.
Каждому по песочнице, а что такого?
А то, что тогда дешевле эти песочницы держать на разработческом компе — и с точки зрения ресурсов, и с точки зрения доступности, и с точки зрения скорости работы.
Каждый разработчик должен тратить время на настройку всей инфраструктуры, тогда как на сервере разработки всё можно сделать централизовано: быстро и правильно, силами самого квалифицированного в администрировании инженера. Особенно актуально, например, если в проекте есть какая-то непривычная инфраструктура. Ты либо отправляешь разработчика целый день возиться с настройкой и запуском того, с чем он раньше не имел дела, либо копируешь ему ещё одну песочницу и ставишь боевые задачи.
И не забываем, что всё-таки так мы избавляемся от возможных эффектов несовместимости в реализации технологий под разные платформы, которые всё-таки есть.
Есть ещё отличный эффект — тонкий клиент проще настраивать. Разработчик поставил путти, какой-то IDE и побежал работать. Купил новый ноут, установил ось и через полчаса снова работает в привычном окружении с любыми своими проектами. Сломался ноут — временно взял другой и снова может работать.
Так что здесь отнюдь не так очевидно, что выходит дешевле.
Чем же дешевле?
А давайте мы сначала определимся, что с чем мы сравниваем. У вас, внезапно, разработческий сервер эквивалентен тонким клиентам, хотя это не одно и то же. Если вы хотите пообсуждать, удобно ли разработчику работать на тонком клиенте — то так и напишите; я же пока буду обсуждать то, что я изначально имел в виду: ситуацию, когда разработчик ведет разработку локально (т.е., исходники и IDE стоят на его компьютере), а вот разворачивает он это для проверки — куда-то еще.
Каждый разработчик должен тратить время на настройку всей инфраструктуры, тогда как на сервере разработки всё можно сделать централизовано: быстро и правильно, силами самого квалифицированного в администрировании инженера.
Если у вас сервер разработки один, то у вас будут проблемы из-за взаимного влияния разработчиков. Если же у вас каждому разработчику выдается свой "сервер разработки", то нет никакой разницы, порождаются они централизованно, или локально — все равно они разворачиваются из шаблона или скриптом, и человек в этом участвует минимально.
Ты либо отправляешь разработчика целый день возиться с настройкой и запуском того, с чем он раньше не имел дела, либо копируешь ему ещё одну песочницу и ставишь боевые задачи.
Что мешает скопировать песочницу на рабочий компьютер разработчика?
И не забываем, что всё-таки так мы избавляемся от возможных эффектов несовместимости в реализации технологий под разные платформы, которые всё-таки есть.
… это если у вас строго одна целевая платформа в продакшне. Как только это меняется (их становится больше), ваша задача — не избавится от эффектов несовместимости, а поймать их как можно раньше.
Так вот, мы уже выяснили, что у каждого разработчика есть своя "песочница" (не важно, виртуалка, контейнер), стоимость развертывания которой, выраженная в человеческих силах, пренебрежима и не отличается между централизованным развертыванием и локальным. А дальше все сводится к банальной задаче нахождения компромиса, где с одной стороны — удобство разработчика (чем ближе к нему песочница, тем быстрее у него будет проходить цикл внесения изменений и тем меньше он зависит от централизованной инфраструктуры) и уменьшение стоимости владения (не надо иметь мощную централизованную инфраструктуру для развертывания множества песочниц), а с другой стороны — увеличение нагрузки на локальный компьютер разработчика (и, таким образом, увеличение расходов на каждый такой компьютер).
Плюсы, как я их вижу, я уже описывал. Забыл только упомянуть о том, что благодаря такому решению вся работа доступна в любой момент для демонстрации или для быстрой консультации с коллегами. Недостатки я тоже понимаю — есть некоторые неудобства связанные с не мгновенным сохранением файла, и с тем, что многие популярные IDE не умеют работать с удалёнными файлами через нормальные протоколы.
Если вы всё сделаете в кроссплатформенных контейнерах, которые неважно где раскладывать — это отлично, почти все плюсы удалённого сервера будут соблюдены, кроме возможности мгновенной демонстрации. Ну и требования к локальной инфраструктуре разработчика всё равно будут выше — надо будет развернуть весь этот зоопарк с докерами и вагрантами. (Я понимаю, с определённого уровня квалификации кажется, что это естественно, нормально и просто, но дать всё это стажёру или джуниору — и он наверняка потеряет день-другой, и будет терять его всякий раз, когда дашь ему проект.)
Если же вы работаете стабильным-квалифицированным составом над одним большим проектом, то вполне допускаю, что плюсы удалённого сервера разработки могут потерять актуальность.
Рабочая копия проекта, рабочая копия базы и прочее такое — все это лежит на сервере/серверах разработки. Работа, таким образом, включая редактирование файлов, ведётся через интернет.
Прежде чем обсуждать что-либо далее, давайте уточним: что такое "рабочая копия проекта"? Та, над которой ведется работа? Или стабильная?
То есть вы — совершенно серьезно — предлагаете разработчику работать не с локальной файловой системой, а с произвольно удаленной?
Окей, тезис понятен.
Во-первых, "что такого". Знаете, мы тут (уже давно, правда) перешли с HDD на SSD для исходников — и это дало ощутимый прирост в комфорте работы. А вы предлагаете унести файлы за удаленное (и негарантированное) соединение — тем самым радикально понизив тот самый комфорт. А если я в самолете хочу поработать? В поезде? Ну или хотя бы в кафе?
Во-вторых, просто представьте себе, что изменения файла в файловой системе недостаточно для запуска приложения. Ну знаете, не все работают в директории веб-сервера, да и бывает такая ересь как компилируемые языки. Теперь после сохранения нужно еще запустить процесс запуска — в лучшем случае сразу на удаленном сервере на этот же сервер, в среднем — забрав обратно исходники и запустив локально, и в худшем — забрав исходники, собрав результат, и положив его обратно на удаленный сервер.
Во-третьих, вернемся к вашим тезисам из коммента повыше.
Забыл только упомянуть о том, что благодаря такому решению вся работа доступна в любой момент для демонстрации или для быстрой консультации с коллегами.
Если у вас есть стабильный сценарий развертывания любой версии из версионника — а он должен быть — то у вас и так вся работа доступна.
Ну и требования к локальной инфраструктуре разработчика всё равно будут выше — надо будет развернуть весь этот зоопарк с докерами и вагрантами. (Я понимаю, с определённого уровня квалификации кажется, что это естественно, нормально и просто, но дать всё это стажёру или джуниору — и он наверняка потеряет день-другой, и будет терять его всякий раз, когда дашь ему проект.)
Не всякий раз, а первый раз. А потом научится. А если не давать, то не научится никогда. И да, это тоже автоматизируется.
Что касается компилируемых языков. Вообще изначально обсуждение идёт о lamp-стеке, но даже если уйти от этого, если честно, то я не вижу разницы с тем случаем, когда все файлы лежат локально. Какая разница, где запускать компиляцию — здесь или там?
Развёртывание любой версии из VCS — не решает задачу быстрой демонстрации. Слишком много хлопот для короткого обсуждения — быстренько отгрузить на какой-то показной сервер (который, получается, должен быть готов к этому в плане прочей инфраструктуры, и не должен быть занят никаким другим показом и т.д.)
Научится — это конечно хорошо. Только у вас получается, что нижняя граница даже самой простой работы поднимается до уровня владения нетривиальными инструментами. Это удорожание разработки в чистом виде.
А что если я хочу с другого ноута поработать? Или с компа своей жены?
То вам ничто не поможет, кроме тонкого клиента.
И нет, в этой ситуации нет ничего странного: я регулярно работал в кафе, я много раз видел людей, работающих в поезде, и даже в самолете — встречал (хотя, будем честными, в самолете без интернета вообще я бы работать не стал). И таких людей намного больше, чем людей, которые хотят поработать с ноута своей жены.
Что касается компилируемых языков. Вообще изначально обсуждение идёт о lamp-стеке, но даже если уйти от этого, если честно, то я не вижу разницы с тем случаем, когда все файлы лежат локально. Какая разница, где запускать компиляцию — здесь или там?
Принципиальная: вам нужно сначала дотащить "туда" команду на исполнение, а потом "обратно" — результат ее выполнения. Это все увеличивает накладные расходы (и, заодно, сложность ПО).
Развёртывание любой версии из VCS — не решает задачу быстрой демонстрации. Слишком много хлопот для короткого обсуждения
Задачу "короткого обсуждения" уже давно успешно решает "подойди посмотреть", если в офисе, и "пошарить скрин в скайпе", если удаленно.
Научится — это конечно хорошо. Только у вас получается, что нижняя граница даже самой простой работы поднимается до уровня владения нетривиальными инструментами. Это удорожание разработки в чистом виде.
Неа. Для "самой простой работы" вообще не нужен ни вагрант, ни докер — ничего. Просто поставьте инструментарий локально. Изолированные среды нужны тогда, когда сложность работы растет — а вместе с ней растут и требования к уровню разработчика.
И да, вы сейчас звучите так же, как дцать лет назад звучали люди, которые говорили, что VCS — нетривиальный инструмент, и они не хотят учиться им пользоваться.
Взять вот ребят из начала поста. У них там, судя по всему, веб-проекты на битриксе, а это короткие по времени и объему работы проекты, более-менее типовые, и что греха таить, скучные для большинства разработчиков. Но это ниша и кому-то надо делать простые сайты, в которых нет смысла разносить микросервисы по контейнерам и обучать вагранту вчерашних студентов, с годом опыта работы на пхп.
Всему своё место, в общем.
компилируемые языки отдельная штука. но имхо, проще взять один очень мощный серв который будет компилить исходники скажем 15 минут и заморочится софтом для деплоя, чем каждому разрабу дать машину, которая будет компилить эти же исходники хотябы час.
С одной стороны да… а с другой — представьте, что у вас пять разработчиков, каждый закоммитил свой код, и каждый хочет посмотреть результат.
в случае с вебом есть еще такая штука как кеши, менеджеры очередей, воркеры. чтобы локально поднять рабочую копию приложения нужно будет локально развернуть все бд с какимито тестовыми данными. Поднять всякие еластики, редисы, монги и прочие кролики. запустить все воркеры и кроны.
Не совсем так. Во-первых, в ряде случаев можно банально упрощать и выкидывать (например, если приложение умеет работать на кластере, то это не означает, что надо локально кластер поднимать). А во-вторых, я не говорю, что все компоненты должны быть локальными — если мы зависим от чего-то тяжелого, то его придется шарить (и получать все побочные негативные эффекты этого шаринга).
вероятность того, что это событие произойдет одновременно — крайне мала.
Я вот это вижу несколько раз в день.
Вполне можно сделать так, чтобы сервер ставил в очередь сортируя по приоритету тасок в баг трекере и на почту слал линку на бинарник по завершению.
… вот только ждать придется дольше, чем если бы я собирал локально. И чем больше у вас программистов, тем сильнее это будет видно.
Впрочем, это, опять, вопрос баланса. Где-то выгоднее собирать централизованно, где-то выгоднее собирать локально.
Если локально у вас не все, а только то что обязательно
"Обязательно" в моем понимании только исходники. А дальше — от сложности проекта и скорости цикла, которую я хочу иметь.
бывают проекты, которые на типичном ноуте для разработки собираться будут часами
Вы все увеличиваете и увеличиваете время...
так тогда вы теряете тот единственный плюс о котором говорилось выше.
Не единственный. Еще как минимум банальная скорость навигации.
Если у вас только исходники, но чтобы посмотреть на работу программы нужно обязательно подключиться к сети/ докачать, доустановить etc, то какой профит таскать на своем ноуте исходники проекта?
(а) возможность в любой момент посмотреть код (чтобы принять решение/подумать/ответить на вопрос)
(б) скорость работы в IDE
А главное — по моим представлениям, проектов, которые действительно нельзя запустить локально, не так уж и много (в процентном представлении), так что я бы не стал на них полагаться при построении общей парадигмы. Их надо учитывать, но не надо брать за норму.
у вас все также локально есть репо с исходниками.
Тогда я не понимаю, что такое "ваш вариант", и чем он отличается от "моего".
А приверженцы данного подхода
Лично я приверженец того (простого, в общем-то) подхода, что чем больше можно поднять локально — тем лучше. Абсолютный минимум — локально лежащие исходники. Дальше — локальная сборка, локальный запуск, локальная БД, и вплоть до локальных сервисов.
Но всеже, иметь сервер «для деплоя» и софт который этот деплой исполняет мне кажется более еффективно.
А это не взаимоисключающие вещи. Можно иметь локальное окружение и сервер для деплоя (первое тестовое окружение и далее).
IDE на одном ПК, сам проект на другом ПК, монтирую директорию с проектом как диск по ssh, чтение и запись без задержки… работать можно из любого места, демонстрировать проект тоже можно где угодно…
в общем то плюсов достаточно…
Свой для каждого разработчика?
Это как код на С++ собирать разными компиляторами: те баги что не видит msvc, видит gcc и наоборот.
А что не так?
и тут у виндовозов случается пичалька.
На практике чаще надо ехать, а не чтобы шашечки. Поэтому какие-то фичи в проекте могут быть зависимыми от среды — это раз, какие-то баги могут просто не отлавливаться на другой среде (например, опечатки с регистром в названиях файлов под виндой).
И дальше-больше. Если в проекте есть какие-то интеграции и зависимости с различными внешними службами и сервисами, то гораздо проще и правильнее поддерживать доступ к ним с одного сервера разработки, чем открывать для бесконечного количества рабочих машин по всему миру. Там и другие нюансы могут быть, например большой объем данных, передаваемый к/от внешней службы, или нужна скорость.
Если в проекте есть какие-то интеграции и зависимости с различными внешними службами и сервисами, то гораздо проще и правильнее поддерживать доступ к ним с одного сервера разработки, чем открывать для бесконечного количества рабочих машин по всему миру.
Вы же в разработке наверное используете не боевые службы и сервисы, а тестовые? Будем честными, в половине случаев никаких проблем с доступом нет вообще (если это, скажем, публичный SaaS), во оставшейся четверти — это внутренний сервис компании, и при правильно организованной сети это тоже не проблема, в оставшейся восьмой части можно написать прокси (мы, кстати, так и сделали один раз, заодно и отладку себе радикально упростили), и только в оставшейся восьмой части надо хоть как-то об этом думать.
Кстати, одно из величайших открытий для меня было, что можно поставить git или svn непосредственно на production сервере.
Зачем?
Ведь больше не надо мучиться с синхронизацией файлов по ftp\sftp, достаточно ввести svn up или git pull origin master!
И для кого только системы автоматизированного развертывания пишут...
Работаю и не обламываюсь
А кто-то без версионника работает и не обламывается.
А кто-то прямо на продуктиве правит и не обламывается.
а настраивать CD на маленьких проектах как мне кажется это лишний геморрой
Ну да, писать собственный deploy.sh — конечно, меньший геморрой, чем взять готовое решение с тремя настроечными полями.
Но вообще, конечно, идея "давайте сделаем git pull" выглядит хорошей… пока вы выполняете несколько условий:
- содержимое версионника не требует обработки перед выкладкой (например, компиляции)
- все нужное для выкладки лежит в версионнике (бинарные зависимости, например, тоже)
- вы обновляете только одну точку развертывания (например, вам не надо обновлять БД вместе с сайтом)
- вам не нужно управлять конфигурацией продуктива
(и даже в этом случае могут быть проблемы класса "а как обеспечить бесперебойность работы во время обновления" и "как сделать так, чтобы на продуктив не утекло ничего опасного с точки зрения безопасности")
Но если вам надо забрать зависимости, скомпилировать бинарник, выложить его на продуктив, сконфигурить там очередь, мигрировать БД — и все это проделать на ферме, — то поддержка deploy.sh становится непозволительно дорогой.
PS а вы для каждого ландшафта свой deploy.sh пишете? а храните вы их где?
языки в основном php, python, так что компиляция не нужна
в плане БД есть миграции, которые можно тоже запустить в deploy.sh
зависимости тянуться с помощью composer install для php, в git лежит composer.lock, так что версии зафиксированы и если ничего не изменилось то и ничего не устанавливается
как говорил, фермы серверов нет, для обновления и очистки кэша через скрипт обновляется fpm
Ну а на рабочих сложных проектах конечно CD есть
Сам по себе наверное ничем. Но сейчас есть Vagrant и Docker. С нативной поддержкой в IDE. Так что «король» давно умер, и после уже сменилось не одно поколение королей.
Мне очень нравятся такие обобщения:
… правда жизни такова, что большинство разработчиков пользуются Windows в качестве основной OC на компьютере.
Однако время летит, появляются новые технологии, новые инструменты — и Вы, разработчик, должны идти в ногу со временем.
Но samba на сервер разработки? Откройте для себя realsync того-же Дмитрия Котерова.
Вот вам пример поднятия «веб-сервера» в 3 команды: scotch box, кроме того для более «требовательных» есть puphpet и куча других готовых решений.
Допустим вам нужна база данных postgresql. Вы просто берете готовый docker образ из его хаба, и юзаете туже самую базу данных для разработки локально и на продакшене. И окружение у этой базы будет точно такое же, то самое, что заложено в образ самого postgresql docker образа.
Грубо говоря вы строите контейнеры локально, и разворачиваете их же на продакшене с минимальным оверхедом (по сравнению с виртуалками).
Vagrant позволяет одному, допустим старшему разработчику написать Vagrantfile, а все остальные разработчики стянут его, и у всех будет одинаковая среда для разработки независимо на какой хостовой ОС они сидят. При желании можно даже собрать образ максимально приближенный к продакшену.
Что docker что vagrant позволяют вам писать код в среде приближенной к продакшену. Насколько приближенной вы можете решить сами, но как минимум и там и там linux например.
if [[ $D == *"bitrix"* ]]
теперь все ясно )
по поводу flush_vhosts.sh — ересь, если мне понадобится проксировать веб-сокет на определенный порт в одном из виртуальных хостов, то после добавления еще одного мне все перетрет и придется делать заново, т.к. скрипт «Очищает конфигурацию виртуальных хостов.». Не лучше ли сделать чтоб хосты добавлялись, а не перетирались старые?
Перезаписываю, т.к. у нас не требуется каких-то особых настроек, веб-сокеты в проектах не используются. Какие-то мелкие настройки внести через .htaccess. Зато не остается мусора, если папку с проектом убрали или переименовали.
Мой опыт настройки окружения для Web-разработки