Эта выдуманная история, но с вполне реальными проблемами. Итак, речь идет о том, как одна компания в лице своего ведущего руководящего персонала пытается спасти свою компанию. Проект «Феникс» — это продукт этой компании, который больше не может существовать привычным образом. Конкуренты внедряют свои новые функции быстро, а текущая команда очень долго выпускает свои релизы. После выпуска таких релизов практически всегда происходит отказ работоспособности продукта у многих пользователей ввиду плохого качества продукта и слабого интеграционного тестирования.
Понимая суть проблемы, менеджеры компании стараются всяческими способами исправить ситуацию, но первое время у них совсем ничего не выходит, и все становится только хуже. Есть большая зависимость от некоторых ведущих инженеров, отсутствие которых затрудняет обслуживание проектов, а также публикацию свежих версий. Немалой проблемой являются технические долги, которые со временем только растут.
Со временем ребята начинают внедрять новые подходы к разработке, особенно к тестированию и развертыванию, и это приводит к положительным результатам. Теперь у них нет технических долгов, а релизы можно делать хоть каждый день. Во избежание более детальных спойлеров я остановлюсь на очень кратком пересказе книги и сконцентрируюсь на некоторых других посылах этой книги.
Сама по себе технология внедрения DevOps с полноценными CI/CD решениями — это очень хорошо. Однако просто внедрение инструментов зачастую не даст большой пользы проекту. Да, это позволит быстро разрабатывать код, тестировать его и доставлять до пользователей. Однако для того, чтобы продукт был востребованным, и весь цикл разработки — наиболее эффективным, потребуется принципиально изменить подходы к коммуникации и совершенствованию процессов между отделами. Именно эта проблема всегда фоново (а иногда и явно) поднимается на протяжении всей книги. Все построение DevOps-процессов обсуждается вместе с мотивацией, бюрократией и другими нюансами. Часть из этих нюансов крайне нежелательны и губительны. На протяжении всей книги можно также наблюдать, как вместе с выстроенными процессами разработки и доставки продукта до конечного потребителя меняются и междукомандные взаимоотношения.
В целом это интересная книга и легко читается. Будет полезна тем, кто решил отвлечься от работы, но не уходить далеко от IT-темы. Более того, для многих менеджеров и управленческого персонала она была бы полезна еще и тем, чтобы взглянуть на то, какие проблемы могут возникнуть при неправильном подходе к делу и неправильной организации процессов, а также о том, как все это можно и нужно менять.
