Stage сервер что это
Среды разработки
В любом производственном процессе, к которому относится и разработка программ, есть различные этапы. Грубо говоря, их можно представить так:
Производство
С этим пунктом всё более менее понятно: мы поставили себе любимый редактор, открыли в нем исходный код проекта и работаем, не покладая рук. Возможно, даже, пишем тесты и, самое главное, иногда их запускаем. Если это веб-сайт, то периодически запускаем сервер и смотрим в браузере, что получилось.
Кроме этого, код в среде разработки обычно пишется не в основной ветке вашей системы контроля версий, а в ветке-фиче. Это важно, так как не блокирует возможность делать быстрые правки, если на сервере что-то поломалось, и нужно поправить только небольшой кусок, а новые наработки вы ещё не готовы выливать.
Читайте также: DevOps — что это такое и почему эти практики меняют мир разработки уже сейчас
Сборка
После того, как вы реализовали свою задачу (фичу) и она была протестирована, код задачи вливается в основную ветку — и происходит так называемая интеграция. Это название связано с тем, что, возможно, кроме этой фичи, параллельно велась разработка другой фичи, в другой ветке, и с высокой вероятностью ту задачу выполняли даже не вы. И вот теперь в основной ветке они встретились, а работают они вместе или нет — ещё предстоит выяснить.
(Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде).
Контроль и испытания
Обычно тестирование включает в себя несколько этапов. Первый, на котором происходит проверка конкретно вашей отдельной фичи, и второй, на котором проверяется всё то, что пойдет в следующий релиз.
Ведь даже собрав всё в одну ветку (все фичи) и проверив их локально, нельзя быть до конца уверенным, что в бою, на реальных данных, всё заработает хорошо. Кроме этого, скорее всего, у вас есть менеджер или даже тестировщики, которые тоже хотят посмотреть/проверить, всё ли хорошо. И тут на сцену врывается ещё одна производственная среда, которая называется средой интеграции (предпродакшен), или стейджинг (staging), как её все называют.
Тут появляется ещё одно новое слово: «релиз». Релиз по-другому называют «выпуск». С одной стороны, это процесс выкатки в бой новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.
Continuous Integration Server
Одна из разновидностей сборочной среды называется «сервер непрерывной интеграции». Это такая отдельная машина (а может быть целый парк машин), на которую выливается код для проверки в автоматическом режиме. Обычно это происходит по какому-нибудь событию, например, на Github это пулреквест. В настроенных проектах каждый пулреквест отправляется в сервис, подобный https://travis-ci.org. Этот сервис прогоняет тестовый набор на нужной ветке (с фичей) и после этого прикрепляет отчет к пулреквесту, в котором пишет о результатах проверки.
Такая система позволяет очень сильно ускорить процесс интеграции. Сильно снижается нагрузка на разработчиков и автоматизируется рутина. Разработчику достаточно писать код и отправлять его в репозиторий, а система сама будет проводить необходимые проверки и выполнять слияние. Непрерывная интеграция является частью практик под названием «экстремальное программирование (XP)».
Доставка
Мы упустили один важный момент. Каким образом новый код попадает в предпродакшен и в продакшен-среду после того, как вы закончили разработку? Делает он это благодаря процессу, который в простонародье называют «деплой».
Как показывает практика, многие до сих пор делают деплой руками. Заходят на сервер (а если их много?) клонируют код, руками меняют базу и так далее.
Можно бесконечно обсуждать то, насколько это плохо. Начиная с того, что по сути отсутствует налаженный, повторяемый процесс, а значит всегда есть вероятность того, что ворвется человеческий фактор и случайно будет что-то забыто/потеряно/удалено. Заканчивая тем, что знания хранятся в одной голове, и сам процесс релиза становится вуду-процедурой, которую может делать только Вася, а иногда он болеет, ходит в отпуск и может уволиться. Часто в таких компаниях релиз — крайне болезненная процедура, которая занимает не один час, а может даже пару дней.
При хорошо отлаженном процессе, релиз занимает десяток минут, и может делаться любым разработчиком в любой момент (почти). Хекслет иногда деплоится по 5-10 раз в день.
Основные задачи, которые стоят перед вами во время деплоя:
Как организовать модель 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 только в дев.
Можно ли ставить дев и продакшн в одной среде зависит от того когда тестируется производительность и прочие нагрузочные вещи. Если до заливки в дев, то можно, иначе — нельзя — есть риск завалить тестами или кривыми изменениями.
Я бы сделал один сервер в продакшн, второй в реплику и третий дев. При сем дев и продакшн менял местами и бекапил бы их вдруг в друга, а реплика имела бы два контейнера или набора серверов соответствующие двум другим машинам.
Улучшаем тестирование путем использования реального трафика
TL;DR Чем ближе к реальности ваши тестовые данные, тем лучше. Попробуйте Gor — автоматическое перенаправление production трафика на тестовую площадку в реальном времени.
Здесь в Granify мы обрабатываем огромное количество генерируемых пользователями данных, наш бизнес построен на этом. Мы должны быть уверены что данные собираются и обрабатываются правильно.
Вы даже не представляете насколько странными могут быть данные пришедшие от пользователей. Источником могут быть прокси-серверы, браузеры о которых вы никогда не слышали, ошибки на клиентской стороне, и так далее.
Не важно сколько у вас тестов и фикстур, они просто не могут покрыть все случаи. Трафик с production всегда будет отличаться от ожидаемого.
Более того, мы может просто все сломать при обновлении версии, даже если все тесты прошли. На моей практике это случается постоянно.
Есть целый класс ошибок которые очень непросто найти автоматизированным и ручным тестирование: concurrency, ошибки в настройке серверов, ошибки которые проявляются при вызове команд только в определенном порядке, и многое другое.
Но мы можешь сделать несколько вещей что бы упростить поиск таких багов и улучшить стабильность системы:
Всегда тестируем на staging
Наличие Staging среды обязательно, и она должна быть идентична production. Использование таких средств как Puppet или Chef сильно облегчает задачу.
Вы должны требовать что бы разработчики всегда в ручную тестировали свой код на staging. Это помогает найти самые очевидные ошибки, но это все еще очень далеко от того что может случится на production трафике.
Тестируем на реальных данных
Есть несколько техник для позволяющих протестировать ваш код на реальных данных (я рекомендую использоваться обе):
1. Обновлять только 1 из production серверов, таким образом часть ваших пользователей будет обрабатываться новым кодом. Эта техника имеет несколько минусов: часть ваших пользователей может увидеть ошибки, и вам возможно придется использоваться «липкие» сессии. Это довольно похоже на A/B тестирование.
2. Воспроизведение production трафика (log replay)
Илья Григорик написал замечательную статью про нагрузочное тестирование используя log replay технику.
Все статьи что я читал на эту тему упоминают log replay как средство для нагрузочного тестирования используя реальные данные. Я же хочу показать как использовать эту технику для ежедневного тестирования и нахождения ошибок.
Такие программы как jMeter, httperf or Tsung имеют поддержку log replay, но она либо в зачаточном состоянии либо сфокусированная на нагрузочном тестировании а не эмуляции реальных пользователей. Чувствуете разницу? Реальные пользователе это не только набор запросов, очень важно правильный порядок и время между запросами, различные HTTP заголовки и так далее. Для нагрузочного тестирования это порой не важно, но для поиска ошибок это критично. К тому же эти средства сложны в настройке и автоматизации.
Разработчики очень ленивы. Если вы хотите что бы ваши разработчики использоватли какую либо программу/сервис, он должен быть максимально автоматизирован, а еще лучше что бы оно работало так что никто ничего не заметил.
Воспроизводим production трафик в автоматическом режиме
Я написал простую программу Gor
Gor — позволяет автоматические воспроизводить production трафик на staging в реальном времени, 24 часа в сутки, с минимальными затратами. Таким образом ваша staging среда всегда получает порцию реально трафика.
Gor состоит из 2-ух частей: Listener и Replay сервера. Listener устанавливается на production веб серверы, а дублирует весь трафик на Replay сервер на отдельной машине, который уже направляет его на нужные адрес. Принцип работы показан на диаграмме ниже:
Gor поддерживает ограничение количества запросов. Это очень важная настройка, так как staging как правильно использует меньше машин чем production, и вы может выставить максимальное кол-во запросов в секунду которое может выдержать ваша staging среда.
Вы можете найти подробную документацию на странице проекта.
Так как Gor написан на Go, для запуска мы можете просто использовать уже скомпилированный дистрибутив Downloads
В Granify, мы используем Gor в production в течении некоторого времени, и очень довольны результатами.
Как правильно настраивать дев-окружение для веб-разработки?
Привет всем! Ребят, подскажите какие-то best practices как правильно организовывать dev окружение для веб-разработки. Имеется следующий конкретный кейс:
Международный портал, с несколькими отдельными сервисами. Например, как в Яндексе есть metrika.ya.ru, webmasters.yandex.ru, direct.yandex.ru и все это разные сервисы/кабинеты.
Допустим в компании работают три программиста. Есть dev-сервер со следующей структурой:
есть отдельный домен: company-dev.com и настроены виртуальные хосты для каждого разработчика:
Выглядит это как-то неправильно все. Не говоря уже о том, что в компании в разныз странах основной домен company.com может выглядеть как company.ru, company.de, company.fr etc.
Если в компании появляется новый разработчик, то приходится создавать ему 5 поддоменов и 5 виртуальных хостов.
Если в компании открывается какой-то новый сервис, то нужно добавить его каждому из трех (а в будущем больше) разработчиков.
Как сделать так, чтобы было 5 субдоменов на проде и 5 субдоменов на дев-сервере.
но каждый разработчик попадал в свою физическую папку? Чтоб не получилось, что три человека работают с одним файлом и мешают друг-другу. Кроме того, чтоб была возможность разработчику1 сказать тестеру или менеджеру, зайди ко мне посмотри оно работает. «зайди ко мне» имеется ввиду открыть его дев в браузере. Знаю что можно сделать своей ДНС сервер и для каждого сотрудника в компании по его айпи направлять его в нужную папку на сервере, хотя в браузере у всех будет один адрес. Но кажется что это слишком сложно. Может есть еще какие-то варианты. Как вообще люди это делают нормальные?
Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз.
Кто решал подобные задачи, поделитесь советом, плз.
Оценить 1 комментарий
Домены будете создавать уже на продакшене. В простейшем случае склонируете на продакшн машину удаленный репозиторий проекта и в конфигах nginx нужно будет написать что-то типа такого
Есть еще мнение, что каждый разраб должен разворачивать себе локальное окружение на своем компе, но хз.
>>Разработчикам не нужен никакой dev сервер.
Иван Артамонов: с ДНС есть проблема если тестировщики внешние и у них ip не постоянные.
надо только определиться, что и как нужно:
1 сделать сборку для дев сервера (со всеми нужными хостами для разработки) те для каждого разработчика свой вирт сервер с настроенными хостами и 4 уровенем url
2 собрать выкатку на тест:
2.1 отдельной ветки [branch].service1.company.com
2.2 RC для [rc-branch].service1.company.com (c группой веток из 2.1)
2.3 выкатку на staging/pre-prod c полубоевой БД [staging].service1.company.com
и да Вам скорее всего нужен Админ ) часов на +/- 8-40 (при наличии расписанных хотелок ) для формирования системы разработки, и конечно разрешение сверху 🙂
Иван Артамонов: разные версии php и прочего у разрабов не будут, если юзать какой-нибудь простейший Vagrant или аналоги. Прелесть в том, что у всех будет одинаковая среда. Вообще, дельные варианты предложили, буду рад потом прочитать статью на Хабре о том, как вы все организовали 🙂
Иван Артамонов: вы ошибаетесь. Полный url это domain.com/index.php/catalog/product и всё что после index.php это не папки, а обычная строка, так называемый роут. Картинку ищет не браузер, а веб-сервер и делать он это будет относительно той директории, которую вы ему укажите для домена domain.com. Если у вас
Иван Артамонов: index.php не убирают, а скрывают, но в любом случае все урлы по которым физически на сервере ничего не существует, он редиректит на точку входа index.php, который лежит в корне. Соответственно, какую страницу сайта вы бы не открыли, ваш current path всегда будет равен директории где лежит index.php т.к все страницы вашего сайта динамические и физически их не существует на сервере (они все генерируются через index.php). Соответственно на любой динамически сгенерированой странице сайта (через index.php) все ассеты будут резолвиться относительно этого current path. Я мог бы вам показать, что именно так это и работает и я уверен в этом на 100%, но мне лень тратить своё время и разворачивать для вас демо, чтобы что-то вам доказать. Достаточно понять, что ваш веб сервер всегда обращается к файлу index.php, какую страницу сайта вы бы не открыли, если у вас одна точка входа, незвисимо от того, видите ли вы index.php в урл или нет. И соответственно все картинки без начального слеша будут отдаваться относительно директории того файла, к которому вы обратились, а это index.php для любой страницы вашего сайта.
Про тестеров я вам уже не раз писал. Если у вас есть специально обученный человек, которому не жить как приспичило тестировать каждую ветку в отдельности, то он может скачать эту конкретную ветку себе на дев машину и делать там всё, что он хочет не заморачивая голову остальным. Но вообще в крупных компаниях тестировщики работают не так, они плевать хотели на все эти ваши ветки, они ничего в них не понимают. У них есть чек-листы и именно по ним они проверяют конкретный билд, который собирается выйти в релиз. Это не ветка и не одна фича, это то, что уже реально готово выйти на продакшн как next version. Если тестеры заворачивают этот билд, то разработчики правят то, что тестировщиков не устраивает и выкатывают новый билд. И для таких вещей есть stage. Ваша проблема в том, что вы сами же придумали себе проблему, а теперь пытаетесь героически её решить.
На этом всё. В дальнейшую дискуссию не вступаю, поскольку мне больше нечего сказать, по вашей теме.
И собственно ветка будет не для разработчика, а для фичи/фикса/дева
Про структуру репозитория почитать можно тут: https://habrahabr.ru/post/106912/
Как это реализовать, я не подскажу, так что это не более чем концепт.
P.S. как по мне, если разработчики правят один и тот же файл, то тут дело в постановке задач для них.
Иван Артамонов: как минимум он уменьшить количество. Допустим у вас будет 5 разрабов, а в работе 2 фичи для основного сайта и один фикс для service1. Таким образом у вас должны быть ветки: [dev|feature1|feature2].company.com и [dev|fix1].service1.company.com. Я думаю 5 доменов, вместо 10 неплохое сокращение. Да и к тому же это позволит вам понимать, что происходит на том или ином домене.
Иван Артамонов описанная Илья схема потребует введения в работу, к примеру Jenkins,
и вся работа будет строиться примерно так:
Настройка 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.
Надеюсь, вам понравилась статья. Не стесняйтесь задавать любые вопросы, которые могут возникнуть в комментариях. Спасибо за чтение.