Работа web-ресурса и архитектура приложения
У нас имеется php-приложение работающее с базами данных: MySQL и PostgreSQL. PHP-приложение работает в докер-кластере перед, которым стоит балансировщик нагрузки. Вся вышеописанная инфраструктура расположена на основной площадке и дублируется на резервной.
Общая схема работы решения
Для каждого разработчика поставлена задача. Программист работает над задачей в локальном окружении. Есть ветка каждого разработчика, в которой он работает. Когда разработчик готов он отправляет push-request в ветку dev. ТимЛид одобряет push-requestы пакетом так часто, как этого требует ситуация. Изменения попадают в дев.
По этому событию срабатывает запуск job в Jenkins,который развертывает инфраструктуру в дев окружении, выполняет ряд автоматических тестов, результаты которых видны в Jira и почте.
По завершению сборки и тестирования, инфраструктура для тестирования удаляется. Если тестирование прошло неудачно, разработчики работают над исправлением проблем. Если тестирование успешно, ТимЛид делает для ветки Dev merge в ветку Test.
По событию merge Jenkins запускает deploy в тестовую среду, набор автоматических тестов. В последующем в этой среде выполняется ручное тестирование QA-инженерами. Для чего ТимЛидом создается соответствующая задача. В нее линкуются задачи разработчиков, по которым выполнялись изменения.
Из тестового окружения в продуктивное делается точно такой же merge репозитория в master ветку.Bручную ТимЛидом запускается задача в Jenkins выполняющая build и deploy «боевого» приложения.
Как организовать рабочее место программиста
Для рабочего окружения разработчика предполагается использовать уже готовые докер-контейнеры. У сотрудника есть доступ на скачивание контейнера. И каждый программист на своей рабочей машине будет получать идентичную среду. Это может быть как докер, так и другая заготовленная виртуальная машина. Но, в целом, докер может работать под любой ОС (в там числе Windows и MacOS).
Организация тестирования
Для тестирования кода предполагается использовать SonarQube. Его результаты будут отображаться в Jenkins. Эти тесты будут проходить на Jenkins перед развертыванием. Помимо тестов на SonarQube ,будут также тесты для функционала приложения и интеграционные тесты, которые встраиваются в само приложение.
Их разрабатывают непосредственно программисты, работающие над приложением. Также можно сделать автоматизацию тестирования написав скрипт, который будет выполнять определенные действия в уже развернутом приложении. Для этого также есть готовые решения.
Среда проведения тестов
Все предполагается сделать на CubrerNets от Google.Будем делать общий кластер и делить его по принадлежности к среде. На нем будет несколько окружений, в каждом будут свои контейнеры и свои сервера. Сервера приложений будут работать в докере, автоматически балансироваться
Развертывание среды
Развертывание среды производится средствами Jenkins. Удаление контейнеров предыдущей среды выполняется автоматически непосредственно перед развертыванием новой.
Тестирование нескольких веток
Нет смысла выполнять что-то одновременно. Дженкинс не позволит сделать это без вмешательства оператора. Да, можно запускать Job с параметрами, но я не сторонник такого подхода. Разные ветки будут тестироваться все равно по порядку.
Как разработчики узнают о результатах тестирования
Дженкинс рассылает отчет о результатах тестирования на почту программистам. Также информация о состоянии сборки будет доступна в Jira. Результаты ручного тестирования QA-инженер будет оформлять в виде подзадач с описанием найденных проблем внутри задач, поставленных разработчикам.
Чем тестирование в среде Dev отличается от тестирования в среде Test помимо наличия ручных проверок работы
Во-первых, Test Environment отличается от Dev инфраструктурой. Dev пердназначена для проверки работы приложения, в то время как Test – для проверки корректной работы всех взаимосвязей в среде, максимально приближенной к реальной. Таким образом, на Dev мы имеем минимально необходимое количество серверов, в то время как инфраструктура Test копирует инфраструктуру, для работы приложения в одном из ЦОД.
Во вторых, на стадии Dev у нас коммиты в git-ветку Dev представляют собой изменения от каждого отдельного разработчика. В то время как на стадии Test коммит представляет собой уже пакет изменений от нескольких разработчиков. Следовательно на ТимЛида ложится ответственность за отбор изменений, формирующих этот пакет, поскольку на стадии теста уже затруднительно вычленение отдельного изменения из пакета. Для этого ТимЛид должен будет откатить commit в ветке Test, содержащий пакет изменений, откатить commit на ветке Dev, в котором применяется сбойное изменение, запустить Job для тестирования в среде Dev, при условии успешного выполнения предыдущего шага -сделать commit в ветку Test, применяющий скорректированный пакет изменений, заново провести тестирование в среде Test. На практике этого не должно происходить.
Права доступа в Jenkins
Доступ в Jenkins есть у DevOps инженера, как у «главного дирижера». Также ТимЛид должен иметь возможность запускать Job-ы вручную.
Как происходит обновление Production? интересуют не только технические, но и организационные подробности, то есть кто это делает и после каких согласований и одобрений?
ТимЛид делает merge в ветку master. И вручную запускает на Jenkins job по сборке и развертыванию приложения в продуктивной среде. Jenkins работает по следующему плану:
- Поскольку во время деплоя контейнеров новых версий сайт не должен изменяться пользователями, то нужно на это время поставить заглушку и выгнать пользователей.
- Сделать резервную копию предыдущей версии.
- Выключить контейнер с приложением
- Внести изменения в базу из файла SQL, если они есть
- Поднять новый контейнер с обновленным приложением
- Выполнить набор автоматических тестов на работоспособность приложения
- Убрать заглушку и разрешить доступ пользователям.
Что делать, если ошибка закралась в продуктивную среду
Такого быть не должно. Если такое случилось – это большой просчет ТимЛида. Если исправление не может быть выпущено в кратчайшие сроки, предусмотрена процедура отката до предыдущей версии. Для этого будет репозиторий с докер-контейнерами, в котором будут храниться более старые сборки. Особо острый момент связан с откатом базы. Потому что при появлении необходимости возврата к предыдущей версии базы будут потеряны, транзакции совершенные обновленным приложением, что грозит интренет-магазину большим ущербом, как материальным, так и репутационным.
Как работать с тестированием изменений базы
При необходимости изменения базы разработчик формирует SQL файл с требуемыми изменениями. Этот SQL файл Jenkins накатывает поверх уже существующей базы с данными.
Dev тестирования проходят на некотором небольшом наборе данных, который формируется после успешного завершения тестирования в среде Test очередного изменения базы.
Проверки в Test Environment прогоняются на полном наборе свежих данных, снятых с продуктивной среды в процессе развертывания тестовой. Это необходимо потому что в Test Environment в том числе делаются нагрузочные тесты и нужно видеть реальную картину.
Важный момент это грамотно выстроенный процесс всех протекающих операций. Конечно же, при внедрении будет период пилотного тестирования, за который важно выявить и устранить все недостатки спланированного решения.