Оформление результата: сборка, тестирование, packaging, deployment
- Виртуализация как средство создания изолированных окружений: чем больше внешних сущностей являются условно-абстрактными (сеть, фс, прочие девайсы), тем более переносимым и контролируемым является данное окружение.
Тестирование
- Тестирование, в отличие от верификации, вещь практическая и приблизительная, но практически широко применимая.
- В чем задача администратора в данном случае: предоставить среду для тестирования. Среда состоит из инструмента выполнения тестов (сюда же всякое прочее) и окружений, в которых проводится тестирование.
- Управление тестами
- Автоматизация задач, связанных с тестами. Какие задачи:
- Бюрократия, связанная с регрессиями ? тикеты
- Локализация причины регрессии
- Тесты бывают разные. В отличие от верификации, тест слабо формализованы. Тем не менее:
- Юнит-тесты. Штука сугубо программистская. Обычно они пускают их у себя для основных локальных проверок. Точка автоматизации ? пре-коммит хук.
- Общие регрессионные тесты (а не сломалось ли чего).
- Тесты производительности (как статические, так и на реальных данных)
- UI-тесты ("прокликивание"), примерно тут опять же ? тесты на реальных данных
- Тестирование - разные окружения - виртуализация!
- Автоматическое заведение тикетов по регрессиям
- Тестирование на каждый коммит ? overkill, обычно при высокой технологичности их гоняют ночами вместе со сборкой (собрал nightly ? потестил), но при нахождении регрессий можно использовать как автоматизацию для bisect.
Сборка
- Изолированная сборка ? опять же виртуализация как средство создания изолированного окружения
- Почему изолированная: всякое разное окружение может вносить всякие разные сайд-эффекты. Контролируемое и воспроизводимое окружение позволяет сразу отделять проблемы, связанные с окружением, от проблем, независимых от него.
- Идея: есть окружение1, окружение2, версия1, версия2. Версия1 в окружении1 работала, а в версии2 окружения2 что-то сломалось. Одновременно можно смотреть, ломается ли что-то при смене окружения и при откате над другую версию.
- Поскольку окружение специфицируется, то есть контролирование ситуации (в том числе, и у администратора, который эти окружения и разворачивает/предоставляет), и этот процесс вполне автоматизируется.
- Почему изолированная: всякое разное окружение может вносить всякие разные сайд-эффекты. Контролируемое и воспроизводимое окружение позволяет сразу отделять проблемы, связанные с окружением, от проблем, независимых от него.
- offtopic: сборка пакетов из исходников [бэкпортинг] (для бинарных дистрибутивов) ? актуальная задача ввиду того, что вебаппы обычно нужно ставить свежие и никто нормально пакетировать вебаппы не умеет (а даже если и умеют, все равно нужно более другие патчи накатывать какие)
- Отсюда же растет частая необходимость ставить из пакетных репозиториев типа pip ? там оно практически самое актуальное
- Мысль о двоякости положения: с одной стороны, сами что-то разрабатываем, с другой стороны ? являемся пользователями инструментов, составляющих инфраструктуру разработки. А так как разработчики привыкли писать код, то патчи пишутся быстро и возникают часто.
Packaging
- Подготовка пакетов для разных дистрибутивов ? задача чаще ментейнеров дистрибутивов, они более в теме. Идеальный вариант ? когда среди разработчиков проекта есть ментейнер целевого дистрибутива (или хотя бы достаточно квалифицированный пользователь)
- Магии тут никакой нет, дистрибутивы давно уже предоставляют сборочницы для локального разворачивания.
- Фактически есть две стратегии: быть как можно более независимым от дистрибутивов или же,наоборот, как можно более тесно интегрироваться с ними.
- Уделить внимание вопросу защищенности сборочницы от несанкционированного доступа (по большому счету, кроме как администратору, к ней доступ не нужен никому)
Deployment
- Опять же, полностью контролируемое окружение, к которому доступ, кроме как администратору, никому не нужен
- Тем не менее, у девелоперов должна быть возможность эмулирования продакшен-площадки по возможности во всех аспектах.
- Отсюда опять же виртуализация
- Автоматизация ? deploy при создании подписанного тега.
- Возможность отката к предыдущему состоянию в любой момент
- Вопрос, насколько это стоит автоматизировать. Реально, проавтоматизировать это можно только в идеальном мире, в реальности, один сервис связан с окружающим миром и fail тестов продакшн площадки с ненулевой вероятностью может быть false-positive.
Ссылки
Видеозапись 6-й лекции курса по системному администрированию Linux (развертывание)