stage server что это
staging server
Смотреть что такое «staging server» в других словарях:
staging server — darbinis serveris statusas T sritis informatika apibrėžtis ↑Serveris, naudojamas naujai kuriamoms, į kitą kalbą verčiamoms arba kitaip pertvarkomoms ↑svetainėms laikyti. Kai darbas su svetaine baigiamas, svetainė patikrinama, ir kai pripažįstama … Enciklopedinis kompiuterijos žodynas
Staging site — Well planned Web site development involves development, staging and production servers. The staging site is used to assemble, test and review new versions of a website before it goes into production. The staging phase of the software lifecycle is … Wikipedia
Staging — Unter einer Stadienbestimmung (engl. staging) versteht man die Beurteilung von Tumoren, siehe Stadienbestimmung (Onkologie) die Klassifikation des Entwicklunggrades von Embryonen und Feten anhand äußerer Merkmale, siehe Stadienbestimmung… … Deutsch Wikipedia
staging — In a document retrieval from an optical jukebox, the process where the image is fetched from the server by the software, and stored on the user s local PC until it is used … IT glossary of terms, acronyms and abbreviations
Microsoft Identity Integration Server — (MIIS) ist eine Metaverzeichnisdienst Software von Microsoft. MIIS ist ein zentraler Dienst, der Identity Informationen aus mehreren Datenquellen zusammenführt, speichert und synchronisiert. Ziel von MIIS ist es, Identity Informationen zu… … Deutsch Wikipedia
document staging — In a document retrieval from an optical jukebox, the process where the image is fetched from the server by the software, and stored on the user s local PC until it is used … IT glossary of terms, acronyms and abbreviations
Stadienbestimmung — (englisch staging) ist: Stadienbestimmung (Onkologie), die Beurteilung von Tumoren Stadienbestimmung (Embryologie), die Klassifikation des Entwicklunggrades von Embryonen und Feten anhand äußerer Merkmale das Stufenkonzept bei Mehrstufenraketen… … Deutsch Wikipedia
East Mecklenburg High School — Infobox high school image caption = name= East Mecklenburg High School native name= latin name= motto = Every Eagle A Success established = 1950 type = Public endowment = staff = faculty = Head teacher = schoolmaster = principal = Mark Nixon… … Wikipedia
darbinis serveris — statusas T sritis informatika apibrėžtis ↑Serveris, naudojamas naujai kuriamoms, į kitą kalbą verčiamoms arba kitaip pertvarkomoms ↑svetainėms laikyti. Kai darbas su svetaine baigiamas, svetainė patikrinama, ir kai pripažįstama, kad ją galima… … Enciklopedinis kompiuterijos žodynas
Hyper-V — Microsoft Hyper V (кодовое имя Viridian),[1] система виртуализации для x64 систем на основе гипервизора.[2] Бета версия Hyper V была включена в x64 версии Windows Server 2008, а финальная версия для этих версий была выпущена 26 июня… … Википедия
Как организовать модель Development, Staging, Production?
30k уников в день, три выделенных сервера в распоряжении. У меня стоит две задачи: построить fail-safe работу двух (трёх?) продакшн серверов (один серв. упал, сайт жив); и организовать работу сторонних фриланс-разработчиков, которые будут обновлять сайт.
Предполагаю сделать 1 сервер load balancer’ом, и два зеркальных production — обрабатывать запросы.
Как лучше поступить с разработчиками? Прочитал про Development — (Integration) — Staging — Production. Стоит ли поднимать виртуальные машины для Development и Staging, или вполне можно держать их на одном из продакшн, на отдельном IP, со своей копией БД?
Позволить разработчикам заливать по FTP что-то на продакшн, или жестко ограничить их коммитами в SVN, и только ответственным сотрудникам дать права на запуск деплоймент скриптов из SVN на продакшн?
Что почитать про Best Practices организации работы разработчиков над проектом?
Разработчики должны иметь свое изолированное окружение, обычно локальное
Дальше неплохо иметь промежуточный dev сервер, как для последнего прогона тестов, так и для интеграционных тестов
Далее dev копируется в продакшн, или снепшот из продакшена копируется в дев и они меняются ( если что можно мгновенно переключиться в старый )
Заливка из VCS только в дев.
Можно ли ставить дев и продакшн в одной среде зависит от того когда тестируется производительность и прочие нагрузочные вещи. Если до заливки в дев, то можно, иначе — нельзя — есть риск завалить тестами или кривыми изменениями.
Я бы сделал один сервер в продакшн, второй в реплику и третий дев. При сем дев и продакшн менял местами и бекапил бы их вдруг в друга, а реплика имела бы два контейнера или набора серверов соответствующие двум другим машинам.
Настройка Staging окружения
Общепринятая практика заключается в том, чтобы работать локально в проекте и выкатывать ревизии на производственный сервер, но шаг, который люди часто пропускают, является промежуточным сервером. Промежуточный сервер представляет собой смесь между производством и разработкой; вы можете проверить свое приложение так, как если бы оно было на производстве. Давайте рассмотрим некоторые из проблем, которые вам придется рассмотреть, а также шаги, необходимые для репликации производственной платформы как службы (PAAS).
Это произошло не один раз: я выкатываю ревизию моего приложения в производство, только чтобы найти проблему после ее публикации. Эти проблемы могут быть такими же простыми, как забывать добавлять изображения в ваш репозиторий, или же может быть такой же большой, как изменение структуры базы данных локально, и забыть обновить производственную базу данных. Проблемы случаются со всеми, особенно когда вы устремились к крайним срокам. В этих ситуациях разумной идеей является создание промежуточного окружения. Идея состоит в том, чтобы иметь сервер, который тесно реплицирует производственное окружение, чтобы протестировать ваше приложение перед публикацией.
Промежуточное окружение не только позволяет отследить человеческие ошибки, но и проблемы, связанные с программным обеспечением.
Это все в деталях (в основном)
Проблемы случаются со всеми, особенно когда вы устремились к крайним срокам.
Создание промежуточной среды зависит от вашей производственной среды. Нет волшебного решения, которое работает в любой ситуации. Но в большинстве случаев следуют аналогичной схеме, и я расскажу о всех ключевых моментах.
Справедливо предположить, что большинство людей развертывают свои приложения с помощью какого-то средства управления версиями (например, GIT). Если есть вероятность того, что вы работаете над старым проектом, который все еще использует FTP, сайты, такие как ftploy.com или deployHQ.com, могут выступать в качестве буфера между GIT и вашим сервером. Джеффри Уэй собрал информативное видео, в котором подробно описывается, как это сделать.
Помимо GIT, вам нужно подумать о языках, программном обеспечении и «специальных» функциях, предлагаемых вашими производственными серверами. Я использую PAAS на основе PHP, названный Fortrabbit, потому что они предлагают обновленную поддержку PHP, Apache и GIT. Они также предоставляют возможность добавить ключевое слово в сообщение GIT commit, которое запускает Composer для установки зависимостей вашего проекта.
Это система, которую я установлю в остальной части этой статьи. Его стандартный набор функций, а также специальная функция композитора делают Fortrabbit идеальным для широкого круга хостов. Просто помните: это не волшебное решение, но шаги, которые вы делаете, следуют тому же шаблону, который вы использовали бы для настройки промежуточной среды для большинства проектов. Подготовьте процесс к вашим конкретным потребностям.
Поэтому без дальнейших церемоний, давайте уже приступим.
Создание сервера
Создание промежуточного окружения напрямую зависит от вашего производственного окружения.
Существует множество различных операционных систем, которые вы можете запускать на сервере. Fortrabbit запускает Debian Squeeze на своих серверах, и поскольку мы пытаемся их сопоставить, я решил запустить его также.
Vagrant принимает виртуальный снимок операционной системы в качестве базового «бокса», и затем вы можете создавать несколько виртуальных машин из этого образа. Итак, сначала нужно загрузить базовое поле для Debian Squeeze. Я не совсем уверен, откуда моя копия, поэтому я загрузил ее в DropBox для загрузки и использования. Чтобы установить, откройте окно терминала и введите:
Это добавляет бокс в Vagrant с именем «debian». Теперь мы можем создать экземпляр этого бокса для нашего промежуточного окружения. Сначала создадим новую папку:
Затем создайте конфигурационный файл Vagrant, введя:
Эти параметры говорят Vagrant о создании новой виртуальной машины на основе нашего базового блока Debian Squeeze. Затем он устанавливает сетевой режим в « bridged». Виртуальная машина с мостовой сетью отображается как новая физическая машина для вашего маршрутизатора, поэтому она автоматически получает свой собственный IP-адрес. Это позволяет получить доступ к устройству с любого устройства в сети (возможно, вне сети, если вы настроите маршрутизатор).
Теперь мы можем запустить нашу виртуальную машину с помощью команды: « vagrant up » (без кавычек).
Вы должны увидеть вывод Vagrant, создающий вашу виртуальную машину. Если ваш компьютер имеет несколько сетевых адаптеров, подключенных к сети, Vagrant предложит вам выбрать NIC для моста.
Давайте перейдем и настроим программное обеспечение сервера.
Программное обеспечение
Настройка Fortrabbit включает в себя:
Мы готовы начать. Убедитесь, что окно терминала открыто и вы залогинены на сервере через SSH. Во-первых, добавьте dotdeb repo в APT (менеджер пакетов), добавив новый файл в каталог sources.d :
Это открывает новый файл с именем dotdeb.list в vim (текстовый редактор). Имя не важно, потому что все файлы в этом каталоге считываются в APT. Нам нужно добавить четыре строки в этот файл. Если вы никогда не использовали VIM, просто введите « i », чтобы войти в режим вставки и скопируйте/вставьте следующие четыре строки:
Нажатие Enter сохраняет файл и возвращает вас в командную строку.
Теперь мы добавили репозитории, но нам еще нужно добавить подпись, прежде чем мы сможем их использовать. Чтобы добавить ключ GNU, введите следующее:
Это загружает ключ dotdeb и добавляет его как подписанный источник. Теперь обновите APT, чтобы вытащить новый пакет, набрав:
Это может занять около минуты, но у вас будут все пакеты dotdeb, перечисленные в APT, когда выполнится команда. Благодаря тому, как dotdeb настроен и как загружаются зависимости APT, мы можем одновременно установить Apache и PHP, набрав:
С помощью этой отдельной строки APT устанавливает и настраивает Apache2 и PHP5. Если вы используете дополнение Memcache Fortrabbit, вы можете установить его с помощью:
Но я не собираюсь касаться memcache в нашем примере в этой статье.
Теперь нам нужно установить расширения, которые использует Fortrabbit. Выполните следующую команду:
Последнее, что нам нужно установить, это Composer. Я собираюсь установить его глобально, потому что мы будем использовать его в нескольких разных местах. Команды для глобальной установки Composer:
Первая команда загружает и выполняет установку; вторая команда перемещает Composer в папку bin, чтобы мы могли использовать ее без объявления пути. Перейдем к конфигурации.
Настройка Apache
Скорее всего, вы можете работать над несколькими проектами. Если это так, наличие промежуточного сервера для каждого проекта создает много накладных расходов. Чтобы разрешить использование нескольких сайтов на одном сервере, нам нужно добавить виртуальные хосты на основе имени в Apache и разделить каталоги и репозитории для каждого проекта.
Начнем с виртуального хоста.
Внутри введите следующее (помните, чтобы нажать « i » для режима вставки):
Первая строка объявляет виртуальный хост, который прослушивает запросы на любом IP-адресе на порту 80. Затем мы устанавливаем адрес электронной почты администратора и имя сервера. Адрес электронной почты предназначен для сообщений об ошибках, а параметр имени сервера сообщает Apache, когда он читает этот виртуальный хост. Регулярные виртуальные хосты работают с IP-адресами. Например, каждый vhost прослушивает другой IP; так Apache различает их.
Поскольку у вас, вероятно, есть только один IP-адрес, мы можем использовать виртуальные хосты на основе имен, позволяя вам указать другое имя на одном IP-адресе.
В нашем примере любые запросы, направленные на demo.dev, собираются этим виртуальным хостом.
Последние две строки говорят Apache, как назвать файл лога и что писать в этот лог. Наш файл лога называется demo.log в папке логов Apache, расположенной в /var/log/apache2/ на этой виртуальной машине.
Чтобы включить этот vhost, введите следующее:
Мы не хотим, чтобы пользователь root имел собственную папку, поэтому измените ее на пользователя vagrant с помощью команды chown :
Теперь перезапустите Apache:
Немного Git магии
Убедитесь, что вы находитесь в домашнем каталоге, набрав cd
Пустой репо является стандартным репо без рабочего каталога. Если вы хотите узнать больше о GIT, посмотрите видеоролик Andrew Burgess.
Теперь нам нужна возможность пушить код в папку сайта, и есть много способов сделать это. Но мне нравится делать вещи как можно ближе к сервису, которому я подражаю. Вот картина процесса git fortrabbit, взятого с их сайта:
Вы можете видеть, что процесс push проходит через три этапа. Он отображает сообщение об обновлении при его подключении и развертывает сайт в каталоге. Заключительный шаг устанавливает все, если сообщение фиксации изменений содержит ключевые слова «[trigger: composer]». Затем, после завершения этих трех шагов, вам будет отображено «>> All Done
Прежде чем создавать хуки, я хочу поговорить о цветах.
Я выполняю большую часть своей работы в терминале, и чаще всего терминальные приложения оставляют все одинаковым цветом. Добавление различных цветов в ваше приложение гораздо повышает читаемость и упрощает его использование. Так что я займусь распространением «цветовых практик» в терминальных приложениях, я займу минутку, чтобы обсудить, как они работают.
Цвета в терминале
Терминалы поставляются с шестнадцатью цветами ANSI, которые можно настроить и использовать на терминале. Вот изображение экрана настроек iTerm2, показывающего шестнадцать цветовых слотов:
Если все сделано правильно, приведенный выше код выводит слова «hello world» красным цветом (если только этот слот не установлен на другой цвет).
Всюду по остальной части учебника я буду добавлять цвета к командам. Не стесняйтесь следовать или опускать их; они не являются строго обязательными. Но если вы хотите использовать цвета, не стесняйтесь использовать мой класс помощник. Теперь давайте вернемся к написанию хуков.
Создание хуков
Если вы еще раз взглянете на скриншот Fortrabbit, вы увидите, что перед обновлением репо отображается сообщение «Шаг 1: Обновление репозитория». Чтобы сделать все правильно, мы должны поместить это сообщение в хук pre-receive, который выполняется до обновления репо. В окне терминала введите:
Это открывает хук для редактирования. Добавьте следующий код:
Первая строка сообщает ОС, что это файл PHP и запускать его как таковой. Затем мы назначаем цвет и последовательность сброса для переменных. Последний шаг делает echo строки.
Следующий хук немного сложнее, потому что он обрабатывает остальные действия. Мы сделаем это шаг за шагом, поэтому сохраните первый хук (: wq) и откройте следующий:
Хук после приема изменений запускается после обновления репо. Мы должны сначала обновить сайт, а затем проверить триггер Composer. Вот скелет нашей программы, не говоря о новой логике:
Это две простые команды, но вы получите сообщение об ошибке, если попытаетесь запустить их из хука.
GIT устанавливает некоторые переменные среды до запуска хуков. Вы можете обойти это одним из двух решений, и я покажу вам оба.
Теперь нам нужно проверить триггер Composer. Давайте разделим это на два шага. Сначала мы проверяем триггер, а затем выполняем composer. Замените второй комментарий TODO следующим:
Первая строка извлекает сообщение фиксации с помощью команды git log и передает в специальном формате, чтобы исключить любую дополнительную информацию. Затем мы проверяем, имеет ли строка специальное триггерное слово и выводим третий шаг и OK-сообщение. Мы проверяем ключевое слово Composer, но вы можете реализовать несколько ключевых слов для других функций, таких как: migrate в Laravel или выполнить модульные тесты. Добавьте что-нибудь, чтобы улучшить рабочий процесс.
Вторая проблема заключается в том, что иногда Composer использует GIT для загрузки пакетов, и эти попытки терпят неудачу из-за переменных среды. Итак, вот хорошее место, чтобы просто удалить переменную окружения «GIT_DIR». Замените комментарий для запуска Composer следующим образом:
Связывание свободных концов
У нас теперь есть настройка обоих хуков, но мы не совсем готовы начать использовать наш сервер. Во-первых, нам нужно сделать эти крючки исполняемыми:
Затем создайте репозиторий GIT в папке сайта. Мы получим ошибку, если попытаемся запустить наши хуки, потому что папка сайта не является репозиторией GIT. Чтобы исправить этот введите:
Вы также должны добавить свой открытый ключ к авторизованным хостам этого сервера, чтобы вы могли получить доступ к серверу через GIT без пароля. Вы можете скопировать свой открытый ключ, набрав на своем компьютере (а не виртуальной машине):
Затем просто вставьте его на сервер в файл
Просто добавьте его в файл, но оставьте все, что уже внутри.
Затем нам нужно добавить IP-адрес этого сервера в наш файл hosts. Чтобы найти IP-адрес, введите:
Это показывает IP-адрес всех сетевых устройств на этой виртуальной машине. Добавьте тот, который подключается к вашей локальной сети. Если вы не можете определить, какой IP-адрес использовать, скопируйте и вставьте его в свой браузер. Если он подключается, у вас есть правильный IP-адрес.
Возьмите IP-адрес и добавьте его в файл хостов вашего компьютера (а не файл хостов VM). Файл hosts на Mac находится по адресу etc/hosts :
Затем добавьте следующую строку:
Если это будет возможно, вы сможете перейти на http://demo.dev в своем браузере. Находясь на вашем Mac, создайте папку и инициализируйте репозиторий GIT:
Если все пойдет хорошо, вы должны увидеть ответ от наших хуков GIT. Переход к http://demo.dev должен привести к появлению сообщения «Hello World» в вашем браузере.
Вывод
Таким образом, вы можете создать промежуточное окружение, которое имитирует функциональность типичного PAAS. Если у вас возникли проблемы с этим, или вам нужно настроить несколько промежуточных сред, я создал сценарий, который полностью автоматизирует процесс. Для получения дополнительной информации вы можете посетить stagr.gmanricks.com.
Надеюсь, вам понравилась статья. Не стесняйтесь задавать любые вопросы, которые могут возникнуть в комментариях. Спасибо за чтение.
Среды разработки
В любом производственном процессе, к которому относится и разработка программ, есть различные этапы. Грубо говоря, их можно представить так:
Производство
С этим пунктом всё более менее понятно: мы поставили себе любимый редактор, открыли в нем исходный код проекта и работаем, не покладая рук. Возможно, даже, пишем тесты и, самое главное, иногда их запускаем. Если это веб-сайт, то периодически запускаем сервер и смотрим в браузере, что получилось.
Кроме этого, код в среде разработки обычно пишется не в основной ветке вашей системы контроля версий, а в ветке-фиче. Это важно, так как не блокирует возможность делать быстрые правки, если на сервере что-то поломалось, и нужно поправить только небольшой кусок, а новые наработки вы ещё не готовы выливать.
Читайте также: DevOps — что это такое и почему эти практики меняют мир разработки уже сейчас
Сборка
После того, как вы реализовали свою задачу (фичу) и она была протестирована, код задачи вливается в основную ветку — и происходит так называемая интеграция. Это название связано с тем, что, возможно, кроме этой фичи, параллельно велась разработка другой фичи, в другой ветке, и с высокой вероятностью ту задачу выполняли даже не вы. И вот теперь в основной ветке они встретились, а работают они вместе или нет — ещё предстоит выяснить.
(Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде).
Контроль и испытания
Обычно тестирование включает в себя несколько этапов. Первый, на котором происходит проверка конкретно вашей отдельной фичи, и второй, на котором проверяется всё то, что пойдет в следующий релиз.
Ведь даже собрав всё в одну ветку (все фичи) и проверив их локально, нельзя быть до конца уверенным, что в бою, на реальных данных, всё заработает хорошо. Кроме этого, скорее всего, у вас есть менеджер или даже тестировщики, которые тоже хотят посмотреть/проверить, всё ли хорошо. И тут на сцену врывается ещё одна производственная среда, которая называется средой интеграции (предпродакшен), или стейджинг (staging), как её все называют.
Тут появляется ещё одно новое слово: «релиз». Релиз по-другому называют «выпуск». С одной стороны, это процесс выкатки в бой новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.
Continuous Integration Server
Одна из разновидностей сборочной среды называется «сервер непрерывной интеграции». Это такая отдельная машина (а может быть целый парк машин), на которую выливается код для проверки в автоматическом режиме. Обычно это происходит по какому-нибудь событию, например, на Github это пулреквест. В настроенных проектах каждый пулреквест отправляется в сервис, подобный https://travis-ci.org. Этот сервис прогоняет тестовый набор на нужной ветке (с фичей) и после этого прикрепляет отчет к пулреквесту, в котором пишет о результатах проверки.
Такая система позволяет очень сильно ускорить процесс интеграции. Сильно снижается нагрузка на разработчиков и автоматизируется рутина. Разработчику достаточно писать код и отправлять его в репозиторий, а система сама будет проводить необходимые проверки и выполнять слияние. Непрерывная интеграция является частью практик под названием «экстремальное программирование (XP)».
Доставка
Мы упустили один важный момент. Каким образом новый код попадает в предпродакшен и в продакшен-среду после того, как вы закончили разработку? Делает он это благодаря процессу, который в простонародье называют «деплой».
Как показывает практика, многие до сих пор делают деплой руками. Заходят на сервер (а если их много?) клонируют код, руками меняют базу и так далее.
Можно бесконечно обсуждать то, насколько это плохо. Начиная с того, что по сути отсутствует налаженный, повторяемый процесс, а значит всегда есть вероятность того, что ворвется человеческий фактор и случайно будет что-то забыто/потеряно/удалено. Заканчивая тем, что знания хранятся в одной голове, и сам процесс релиза становится вуду-процедурой, которую может делать только Вася, а иногда он болеет, ходит в отпуск и может уволиться. Часто в таких компаниях релиз — крайне болезненная процедура, которая занимает не один час, а может даже пару дней.
При хорошо отлаженном процессе, релиз занимает десяток минут, и может делаться любым разработчиком в любой момент (почти). Хекслет иногда деплоится по 5-10 раз в день.
Основные задачи, которые стоят перед вами во время деплоя: