Download - Continuousdelivery
Con$nuous Delivery как перестать релизиться и
начать жить
Иван Евтухович
SECON’ 2013
План доклада
• Неудачные истории из жизни • Принципы непрерывной поставки ПО • Управление конфигурацией • Непрерывная интеграция • Тестирование
Неудачные истории из жизни
Сломавшийся сервер
1. Плановая перезагрузка 2. Сервер не подымается 3. В 23 часа начинаем перенос 4. В 4 утра он все еще идет 5. Утром с 10 продолжаем
Что там было?
1. 10-‐15 скриптов в cron 2. у каждого скрипта свой набор ключей 3. 2 ключевых сервиса 4. все настройки умерли вместе с сервером
Много оборудования
• Десятки и сотни единиц оборудования • Процесс первоначальной настройки: – Загружаемся с диска – Переставляем диск с образом – Записываем – Правим 3 параметра в системе
• Сколько раз я ошибся в IP-‐адресах? • Сколько это занимало времени? • И это только настройка OS
Ошибки в конфигурации
• MySQL 5.0 на produc$on, 5.1 на stage • php без модуля и вызов @funcname • database pool size в многопоточном приложении
• Array.count в Ruby 1.8.7 (development) и 1.8.6 (produc$on)
• Патчи для Ruby во FreeBSD и Hpricot
И еще…
• Патч в gem $dy, который делали руками • Размер блока в md-‐устройстве • PostgreSQL мастер на Linux, слейв – FreeBSD • Выкатка через chef/capistrano • Версии PostgreSQL 9.0 – на stage, 9.1 в бою
Опрос
Как предотвратить подобные ситуации?
Принципы
• Создать повторяемый и надежный процесс поставки ПО
• Автоматизировать все, что можно • Хранить все в системе контроля версий • Совершенствоваться через повторения • Получать раннюю обратную связь
продолжение…
• Встроенный контроль качества • Выполнено, значит зарелизилось • Каждый отвечает за процесс поставки ПО • Непрерывные улучшения
Преимущества
• Понижение стресса • Уменьшение ошибок • Помощь команде • Гибкость выкатки
Сколько времени нужно, чтобы строчка кода попала в релиз?
Сколько времени вам надо, чтобы развернуть ваше приложение?
Конвейер
Среда разработки
CI
QA
Staging
Produc$on
DevOps
• Разработчики и QA – враги • QA и админы – враги • Разработчики и админы – враги • Это неправда!
Управление конфигурацией
Как хранить конфигурацию?
Хранить образы всех серверов Минусы: – изменение в образе и на сервере – отсутствие контроля (кто и когда)
Что такое конфигурация?
Что ценно на сервере?
На боевом сервере размер папки /usr 730 Мб
Дороги ли мне эти данные?
Минимальное количество данных, необходимое для того, чтобы
повторяемо воспроизводить среду
• OS (версия, образ) • Список установленных пакетов (с версиями) • Настройки системы • Библиотеки приложения
Образ системы
• Kiwi h�p://opensuse.github.com/kiwi/ • Cobbler h�p://cobbler.github.com/ • Spacewalk h�p://spacewalk.redhat.com/
Пакеты
OBS -‐ Open Build Service h�ps://build.opensuse.org/
Системы управления конфигурацией
• Chef h�p://www.opscode.com/chef/ • Puppet h�ps://puppetlabs.com/puppet/puppet-‐open-‐source/
• CFEngine • Salt
Функции
• Устанавливать нужные пакеты • Следить за файлами конфигурации • Запускать и перезапускать сервисы • Интеграция компонет
Opscode Chef
Chef сервер
db01 web01 web02
Выкатка
• Повторяема • Полностью автоматизирована • Независима от локальных настроек • Независимые релизы (и конфигурация) • Откат отрепетирован • Например: capistrano, fabric
Библиотеки приложения
• Maven для Java • Bundler для Ruby • Virtualenv/pip для Python
Bundler source 'h�p://rubygems.org’ gem 'rails', '3.1.10’ gem 'pg’ gem 'nokogiri' gem 'haml' gem 'devise', '1.5.0' gem 'russian', '~> 0.6.0' gem 'simple_form', '1.5.2' gem 'state_machine' gem 'globalize3', "~> 0.2.0.beta4”
При этом настройки Cobbler, OBS, Chef, Bundler лежат в системе контроля версий
Непрерывная интеграция
(Con$nuous Integra$on)
При каждом изменении:
• проект забирается из СКВ • проект собирается • прогоняются тесты • проходит выкатка на тестовый стенд (?) • рассылаются оповещения
• CruiseControl (CruiseControl.rb) • Jenkins • TeamCity от JetBrains • TravisCI
Проблема в людях
Практики
Делайте коммиты часто
• создайте хорошее покрытие автоматическими тестами
• сохраняйте время сборки и выполнения тестов небольшим
• не вносите изменений, когда сборка сломана
• прогоняйте тесты локально перед внесением изменений
• подождите прохождения тестов, а потом продолжайте работу
• не уходите домой, если сборка сломана • будьте готовы откатить изменения • не комментируйте сломавшиеся тесты • берите на себя ответственность за свои изменения
• пишите тесты перед кодом (TDD)
Тестирование
Автоматические
Приемочные тесты
Ручные
Показы
Юзабилити
Юнит тесты
Интеграционные
Выкатка
Автоматические
Нагрузочные
Безопасности
Ручные/Автоматические
Бизнес
Технологии
Подд
ержка
Критика
Готовых рецептов нет
• Думайте • Измеряйте • Экспериментируйте
Что почитать?
• con$nuousdelivery.com
Спасибо за внимание! Вопросы и ответы
[email protected] Twi�er: evtuhovich
h�p://blog.evtuhovich.ru/