Литрес - 1200 руб.

Вчера начальник попросил вас продемонстрировать клиентам новые замечательные средства, внедряемые в приложение, но вы не смогли показать им ничего. Все ваши раз работчики находятся на полпути к финальному релизу, и ни один из них не готов запустить приложение прямо сейчас. У вас есть код, он компилируется и проходит все тесты на вашем сервере непрерывной интеграции (Continuous Integration CI), но нужно еще несколько дней, чтобы развернуть новую версию в среде приемочного тестирования (User Acceptance Testing UAT). Имеет ли смысл показывать демонстрационную версию по первому требованию? В программе обнаружена критическая ошибка. Компания ежедневно теряет на этом деньги. Вы знаете, что нужно исправить: единственную строчку в библиотеке, используемой во всех трех слоях трехуровневой системы. Кроме того, нужно внести соответст вующие изменения в таблицу базы данных. Но при поставке предыдущей версии программы эта работа заняла все выходные вплоть до трех часов ночи в понедельник, причем разработчик, осуществлявший развертывание, вскоре уволился, заявив, что этот сумасшедший дом не для него. Вы понимаете, что и теперь за выходные не успеть, а значит, приложение окажется недоступным в течение какого то периода в рабочие дни. Вряд ли это понравится клиентам компании. Описанные выше проблемы, хоть и встречаются весьма часто, не являются необходимым следствием цикла разработки программного обеспечения. Скорее, наоборот: они служат признаком того, что в рабочем процессе что то не так. Поставка очередной версии программы должна быть быстрым, часто повторяющимся процессом. В наши дни многие компании выпускают по несколько версий ежедневно! Это вполне возможно даже в очень сложных проектах, содержащих огромный объем кода. В данной книге мы покажем вам, как это делается. Мэри и Том Поппендик задавались вопросами: ‘‘Сколько времени необходимо организации на развертывание новой версии приложения при изменении одной строки кода? Является ли этот процесс повторяющимся и надежным часто?’’ Интервал времени между принятием решения об изменении кода и поставкой новой версии продукта называется продолжительностью цикла. Это важный показатель в любом проекте. Во многих организациях продолжительность цикла колеблется от нескольких недель до месяцев, причем процесс подготовки релиза не является ни повторяющимся, ни надежным. Часто подготовка выполняется вручную и требует участия команды разработчиков для развертывания программы даже в тестовой и отладочной средах, не говоря уже о рабочей среде. Тем не менее нам часто встречались проекты, которые начинались, как описано выше, однако со временем были существенно доработаны, в результате чего продолжительность цикла была сокращена до нескольких часов и даже минут. Это возможно благодаря созданию полностью автоматизированного, повторяющегося и надежного процесса внесения изменений на различных стадиях сборки, тестирования и раз вертывания приложений. Ключевой элемент данного процесса автоматизация, позволяющая буквально одним щелчком на кнопке выполнять разнообразные задачи, связанные с развертыванием программного обеспечения (ПО). В данной книге описывается, без преувеличения, революционная технология развертывания, сокращающая продолжительность цикла и делающая процесс развертывания надежным и безопасным.

Часть I. Основы непрерывного развертывания
Глава 1. Проблема развертывания программного обеспечения
Глава 2. Стратегии управления конфигурациями
Глава 3. Непрерывная интеграция
Глава 4. Реализация стратегии тестирования
Часть II. Конвейер развертывания
Глава 5. Структура конвейера развертывания
Глава 6. Сценарии сборки и развертывания
Глава 7. Стадия фиксации
Глава 8. Автоматическое приемочное тестирование
Глава 9. Тестирование нефункциональных требований
Глава 10. Развертывание и выпуск приложений
Часть III. Процесс поставки
Глава 11. Управление инфраструктурой и средами
Глава 12. Управление данными
Глава 13. Управление компонентами и зависимостями
Глава 14. Управление версиями
Глава 15. Управление непрерывным развертыванием

Фарли Д.
Дейвид Фарли в настоящее время участвует в проекте построения самой производительной в мире электронной биржевой системы — London Multi-Asset Exchange. Имеет 20-летний опыт работы с крупномасштабными распределенными системами и является активным сторонником методик гибкой разработки. В компании ThoughtWorks работал техническим руководителем ряда важнейших проектов.

Хамбл Д.
Джез Хамбл — главный консультант компании ThoughtWorks Studios, помогающей различным организациям быстро и надежно поставлять высококачественное программное обеспечение. Начиная с 2000 года работал в различных IT-компаниях системным администратором, разработчиком, инструктором, консультантом и менеджером проектов. Постоянный докладчик на конференциях, посвященных гибкой разработке программного обеспечения.