Основные возможности платформы Hexlet не доступны в вашем браузере.
Пожалуйста, обновитесь. Выбрать браузер.
Разработка

Среды разработки. Мужики, выкатывай!

В любом производственном процессе, к которому относится и разработка программ, есть различные этапы. Грубо говоря, их можно представить так:

  1. Производство (разработка)
  2. Сборка
  3. Контроль и испытания
  4. Доставка

Производство

С этим пунктом все более менее понятно: мы поставили себе любимый редактор, открыли в нем исходный код проекта и работаем, не покладая рук. Возможно, даже, пишем тесты и, самое главное, иногда их запускаем. Если это веб-сайт, то периодически запускаем сервер и смотрим в браузере, что получилось.

Место, в котором происходит этот процесс, называется средой разработки, которая, как правило, является локальной. Зачем нужно какое-то специальное название? Чтобы это понять, нужно рассматривать ситуацию в целом. У нас всегда, как минимум, есть две среды. Одна - это среда разработки (ее часто называют development environment), а другая - это среда эксплуатации (так говорят редко, обычно боевая среда, production). И код должен вести себя по-разному в зависимости от среды.

Например:

  • В среде разработки шире уровень логгирования, то есть мы видим все отладочные сообщения и они нам помогают разрабатывать. В продакшене этот уровень отключают, так как очень быстро улетает место на диске.
  • В среде разработки мы не можем слать письма по-настоящему. Если это произойдет, то ваши пользователи не будут рады. Кстати, это часто бывает у тех, кто не настраивает разные среды.
  • В среде разработки отключают кэширование (техника для ускорения доступа).
  • Среда разработки может содержать нерабочий код и находится в неконсистентном (несогласованном) состоянии. Это нормально, мы ведь разрабатываем.

Кроме этого, код в среде разработки обычно пишется не в основной ветке вашей системы контроля версий, а в ветке-фиче. Это важно, так как не блокирует возможность делать быстрые правки, если на сервере что-то поломалось, и нужно поправить только небольшой кусок, а новые наработки вы еще не готовы выливать.

К сожалению, в среде php, до сих пор часто встречается ситуация, при которой разработка ведется прямо в боевой среде. Что приводит к очень печальным последствиям.

Сборка

После того, как вы реализовали свою задачу (фичу), и она была протестирована, код задачи вливается в основную ветку и происходит так называемая интеграция. Это название связано с тем, что, возможно, кроме этой фичи, параллельно велась разработка другой фичи, в другой ветке, и с высокой вероятностью ту задачу выполняли даже не вы. И вот теперь в основной ветке они встретились, а работают они вместе или нет — еще предстоит выяснить.

(Этот пункт сильно зависит от того, какой процесс выбран в конкретной команде).

Контроль и испытания

Обычно тестирование включает в себя несколько этапов. Первый, на котором происходит проверка конкретно вашей отдельной фичи и второй, на котором проверяется все то, что пойдет в следующий релиз.

Ведь даже собрав все в одну ветку (все фичи) и проверив их локально, нельзя быть до конца уверенным, что в бою, на реальных данных, все заработает хорошо. Кроме этого, скорее всего, у вас есть менеджер или даже тестировщики, которые тоже хотят посмотреть/проверить, все ли хорошо. И тут на сцену врывается еще одна производственная среда, которая называется средой интеграции (предпродакшен), или стейджинг (staging), как ее все называют.

Стейджинг — это такая среда, в которой происходит проверка перед боем. Ее особенностью является то, что она максимально приближена к условиям боевой среды, что дает возможность полнее протестировать то, что происходит. Обычно это то место, куда идут менеджеры, тестировщики, заказчики. Часто стейджинг выполняет сразу две задачи. Как проверку конкретных фич от разработчиков, так и окончательный прогон приложения перед релизом.

Тут появляется еще одно новое слово: "релиз". Релиз по-другому называют "выпуск". С одной стороны, это процесс выкатки в бой новой версии системы. С другой стороны, так иногда называют сборку, которая представляет из себя новую версию системы.

Continuous Integration Server

Одна из разновидностей сборочной среды называется "сервер непрерывной интеграции". Это такая отдельная машина (а может быть целый парк машин), на которую выливается код для проверки в автоматическом режиме. Обычно это происходит по какому-нибудь событию, например, на гитхабе это пулреквест. В настроенных проектах каждый пулреквест отправляется в сервис, подобный https://travis-ci.org. Этот сервис прогоняет тестовый набор на нужной ветке (с фичей) и после этого прикрепляет отчет к пулреквесту, в котором пишет о результатах проверки.

Такая система позволяет очень сильно ускорить процесс интеграции. Сильно снижается нагрузка на разработчиков и автоматизируется рутина. Разработчику достаточно писать код и отправлять его в репозиторий, а система сама будет проводить необходимые проверки и выполнять слияние. Непрерывная интеграция является частью практик под названием "экстремальное программирование (XP)".

Доставка

Мы упустили один важный момент. Каким образом новый код попадает в предпродакшен и в продакшен среду после того как вы закончили разработку? А делает он это благодаря процессу, который в простонародье называют "деплой".

Как показывает практика, многие до сих пор делают деплой руками. Заходят на сервер (а если их много?) клонируют код, руками меняют базу и так далее.

Можно бесконечно обсуждать то, насколько это плохо. Начиная с того, что по сути отсутствует налаженный, повторяемый процесс, а значит всегда есть вероятность того, что ворвется человеческий фактор и случайно будет что-то забыто/потеряно/удалено. Заканчивая тем, что знания хранятся в одной голове, и сам процесс релиза становится вуду-процедурой, которую может делать только Вася, а иногда он болеет, ходит в отпуск и может уволиться. Часто в таких компаниях релиз — крайне болезненная процедура, которая занимает не один час, а может даже пару дней.

При хорошо отлаженном процессе, релиз занимает десяток минут, и может делаться любым разработчиком в любой момент (почти). Хекслет иногда деплоится по 5-10 раз в день.

Основные задачи, которые стоят перед вами во время деплоя:

  • Взять новую версию кода из репозитория и залить его на сервер(ы)
  • Сделать все необходимые приготовления: накатить миграции, собрать frontend-скрипты и т.д.
  • Переключить проект на новую версию
  • Откатиться в случае ошибок

ci cycle

В среднем проекте количество действий, которое необходимо сделать при деплое, уже составляет десятки различных задач. Хорошая новость в том, что в современном мире это настолько отработанная процедура, что существует немало решений, позволяющих настроить деплой любого проекта. Одним из таких решений, является набор скриптов поверх ansible: https://github.com/ansistrano/deploy

Поделиться Вконтакте
Отправить в Телеграм