Опрос. Как вы делаете деплой на production сервер(а)?

    Коллеги расскажите, пожалуйста. как вы делаете деплой на production сервер(сервера) веб-проектов.
    Если у вас используется 3 или 4 вариант, то как вы переключаете document_root — создаете симлинк на новый релиз или переписываете (скриптом) конфиг nginx?
    Если переключать симлинк не бывает проблем с APC или XCache?
    Если не хватает какого то варианта пишите в комментарии.

    UPD: Спасибо всем за комментарии, пятничный пост получился очень продуктивным и полезным думаю для многих.
    UPD2: Небольшой обзор комментариев:
    подробные разборы деплоя habrahabr.ru/post/211733/#comment_7286111 habrahabr.ru/post/211733/#comment_7287769
    утилиты для создания deb пакетов habrahabr.ru/post/211733/#comment_7286187
    наиболее популярное готовое ПО capistrano, fabric, teamcity

    Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

    Как вы делаете деплой на production сервер(а)?

    • 37.2%Заливаем вручную по (S)FTP1130
    • 30.9%В document_root лежит рабочая копия SVN (GIT) хранилища940
    • 14.9%Bash скрипт делает экспорт (полный или частичный) из СКВ и отправляет его в production453
    • 5.1%Разливаем через deb пакеты156
    • 11.7%Другой вариант, напишу в комментариях357
    Поделиться публикацией
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 149

      +17
      Почему нет варианта «рабочая копия SVN (GIT) хранилища, которая расположена ВЫШЕ document_root».
      Зачем держать корень репозитория в document_root если можно поднять его выше и обезопасить себя?
        0
        видел такой вариант: держат в руте svn копию, когда надо сделать релиз делают svn up. А если делать хранилище ВЫШЕ document_root, то дальше какой алгоритм? svn up потом экспорт в папку с новым релизом?
          +2
          А что вы подразумеваете под document_root?
          То где лежит весь проект, или то что видно из броузера?
            –1
            для многих php фреймворков по-умолчанию это одно и тоже ), в общем случае, конечно это папка где лежит весь проект.
              +7
              А потом выясняется, что репозиторий доступен всем через веб)
          0
          Наверное я вас неправильно понял. Я имел в виду случай, когда мы имеем доступ ко всему дереву каталогов, и работаем через ssh например на VPS.
          Тогда создаем каталог в который клонируем наш репозиторий. А в нем лежит каталог www на который и указывает виртуальный хост как на document_root.

          С обычным хостингом это будет несколько сложнее.
            0
            Для меня обычная методика на мелких сайтах — в /home/user лежит рабочая копия репозитория. /home/user/public — это document_root веб-сервера. Соотв. при коммите в интеграционный репозиторий срабатывает хук, который идет по ssh на продакшн сервер и делает git pull origin release.
            Соотв. программисту достаточно запушить в ветку release на git-сервере.
              0
              Да там всё просто — в директории, отдаваемой веб-сервером, только всякая статика. Весь код недоступен веб-серверу, так как лежит в другом поддереве репозитория. Однако FastCGI-серверу, к которому обращается веб-сервер, доступно всё.
                0
                такую схему по-умолчанию предлагает Zend Framework, я правильно понял?
                  0
                  Не знаю. К счастью, с PHP уже лет 8 не работаю, пересел на django, а там такая схема деплоя единственно естественная (за исключением apache, который я тоже не использую). Впрочем, с некоторой версии там наружу отдаётся две директории со статикой (они отделили user-generated статику от той, что помещается в репозиторий), но это общую схему не меняет.

                  Я вообще считаю, что плоха любая технология, которая провоцирует код класть в директорию, которую отдаёт веб-сервер. В смысле усложнения выстреливания себе в ногу мне как раз нравится django, там все опасные вещи происходят явно — явно отключается экранирование при подстановке переменной в шаблон, явно отключается экранирование при подстановке значений в SQL, явно отключается защита от CSRF-атак в формах, и так далее.
                    0
                    Я вообще считаю, что плоха любая технология, которая провоцирует код класть в директорию, которую отдаёт веб-сервер.

                    В традиционном (mod_php или php-fpm) использовании PHP сейчас рекомендуется (и провоцируется авторами многих продуктов, в частности тогже Зенда) класть в док-рут веб-сервера только один или несколько файлов в несколько строк, которые уже вызывают остальной код, веб-серверу недоступный.
                    мне как раз нравится django, там все опасные вещи происходят явно — явно отключается экранирование при подстановке переменной в шаблон, явно отключается экранирование при подстановке значений в SQL, явно отключается защита от CSRF-атак в формах, и так далее.

                    Это справедливо и для многих php-фреймворков (при условии использования не пхп-шаблонов).
                      0
                      К слову, шаблонизатор в симфани 1 был на PHP, однако там было автоматическое экранирование по умолчанию
                        0
                        Вроде только для объектов и массивов, передаваемых из контроллера.
              0
              Можно делать редирект запросов во дочернюю папку репозитория, где находится точка входа в приложение. Таким образом .svn/.git папки не доступны извне
              +5
              dokku и деплой через git
                +39
                capistrano
                  0
                  аналогично)
                    +3
                    capistrano, capifony, magentify и т.д
                    +17
                    fabric
                      +2
                      fabric + jenkins
                      +9
                      А почему нет варианта «я разрабатываю сразу на продакшене?»
                        +31
                        По той же причине, по которой нет варианта «Я самоубийца»
                          +22
                          А я считаю надо добавить такой пункт для корректности статистики.
                          Это печально, но я такие варианты встречал в жизни многократно.
                        +34
                        Странно, что нет самого очевидного варианта: Использую системы CI (teamcity, jenkins, bamboo и т.п.)
                          0
                          Они сами по себе этим не занимаются, почти всегда есть дополнительная приблуда (н-р copy плагины к jenkins) или просто дергаются скрипты из build шагов.
                          Хотя и нужно отдельно заметить про app сервера, которые поддерживают деплой как задачу.
                            –1
                            думал про них, но они сами по себе только предоставляют GUI, а так сказать транспорт для разливки, обычно более низкоуровневый или тот же bash скрипт или deb
                              0
                              +1
                              Заливать по SFTP не обязательно _вручную_ — это делает CI.
                              • НЛО прилетело и опубликовало эту надпись здесь
                                +1
                                opensuse build server + deb хранилище + chef
                                  0
                                  А у нас исторический тандем VСS+rsync
                                    +7
                                    Где вариант «заливаем вручную через RDP»? Какой-то одноплатформенный опрос получился…
                                      +3
                                      Да-да, или где же DAV?
                                      Как бы кому ни хотелось, но доля веб-проектов под IIS'ами далеко не нулевая…
                                      +5
                                      WebDeploy
                                        +5
                                        capistrano с обновлением версии из гита + eye

                                        деплой происходит одной командой cap production deploy

                                        Хоть оно и на руби, но в целом является аналогом очень продвинутого баш-скрипта, мы используем во всех проектах вне зависимости от языка
                                          0
                                          Использовал capistrano, как для рельс, так и для java-проектов (для шаблонов фронтовой части, бэк деплоился либо через веб-интерфейс аппсервера, либо через scp/cp/mv в специальную директорию и деплоить его тем же скриптом не имело смысла).
                                            0
                                            > Хоть оно и на руби

                                            Звучит, будто это что-то плохое.
                                              +1
                                              Эта фраза не для меня, а для тех, кто думает, будто руби — что-то плохое :)
                                                0
                                                В сочетании с «во всех проектах вне зависимости от языка» звучит как «хоть и почти во все проекты вносим ещё одну зависимость», причём не только «физическую» (должно быть настроено окружение), но и «ментальную» (нужно хоть поверхностно знать ещё один ЯП с довольно оригинальным (читай — не Си-образным) синтаксисом). Обычно это минус.
                                              0
                                              Пока проект небольшой заливаем вручную.
                                              Но уже сейчас задумываемся об автоматической сборке и выгрузке на продакшен. Опять же сейчас все на уровне самопальных «умных» python-скриптов
                                                +1
                                                Посмотрите на fabric, если у вас python-среда.
                                                  0
                                                  Не, у нас не python. На python'e пишем скрипты сборки. У нас Java7 почти полностью и клиент на JS. И сейчас продукт собирается около 3х минут. Поэтому перед деплоем необходимо еще проверить корректность сборки. Здесь и находится камень преткновения
                                                    +1
                                                    За корректность сборки можно грузить сервер CI. И по результату его работы делать необходимые действия для деплоя на test/stage/production/etc.

                                                    Fabric (capistrano или ещё какой-нибудь легковесный deployment framework) даст в таком случае небольшой фреймворк для удаленного выполнения, который несколько упростит написание этих самых самопальных python-скриптов. Принципиальных отличий от своих скриптов нет, просто нужно меньше писать boilerplate кода и можно подняться на более высокий уровень абстракции (уровень заданий, например, вместо отдельных команд).
                                                +4
                                                CI система выкачивает сорцы с репозитария на целевой продакшен сервер, выполняет миграции БД, выполняет деплой и миграционные скрипты для проекта как то: переделывает симлинки с директорий с данными, если нужно с некоторыми кешами, чистит кеш проекта, (возможно и apc | memcache), переключает симлинк document root директории на новую папку, прогоняет последний тест, что все завелось, если не завелось — откатывает симлинки, миграции и т. д.

                                                Примерно так, с порядком может быть напутал, потому что писал по памяти, а реализацию писали больше 1.5 лет назад
                                                  0
                                                  Изначально так же планировали. Но появился страх (проблема?), что на продакшене собирать новую версию — дорогое удовольствие. Может в силу отсутствия такого опыта я что-то упускаю из вида? Были ли у вас проблемы?
                                                    0
                                                    фактически проблемы периодически появляется, но с конкретными проектами… зависит и от задействованных фреймворков и от стека технологий. Но это не «проблемы», это сценарий деплоя проекта требует доработки. Я описал общее поведение системы деплоя, в него практически все вписывается… Кстати забыл: CI кроме выгрузки сорцов проекта выкачивает еще и настроеки проекта:
                                                    конфиги nginx — шаблон кастомных реврайтов настроек
                                                    настройки окружения — xml файл с настройками (использовать ssl или нет, делать ли редирект по умолчанию с домена на домен с www, на какие директории делать и куда делать симлинки, на какие директории нужно заново выставить какие то права), какую версию и какой пул php использовать, какие дополнительные домены парковать к этому сайту
                                                    конфиги cron
                                                    анализатор конфигов проекта — скрипты редактирующие/генерирующие конфиги проекта, в зависимости от окружения…
                                                    И генерирует на основе них файлы конфигурации для продакшен окружения удаляя старые…

                                                    Конечно же, иногда приходится дорабатывать под проект, конкретные стадии деплоя индивидуально
                                                    Некоторые проекты могут просить жесткий ребут php-fpm, можно сделать это мягко и использовать для проекта 2 пула php-fpm, перезагружая их по очереди, или может быть рестарт мемкешд, где то нужно прежде работать с composer, но это уже лирика…
                                                    Кстати, конкретно у нас есть еще система преддеплоя/тестирования, которая фактически делает тоже самое, но с дебаг режимом, логированием тестов и работает автоматически при каждом коммите в транк разворачивая все это на тестовом сервере, поэтому если что-то явно сломается или скрипты не отработают — будет видно сразу…
                                                      0
                                                      P.s. Чтобы было понятней приведу немного цифр. Специально глянул:
                                                      Cейчас в системе деплоя около 30 проектов, итого около 50 планов деплоя (на 1 проект, может быть несколько планов деплоя: в проектах может быть несколько сервисов: веб, апи, поддомены с бета версиями или лендингами/промо сервисами), которые постоянно выкатываются на продакшен. На раных проектах из языков/фреймворках используются: yii, symfony2, самописный фреймворк, node js, 1 веб сервис полностью на java. Различные хранилища и модули.
                                                        0
                                                        Я вас понял, спасибо за ликбез. Сразу встречный вопрос следующего характера. Есть пользователи, сидящие на сервисе. И вы начинаете пересобирать проект. Видно два минуса: задержка отклика сервера (поскольку сервер может быть нагружен) и проблема с обновлением так, чтобы не было заметно пользователю, что что-то пошло не так. Или вы пока не думаете об этом?
                                                          +2
                                                          на 3 проектах суммарная суточная аудитория около 1 100 000 уников, в момент деплоя в онлайне обычно 2-4 тыс. человек… на производительность сервера svn export и прочие дисковые операции обычно не влияют… проблемы могут быть если существуют тяжелые миграции (к примеру БД), которые могут вывести из строя работу сервера на длительное время… В этом случает делаем аккуратно, к примеру, если это тяжелое обновление БД, то накатывается вручную или через дополнительные таблицы или с перелючением на другой сервер БД, после догоняем сделанные изменения… или новое обновление может работать как со старой стуктурой, так и с новой, со временем обновляя данные… в этих случаях все индивидуально…
                                                          само переключением проходит для пользователя практически незаметно, потому что для проекта написаны скрипты так, что сервисы без необходимости не рестартятся, временные файлы необходимые для бесшовного переключения, остаются, сессии и прочее хранится в БД, а переключение симлинки проходит очень быстро…
                                                            0
                                                            Спасибо за ответы такие подробные. В общем случае чудес не бывает. :-)
                                                            Спасибо за помощь такую.
                                                              0
                                                              Не за что. Если будут более конкретные вопросы, пишите в личку, расскажу более подробно как это работает конкретно у нас. Ну или расскажите, как хотите сделать вы, вдруг мы уже на такие грабли наступали :)
                                                    +1
                                                    А кто использует deb пакеты, какими утилитами собираете?
                                                      +1
                                                      Если говорить про sbt, то sbt-native-packager
                                                        +2
                                                        dpkg-buildpackage
                                                          0
                                                          Пришлось свою написать, прям вот этими руками: github.com/punund/nodeb
                                                            0
                                                            спасибо за ответы
                                                              0
                                                              github.com/jordansissel/fpm/ весьма простой для простых вещей
                                                                +1
                                                                dch; debuild && debclean && debrelease && debcommit
                                                                +6
                                                                Я бы просто для смеха добавил вариант «А мы не деплоим, мы прямо на продакшене и пишем!»
                                                                  +7
                                                                  Было бы смешно, если б не было так грустно…
                                                                    +11
                                                                    Поди, не добавили из опасения, что вариант перегонит FTP)
                                                                    +2
                                                                    А я вот скрипты по автоматизации своей квартиры пишу прямо на продакшен сервере, который у меня в чулане стоит. Без версионности, тестирования и деплоя. И в данном конкретном случае, считаю это нормальным.

                                                                    В некоторых ситуациях работать на продакшене это приемлемо, хотя в большинстве случаев — это дикость.
                                                                      0
                                                                      Вы слишком серьёзно подошли к вопросу.
                                                                        +3
                                                                        версионность не помешает сколь угодно малому проекту. всего лишь пара команд, чтобы подключить тот же git прямо локально, но моментально появившиеся дополнительные плюшки очень могут сэкономить времени. особенно на стадиях «блин, зря я так переделал, лучше вернуть как было».
                                                                          +1
                                                                          для маленьких проектов вполне хватает поддержки версионности средствами самой IDE — зачем ещё что-то городить? та же IDEA хранит 1 месяц изменений — мне кажется это более чем достаточно.
                                                                      0
                                                                      Capifony для Symfony 2 проектов, вручную (пока) для всякой мелочи.
                                                                        +1
                                                                        mina (легковесная single-server замена capistrano), на больших проектах — capistrano, но без simlink'ов, вместо этого git и его теги + правильно настроеный gitignore.
                                                                          0
                                                                          У git+тегов вместо симлинков проблема в том, что нужно быть абсолютно на 100% уверенным, что на сервере ничего не меняют руками.
                                                                          Иначе может случиться такая ситуация, что в горячке накатили какой-то хотфикс из пары строк прямо по месту, а после очередного деплоя он необратимо исчезнет (если делать reset), или наоборот, сломает работающий код (если reset не делать).
                                                                            +1
                                                                            Если случилась такая ситуация, что хотфикс надо делать на боевом сервере, то:
                                                                            1) все последующие «регулярные» деплои блокируются до разбора полетов
                                                                            2) хотфикс, если он заработал на боевом, в обязательном порядке (а зачастую сразу паралельно с редактированием «там») заносится в git и в самом высоком приоритете тестируется со всех сторон, заливается в мастер и выполняется деплой уже с хотфиксом в гите. После чего проверяем что всё применилось нормально. (Если нет — повторяем итерацию, но такое за 5 лет было только 1 или два раза)
                                                                            3) вся команда собирается на разбор полетов, с выяснением (а) почему такой факап произошел, (б) почему его пропустили QA, (в) могли ли они вообще его заметить, и (г) что сделать чтобы такое не повторилось.
                                                                            Как-то так. :)
                                                                          +1
                                                                            +1
                                                                            Не хватает возможности множественного выбора, на разных проектах разные методы.
                                                                              +1
                                                                              Пробовали разные варианты, самым удобным оказалось деплоить продакшн ветку гитом и запускать скрипт миграции бд при необходимости.
                                                                                0
                                                                                Делаю пуш на нужный сервак, он все подхватывает и сам разворачивает среду и настраивает нжиникс
                                                                                  0
                                                                                  Мы используем маленький проект, который написал мой коллега: github.com/korchasa/zeus
                                                                                    0
                                                                                    Пакеты, пакеты и только пакеты. К сожалению, rpm. Время обновления тачки и ее пуска больше чем хотелось бы, поэтому во время обновления машина не видна пользователям.
                                                                                      +1
                                                                                      Используем Gitlab + gitlab-ci (runner). Удобно. Runner проганяет тесты, делает билд, и если все ок — деплой. Срабатывает по тригеру пуша в мастер ветку GIT
                                                                                        0
                                                                                        Меня удивляет то, что 37% проголосовавших живет в каменном веке и выкладывает все руками! Больше трети!
                                                                                          +6
                                                                                          Я думаю так голосует те, у кого:
                                                                                          — На один проект один девелопер.
                                                                                          — Проекты простые, что то типа простеньких сайтов.
                                                                                          — Нет версионности (Сляпал сайт за неделю, сдал работу и забыл.)
                                                                                          — Нет автоматизированного тестирования (а зачем оно для сайта визитки, где тестором выступает сам заказчик?)
                                                                                          — Разрабатывают под виндой (иначе бы, хотя бы пользовались bash, rsync и тп).

                                                                                          Да 80% веб-студий так работают, как я заметил.
                                                                                            +1
                                                                                            «mvn package deploy -P production» из IDE по сути тоже является «выкладыванием руками», но в этом профиле «production» ещё столько скриптов запуститься, что мама не горюй
                                                                                              0
                                                                                              Да, так и есть, наверное.
                                                                                              У меня имеется проект приличный по размеру, но с одним разработчиком (мной). Git используется для синхронизации кода между несколькими рабочими компьютерами, а выкладывается все при коммите кода в рабочую ветку обычным PHPStorm.
                                                                                                0
                                                                                                Или просто нет времени/желания автоматизировать деплой.
                                                                                                  0
                                                                                                  — Разрабатывают под виндой (иначе бы, хотя бы пользовались bash, rsync и тп).


                                                                                                  TFS уже давно умеет в:
                                                                                                  image
                                                                                                  0
                                                                                                  Сильно зависит от платформы. В случае деплоя war (java) часто достаточно его скопировать в специальную директорию. Тогда деплой через ftp/sftp/scp/руками — суть одно и то же.
                                                                                                  0
                                                                                                  Проект синхронизируется между разработчиками через git или svn. В проекте имеется простенький bash скрипт, который через rsync синхронизирует рабочую версию на компе разработчика с продакшен сервером. Этот же скрипт может аптейтить базу данных на продакшен сервере, если есть необходимость. Например для какого-нибудь простого проекта, где при деплое можно просто поставить свежую версию поверх старой, это будет как то так.
                                                                                                  rsync -rlptDvL \
                                                                                                      /var/www/project_1 \
                                                                                                      developer@production-server.com:/var/www/project_1
                                                                                                  
                                                                                                  mysqldump --user=*** --password=*** --host=localhost --add-drop-table DATABASE |  \
                                                                                                      ssh developer@production-server.com  \
                                                                                                          mysql --user=*** --password=*** --host=localhost DATABASE
                                                                                                  
                                                                                                  Если проект посложнее, то обычно просто скопировать поверх — этого недостаточно. Копировать надо избирательно, чтобы не потереть рабочие данные на продакшене. Тогда скрипт будет чуть посложнее, и обмен скорее всего там будет в обе стороны.
                                                                                                    +6
                                                                                                    Разливаем через deb пакеты
                                                                                                    Кроме DEB других пакетов нет что ли? Мы через RPM заливаем.
                                                                                                      0
                                                                                                      Заливаем через Tomcat Manager в билде (Java приложение).
                                                                                                        +1
                                                                                                        В PHP проектах деплой просто выкладывается в новую папку, и инит проекта перегенерирует локальный nginx конфиг — это заведомо избавляет от проблем с кешем, позволяет действительно быстро откатываться и даёт действительно graceful reload сугубо командой nginx reload.
                                                                                                          0
                                                                                                          А что это за инит проекта? Shell магия?
                                                                                                            0
                                                                                                            Зависит от проекта. В целом, это инициализация карты классов, проектных конфигов, nginx конфигов, npm install + bower install, сборка статики, генерация спрайтов, кодогенерация итд.
                                                                                                          0
                                                                                                          Используем Beanstalk.
                                                                                                            +1
                                                                                                            GIT + хуки
                                                                                                              0
                                                                                                              Поддержу. git pull. Но остаётся открытым вопрос миграций в БД. Достаточно делать их обратно совместимыми и тогда нет проблем. Для отката хватает банально checkout'а.
                                                                                                              +2
                                                                                                              1. Capistrano. Копирование и переключение симлинка.

                                                                                                              2. Вызов rsync из puppet, который, в свою очередь, вызывается из jenkins.

                                                                                                              PS: Не нравятся оба способа. В первом случае, долгое копирование на большое количество серверов плюс указанные глюки кешера. Во втором, в принципе, тоже. Файлы попадают на сервера не одновременно. Из-за чего приходится выводить их в maintenance.

                                                                                                              PPS: Самый передовой способ деплоя — это «Чик-чик и в продакшен». Не важно чем.
                                                                                                                0
                                                                                                                Может я чего-то не понял в вариантах, но у нас TeamCity собирает архив из релизной версии и потом кладёт всё на FTP, откуда скрипты уже всё забирают и распаковывают на живой.
                                                                                                                  0
                                                                                                                  а саму работу делают (архив, распаковка, выгрузка на ftp) делают собственные sh скрипты? Или для тимсити есть готовые плагины?
                                                                                                                  +1
                                                                                                                  Использую Ansible.
                                                                                                                    0
                                                                                                                    У нас просто запускается билд в TFS, который берет нужную версию из VCS и заливает на соответствующий сайт с помощью MSDeploy.
                                                                                                                      0
                                                                                                                      Локально развернута на VMWare-инфраструктуре зеркальная копия production'ов (везде ubuntu 64 server 12.04). Включая OS, RAM, окружение, и даже хосты. Еще одна зеркальная копия там-же — dev сервера.

                                                                                                                      Переключение на dev рабочих местах через hosts.

                                                                                                                      После ручного пуша на локаль и всех тестов — rsync на продакшн + нужные кастомные sh скрипты на каждый деплой.

                                                                                                                      Всё остальное на практике либо не оправдывает затрат на настройку, либо избыточно для нашей небольшой команды и вполне себе больших проектов с кучей разных связей и тулз.

                                                                                                                      Исторически сложилась система проектов, которая плохо накладывается на паттерны работы с GIt и автосборщиками.

                                                                                                                      Никаких серьезных проблем при этом не испытываем. Разве что не так красиво это выглядит со стороны, как хотелось бы.
                                                                                                                        0
                                                                                                                        А, ну разве что кроме проблемы, что иногда забываешь, на какой хост ты смотришь, на локальный или на продакшн )
                                                                                                                        0
                                                                                                                        Разработка под SharePoint является веб-разработкой?
                                                                                                                        Ставим предназначенный для разворачивания WSP-пакет. Это такой контейнер, в котором содержится всё необходимое для развёртывания решения на сервере.
                                                                                                                          0
                                                                                                                          Последнее время использую git, каждый релиз новый тег + для некоторых проектов для упрощения выгрузки написан скриптик update.sh, который еще делает всякие дополнительные вещи (сброс кэша, метаобновления если есть и т.п.)
                                                                                                                          На одном из проектов еще сделана автоматическая выгрузка, в момент когда что-то пушится в ветку мастер.
                                                                                                                            +1
                                                                                                                            Maven с профилями + Tomcat
                                                                                                                              0
                                                                                                                              С гитом всё очень просто. Создаем страницу, которя при POST с определённого ip делает лишь —
                                                                                                                              git fetch --all
                                                                                                                              git reset --hard origin/master
                                                                                                                              npm update
                                                                                                                              

                                                                                                                              и на случай перезапускаем инстансы (node.js) (file touch при разработке у нас вотчеры на весь проект, а при деплое только конфиги и index.js)
                                                                                                                              fs.utimesSync('index.js', new Date(), new Date());
                                                                                                                              
                                                                                                                                0
                                                                                                                                Check-In на TFS сервер, оттуда триггер на деплой на Staging Cloud Service в Azure, если все ок, свап VIP адресов со стейджинга на продакшен.
                                                                                                                                  +2
                                                                                                                                  банк имеет свою систему которая копирует файлы с серверов на которых тестируют на продакшн
                                                                                                                                  TEST — UAT — PROD
                                                                                                                                  разработчики могут выложить версию только на TEST
                                                                                                                                  PROD под контролем администраторов
                                                                                                                                  в случае исправления ошибки весь цикл повторяется
                                                                                                                                    0
                                                                                                                                    заливаю вручную с помощью rsync
                                                                                                                                      +1
                                                                                                                                      chef
                                                                                                                                        0
                                                                                                                                        Jenkins
                                                                                                                                          0
                                                                                                                                          capistrano, salt
                                                                                                                                            0
                                                                                                                                            bash-скрипт в кроне опрашивает Teamcity на предмет наличия новых версий приложения и складывает их в отдельную папочку. Само обновление выполняется вручную из папки, но с предварительным сравнением версий и diff-ами, чтобы убедиться, что заменяются нужные файлы. Деплоим java-приложения
                                                                                                                                              0
                                                                                                                                              На текущем проекте код лежит в репе (SVN), подтягивается на продакшен в отдельную папку (хомяк юзера deploy) через svn up/merge, потом сихронизируется локально через rsync, а потом вручную разбираются проблемы с миграциями (фреймворк не очень хорошо с ними работает если миграция создана раньше последней накатанной, но ещё не накатана). Можно было бы больше автоматизировать, но нет никакого желания — проект, как говорится, «на выброс» :(
                                                                                                                                                +1
                                                                                                                                                Git стоит на CI-сервере (с Gitolite), через hook мониторится определённая ветка, обновление которой инициирует git pull на Production. Процесс инициации может отличаться, по умолчанию CI сам заходит через ssh и делает pull. Сервер всегда находится в точном соответствии с конкретной веткой git'а на CI.

                                                                                                                                                Корень git'а при этом находится выше Document root.
                                                                                                                                                Конфигурации серверов — отдельный репозиторий, находится в отдельном месте и управляется отдельным пользователем, обновляется таким же способом.
                                                                                                                                                Исходный код самих серверов (они у нас тоже собираются из сорцов) — третий репозиторий…
                                                                                                                                                Конфигурация CI, скрипты инициации и разделение прав пользователей — четвёртый…
                                                                                                                                                  0
                                                                                                                                                  До недавнего времени делали все по (S)FTP, но как-то это все утомило, сейчас с помощью GIT сервер синхронизируется с master веткой репозитория, а для автоматизации этого всего, как обновления так и для инстала на сервер используем deployer.in
                                                                                                                                                    +2
                                                                                                                                                    1. С помощью кроновых PHP-скриптов авто-мержим задачи из таск-трекера* в ветку релиза (которая создается автоматически 2 раза в день)
                                                                                                                                                    2. В CI-системе** прогоняем юнит-тесты с помощью самописной «облачной» запускалки тестов на основе phpunit (запуск тестов осуществляется в 30-60 потоков на 4 серверах, и занимает от 50 секунд до 3 минут, в зависимости от загрузки)
                                                                                                                                                    3. Для этой ветки генерируем файлы с переводами (наш сайт мультиязычный) и заливаем статические файлы на наш CDN — тоже с помощью самописной системы
                                                                                                                                                    4. Из всего этого создаем т.н. «луп» — образ ФС размером 768 Мб, в которой находятся все файлы, включая автогенерированные переводы (всего около 100 000 мелких файлов)
                                                                                                                                                    5. Заливаем «луп» во все датацентры (в данный момент их 2,5 — один в Европе, другой в США, и один маленький ДЦ в Азии) с помощью самописной системы, которая умеет пересылать только разницу между этими «лупами»
                                                                                                                                                    6. Деплоим «луп» на staging — заливаем и монтируем «луп» в отдельную директорию и переключаем симлинк. При этом, к сожалению, возникают проблемы с кешом, причём во всех аккселераторах — APC, eAccelerator и opcache в PHP 5.5
                                                                                                                                                    7. Когда релиз стабилизирован, тот же самый «луп» (сжатый файл весит около 100 Мб) с помощью технологии UFTP заливается за 25 секунд на наши 1000 серверов и с помощью библиотеки libpssh на всех этих машинах происходит запуск соответствующих скриптов, которые монтируют «луп» и сбрасывают кеши

                                                                                                                                                    Процесс деплоя на staging занимает около 3-5 минут (с момента пуша в ветку до попадания кода на staging), при деплое на production — ещё около 2 минут с момента, когда изменения попали на staging.

                                                                                                                                                    * таск-трекер не имеет значения, мы им не слишком довольны, но он произведен компанией на букву A
                                                                                                                                                    ** CI-система работает относительно хорошо, но некоторые задачи нам пришлось перенести на самописную систему, поскольку она не справлялась. Система произведена компанией на букву J
                                                                                                                                                      0
                                                                                                                                                      Я правильно понимаю, что в п.4 вы руками делаете примерно то же, что делает Docker?
                                                                                                                                                        0
                                                                                                                                                        Docker же делает образы виртуальных машин? Мы делаем только образы ФС с нашим кодом, виртуализация у нас на production вообще не используется.
                                                                                                                                                          0
                                                                                                                                                          Докер делает контейнеры, это далеко не то же самое, что система виртуализации
                                                                                                                                                      0
                                                                                                                                                      Таски после теста мержатся в релизную ветку, а на сервере запускается shell-скрипт (или Teamcity со скриптом), который делает git pull, накатывает миграции, сбрасывает кэши, делает бэкап прошлой версии и т.д.
                                                                                                                                                        –2
                                                                                                                                                        Разливаем через deb пакеты
                                                                                                                                                        Поубивал бы…
                                                                                                                                                          –1
                                                                                                                                                          В чем проблема deb?
                                                                                                                                                            0
                                                                                                                                                            Проблема в том, что алгоритм выкладки читаем лишь админами, которые его прописывали. Изначально deb и т.п. *nix пакетные системы деплоя преднозначен для обновления серверного ПО, а не для delivery и тем более build веб проектов.

                                                                                                                                                            Есть множество инструментов изначально предназначенных для сборки и delivery веб-проектов. Будь то Ant, или Phing на нём построенные или хоть даже Maven. Не суть важно. Они предоставляют более прозрачный интерфейс для сборки и выкладки веб-проектов чем deb/rpm/wtf… обновляторы заточенные тупо на обновление серверного ПО.

                                                                                                                                                            Из более двух десятков известных мне веб-проектов лишь несколько использовали deb/rpm деплоеры для выкладки, и… что не удивительно, во всех этих проектах тех. диры были бывшими админами, и именно в этих в проектах происходили наибольшие проблемы с деплоями как с точки зрения стабильности выкладки, отката, так и с точки зрения простоты редактирования сценария выкладки.
                                                                                                                                                              0
                                                                                                                                                              Ну, выходит у нас был противоположный опыт, у меня как раз меньше всего проблем было с пакетами.
                                                                                                                                                                0
                                                                                                                                                                Мне кажется не стоит путать сборку и деплой. Все-таки это разные вещи. Сборка — скомпилить JS, CSS, LESS, скомпилить картинки в одну большую, bower install, npm install, etc. Деплой — положить все это дело правильно на сервер. ИМХО для первого ant, phing, maven — в зависимости от платформы, для второго deb лучше. Еще есть настройка окружения — puppet, chef, ansible, тоже не мешать с деплоем артефактов на сервер.

                                                                                                                                                                Так вот для деплоя артефактов, ИМХО, как я уже говорил, deb подходит идеально.
                                                                                                                                                                  0
                                                                                                                                                                  А почему вы считаете, что Ant/Phing/Maven и т.п. инструменты в плане delivery хуже систем обновления пакетами deb/rpm/..? Сценарии описываемые на XML в том же Ant Script прекрасно читаемы всеми программистами и более того могут быть более безопасно подправлены. И более того, при грамотном написании эти сценарии являются платформонезависимыми позволяя отлаживать и тестировать их на локальных машинах разработчиков.

                                                                                                                                                                  ИМХО deb подходит для обновления и конфигурации серверного ПО — всего того, что попаает в зону ответственности админов. А всё что касается архитектуры веб-проектов, тонкости функционирования различных компонентов — зона ответственности программистов, и только они должны принимать решения о сценарии сборки и выкладки.

                                                                                                                                                                  И что касается разделения использования Ant/Phing/Maven для сборки и dev/rpm для выкладки — зачем это разделять, если Ant/Phing/Maven прекрасно справляются и с первым, и с последним?
                                                                                                                                                                    0
                                                                                                                                                                    Не знаю, может быть мы о разных вещах говорим.

                                                                                                                                                                    Для меня deb это в первую очередь положить в правильные места все необходимые артефакты. Если юзать для этого просто архивы, а не deb, то нужно париться о многих вещах. Во-первых нельзя просто так распаковать новую версию поверх старой, потому что в новой могут удалиться какие-то файлы, их не должно быть после деплоя. Во-вторых нельзя просто так взять и удалить старую версию перед распаковыванием новой, потому что там могут быть какие-то генерируемые во время работы файлы. Приходится писать какие-то скрипты, которые будут удалять все кроме всяких uploaded_images папок. ИМХО это велосипед, потому что deb это идеально сам разруливает.

                                                                                                                                                                    Далее, кроме того чтобы положить правильные файлы в правильное место при деплое надо сделать еще кое-какие действия: обновить кеш, смигрировать БД, перезапустить воркеров, etc. Мне тоже не нравится делать это в preinstall/postinstall хуках. У нас, например, этим занимается ansible вместе с остальной частью провиженинга системы, такой как: положить правильный конфиг веб-сервера в правильное место, рестартануть веб-сервер только в случае если конфиг изменился и пр. ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.

                                                                                                                                                                    Мы у себя используем phing для того чтобы собрать deb-пакет со всеми артефактами и прогнать перед этим юниттесты
                                                                                                                                                                      0
                                                                                                                                                                      ИМХО ant/phing для этого не очень хорошо подходят, потому что все-таки читабельность его XML очень сомнительна, мне кажется. И что-то более или менее большое на нем сложновато поддерживать.

                                                                                                                                                                      Я видел сценарии build & delivery реализованные на Ant и на Maven в десятки тысяч строк(XML), разбитые на десятки под-файлов с несколькими десятками под-сценариев, с достаточно сложной, но легко читаемой логикой зависимостей между ними. И вот представить всю эту красоту описанной на deb + bash… извините, но лично мне не хватает фантазии.

                                                                                                                                                                      Понятно, что опытные админы могут легко читать bash скрипты любых размеров и сложности. Но, опять таки, как я уже писал выше, я за то, чтобы сценарии сборки и выкладки проектов писались программистами, а не админами. Как-то раз столкнулся с ситуацией, когда после увольнение админа команда ещё неделю с ума сходила, чтобы в его deb + bash скриптах разобраться. Хотя сценарий выкладки там был не такой уж сложный. С тех пор я эти решения на дух не переношу.

                                                                                                                                                                      А в плане хитрого delivery, всё о чём вы говорите вполне реализуемо на Ant/Maven, весь необходимый функционал для этого там есть. Был бы только мозг способный этим функционалом правильно воспользоваться.
                                                                                                                                                                        0
                                                                                                                                                                        Вы, наверное, не внимательно читали мой комментарий. Я призываю использовать deb для копирования файлов на сервер и распаковки правильных файлов в правильном месте, для правильной замены и удаления файлов старых версий. Согласен с вами, что деплой на bash скриптах это жесть.

                                                                                                                                                                        Посмотрите в сторону ansible для деплоя и провиженинга, может быть передумаете и выкинете phing после этого )
                                                                                                                                                                  0
                                                                                                                                                                  А веб-проекты — это не серверное ПО?
                                                                                                                                                                    +1
                                                                                                                                                                    Нет, веб-проекты — это не серверное ПО. Ничего не имею против того, чтобы админы использовали deb/rpm пакеты для обновления серверного ПО т.к. там не такие сложные сценарии, и т.к. программистам в принципе лучше не соваться в эти сценарии.

                                                                                                                                                                    Сценарий сборки и выкладки веб-проектов не так просты как сценарии обновления серверного ПО т.к. они во много зависят от архитектуры проекта(которую админ может не понимать до конца), от бизнес-логики некоторых компонентов(о которой админ может не знать) и т.д. и т.п. Ни один админ не будет знать логику функционирования веб-проекта лучше чем программист, который его реализовал. Поэтому, моё мнение, что сценарий сборки и выкладки должны описывать программисты, а не админы. Поэтому, я считаю, что сценарии сборки и выкладки должны описываться не на deb/rpm пакетах, а на легко читаемых и кроссплатформенных инструментах деплоя типа Ant/Phing/Maven и т.п.
                                                                                                                                                                +1
                                                                                                                                                                На серверах приложения раскладываются с помощью пакетов и это, на мой взгляд, наиболее правильный и наименее велосипедный способ.
                                                                                                                                                                Используя пакеты, прямые руки и светлую голову, у вас автоматом появляется контроль и удовлетворение внешних зависимостей, откат поломанных релизов, чистоту и порядок на рабочем месте и мягкие и шелковистые волосы.

                                                                                                                                                                P.S. конечно, не следует пакетировать конфиги. Конфиги должны храниться в VCS и управляться через SCM.
                                                                                                                                                              +1
                                                                                                                                                              puppet apply
                                                                                                                                                                0
                                                                                                                                                                fabric + jenkins
                                                                                                                                                                  0
                                                                                                                                                                  Amazon ESB + puppet + docker + serf + собственная обвязка на bash + php
                                                                                                                                                                    0
                                                                                                                                                                    buildbot
                                                                                                                                                                      0
                                                                                                                                                                      Не указаны следующие варианты :)

                                                                                                                                                                      image
                                                                                                                                                                        +1
                                                                                                                                                                        Всё делает bash-скрипт:
                                                                                                                                                                        — Переключает nginx на страницу «ведутся работы»
                                                                                                                                                                        — Делает свежий дамп базы и копирует куда нужно.
                                                                                                                                                                        — Скачивает рабочую версию из svn-репозитория.
                                                                                                                                                                        — Собственно обновляет приложение.
                                                                                                                                                                        — Запускает приложение и переключает nginx обратно.

                                                                                                                                                                        Для переключения nginx на страницу «ведутся работы», скрипт создает пустой файл в специальном каталоге, который проверяет nginx и в случае, если файл существует, nginx выдает страницу-заглушку.
                                                                                                                                                                          0
                                                                                                                                                                          Можно скачивать рабочую версию из репозитария и делать дамп до переключения на страницу «ведутся работы», тогда простой будет меньше.
                                                                                                                                                                            0
                                                                                                                                                                            Да, можно, но там разница была бы секунд в 10-15. В любом случае, сейчас уже это не актуально, так как переехали на Amazon и там пока используем AWS Beanstalk с балансером и обновлением серверов приложений по-очереди, без простоя.
                                                                                                                                                                        • НЛО прилетело и опубликовало эту надпись здесь
                                                                                                                                                                            0
                                                                                                                                                                            capistrano (Rails)
                                                                                                                                                                              0
                                                                                                                                                                              Используем FTP, но прямо сейчас выбираем более удобный вариант для выгрузки из SVN.
                                                                                                                                                                              В связи с чем вопрос к указавшим capistrano и тп — если использовать подход с симлинком, как быть с папками которые не входят в репозитории и которые не нужно трогать вообще?
                                                                                                                                                                              Пример:
                                                                                                                                                                              /public/
                                                                                                                                                                              ../app — 10 кб
                                                                                                                                                                              ../data — 100 Гб

                                                                                                                                                                              Если создается симлинк на папку /public — и потом обновляется только /app — то огромная папка /data не будет копироваться? К сожалению не очень силён в настройках unix — поэтому прошу сообщество подсказать. Направить на верный путь.

                                                                                                                                                                                +1
                                                                                                                                                                                Capistrano стандартно создает (при команде deploy:setup) директорию shared, где лежат данные, не изменяющиеся при деплое.

                                                                                                                                                                                app
                                                                                                                                                                                |`- current -> releases/20140101100000
                                                                                                                                                                                |`- releases
                                                                                                                                                                                | |`- 20130101100000
                                                                                                                                                                                |  `- 20140101100000
                                                                                                                                                                                `- shared
                                                                                                                                                                                


                                                                                                                                                                                Т. е. если data не изменяется при деплое, то можно переместить её в shared и настроить создание нужного симлинка в каждом релизе на неё.
                                                                                                                                                                                0
                                                                                                                                                                                1. Нажимаем на кнопку в Jenkins-е -> Делается git clone репозитория, нагоняется buildout (buildout т.к. проекта на python-е, в случае php для этих целей мы используем phing), билдится rpm-ка проекта и кладется в rpm-репозиторий
                                                                                                                                                                                2. Даем команду salt-у (cм. SaltStack), который раскатывает собранную rpm-ку по серверам, вносит на каждом из серверов необходимые изменения в файлы конфигураций, после чего выполняется миграция БД и делается синхронный рестарт веб-серверов
                                                                                                                                                                                  0
                                                                                                                                                                                  а чем автоматически собираете rpm?
                                                                                                                                                                                    0
                                                                                                                                                                                    RPM собирается по спекам при помощи rpmbuild-а
                                                                                                                                                                                  0
                                                                                                                                                                                  capistrano
                                                                                                                                                                                    0
                                                                                                                                                                                    habrahabr.ru/post/140103/ Деплою так.

                                                                                                                                                                                    А джангу деплою фабриком.

                                                                                                                                                                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                                                                                                                                                                    Самое читаемое