Оформление результата: сборка, тестирование, packaging, deployment

• Виртуализация как средство создания изолированных окружений: чем больше внешних сущностей являются условно-абстрактными (сеть, фс, прочие девайсы), тем более переносимым и контролируемым является данное окружение.

Тестирование

• Тестирование, в отличие от верификации, вещь практическая и приблизительная, но практически широко применимая.
• В чём задача администратора в данном случае: предоставить среду для тестирования. Среда состоит из инструмента выполнения тестов (сюда же всякое прочее) и окружений, в которых проводится тестирование.
  • Управление тестами
  • Автоматизация задач, связанных с тестами. Какие задачи:
    • Бюрократия, связанная с регрессиями — тикеты
    • Локализация причины регрессии
• Тесты бывают разные. В отличие от верификации, тест слабо формализованы. Тем не менее:
  • Юнит-тесты. Штука сугубо программистская. Обычно они пускают их у себя для основных локальных проверок. Точка автоматизации — пре-коммит хук.
  • Общие регрессионные тесты (а не сломалось ли чего).
    • Тесты производительности (как статические, так и на реальных данных)
  • UI-тесты ("прокликивание"), примерно тут опять же — тесты на реальных данных
• Тестирование - разные окружения - виртуализация!
• Автоматическое заведение тикетов по регрессиям
• Тестирование на каждый коммит — overkill, обычно при высокой технологичности их гоняют ночами вместе со сборкой (собрал nightly — потестил), но при нахождении регрессий можно использовать как автоматизацию для bisect.

Сборка

• Изолированная сборка — опять же виртуализация как средство создания изолированного окружения
  • Почему изолированная: всякое разное окружение может вносить всякие разные сайд-эффекты. Контролируемое и воспроизводимое окружение позволяет сразу отделять проблемы, связанные с окружением, от проблем, независимых от него.
    • Идея: есть окружение1, окружение2, версия1, версия2. Версия1 в окружении1 работала, а в версии2 окружения2 что-то сломалось. Одновременно можно смотреть, ломается ли что-то при смене окружения и при откате над другую версию.
    • Поскольку окружение специфицируется, то есть контролирование ситуации (в том числе, и у администратора, который эти окружения и разворачивает/предоставляет), и этот процесс вполне автоматизируется.
• offtopic: сборка пакетов из исходников [бэкпортинг] (для бинарных дистрибутивов) — актуальная задача ввиду того, что вебаппы обычно нужно ставить свежие и никто нормально пакетировать вебаппы не умеет (а даже если и умеют, всё равно нужно более другие патчи накатывать какие)
  • Отсюда же растёт частая необходимость ставить из пакетных репозиториев типа pip — там оно практически самое актуальное
  • Мысль о двоякости положения: с одной стороны, сами что-то разрабатываем, с другой стороны — являемся пользователями инструментов, составляющих инфраструктуру разработки. А так как разработчики привыкли писать код, то патчи пишутся быстро и возникают часто.

Packaging

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

Deployment

• Опять же, полностью контролируемое окружение, к которому доступ, кроме как администратору, никому не нужен
  • Тем не менее, у девелоперов должна быть возможность эмулирования продакшен-площадки по возможности во всех аспектах.
  • Отсюда опять же виртуализация
• Автоматизация — deploy при создании подписанного тега.
• Возможность отката к предыдущему состоянию в любой момент
  • Вопрос, насколько это стоит автоматизировать. Реально, проавтоматизировать это можно только в идеальном мире, в реальности, один сервис связан с окружающим миром и fail тестов продакшн площадки с ненулевой вероятностью может быть false-positive.

Ссылки

• Buildbot

• Лекция про тестирование

• Лекция про сборку

• Курс про пакетирование

• Видеозапись 6-й лекции курса по системному администрированию Linux (развёртывание)