Непрерывное развертывание ПО. Джез Хамбл, Дейвид Фарли

Ссылка на OZON

Внушительный труд. И по внешнему виду (420 страниц большого формата мелким почерком), и по содержанию. Читается интересно, но местами сложно. Так как авторы говорят о любых проектах, то их иногда заносит в такие абстракции, что мне сложно осознать, о чем именно они пишут, и это при наличии опыта =)

Это однозначно НЕ книжка для начинающих, вы просто не поймете половину. А если и поймете, то все равно забудете, если возьмут на проект как джуниора, то он обычно ничего не может решать и тем более внедрять. А без практики, как говорится...

Мне книга понравилась. Заставляет задуматься. Где-то я осознала, что «вот это у нас тоже есть, и это же круто!». А то я когда пришла в проект, там уже много всего было, что воспринимается теперь как само собой разумеющееся. А на самом деле это классная фишка, о которой можно рассказать (есть у меня в планах на 12 недель «пост с работы раз в неделю», вполне подойдет). А где-то при чтении задумываешься «блин, а почему у нас такого нет? Ну ведь очень надо!».

Начинается книга с описания антишаблонов поставки релизов: это ручное тестирование, ручная сборка билда, ручная поставка. И обычно день релиза — это самый напряженный день у разработчиков и админов. На сутки работа останавливается, потому что надо следить за тем, развернется билд или нет. И очень важна сосредоточенность, чуть неправильно выполнишь инструкцию — А, КОШМАР, ВСЕ СЛОМАЛОСЬ!


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

Установка релиза на любое окружение — это тыкнуть на одну кнопочку в Team City или что там у вас стоит. Сделать это может даже тестировщик. И не надо думать о том, чем платформы отличаются друг от друга, что там надо вручную подкрутить и так далее. Потому что даже настройки самой платформы хранятся в системе версионного контроля и легко разворачиваются автоматически.

Так как релиз ставится одинаково на тестовые платформы и на продакшен → процесс развертывания до выхода в прод уже 10 раз протестирован → меньше проблем, скорее всего ничего не развалится.

Тут важно что? Чтобы разработчики работали совместно с админами, разрабатывая процесс развертывания. А то если одни что-то смастрячат, вторые не захотят поддерживать чужой код, в котором они ничего не понимают. А вот если сделают все вместе, то и разработчики будут изменения легко вносить, и админы по 1 кнопочке все развернут.


Цена управления конфигурациями вручную

Больная тема для меня. Авторы пишут, словно ножом по сердцу режут:

Зависимость проектов от ручного управления конфигурациями встречается довольно часто. Во многих организациях, в которых мы работали, проекты были зависимыми от управления конфигурациями как рабочих, так и тестовых сред. Например, зачастую не имело значения, что пул соединений сервера А ограничен 100 соединениями, а сервера В — 120, но иногда это оказывалось крайне важным.

Ох уж мне эти настройки сервера!

Когда-то у нас было мало Заказчиков и настройки для всех были едины. Но сейчас Заказчиков больше, нагрузки у всех разные. В итоге у клиента А увеличили пул соединений с БД, у клиента Б тоже что-то подправили. Как хранить эту информацию?

В конфлюенс записывать? Вариант, да. Но ручной труд = человеческий фактор. Что-то продолбал внести, и все. Настройку при переезде на новый сервер потеряли и снова уперлись в ограничение.

Я все мечтаю перенести это в систему управления версиями, все таки подкрутки. Как авторы в книге советуют. Правда, пока не особо представляю, как это должно выглядеть, так как мы поставляем коробку, которую разворачивают уже без нас, влиять на чужие сервера мы не можем.

Так что тут или виртуализация, или мб какой-то скрипт, который надо запускать от имени админа, чтобы он применял все важные настройки. Тогда такие скрипты можно хранить в hg, и всегда иметь возможность увидеть, что хранится у чужих заказчиков, из серии «а вдруг  мне это тоже надо?». Разумеется, очень важно комментировать в коде что почем. Думаю, будет очень полезно. Пока обсуждаем такой вариант. У нас вроде перекрытий не слишком много, но ведь надо смотреть в будущее!


Принципы развертывания ПО

1. Создайте надежный повторяющийся процесс развертывания.
2. Автоматизируйте все, что только можно.
3. Контролируйте все с помощью системы управления версиями.
4. Если операция болезненная, выполняйте ее чаще.
5. Встраивайте качество в продукцию (это как раз непрерывная интеграция, автотесты, быстрый фидбек)
6. Готово — значит выпущено. 
7. Каждый отвечает за процесс поставки. 
8. Непрерывное улучшение.

Насчет пункта два — авторы часто повторяют, что автоматизация очень полезна. Но двигаемся мелкими шажками. Конечно, вы не можете сразу взять и внедрить полностью новый процесс. Поэтому в одном релизе автоматизировали то, что приносит наибольшую #жизньболь коллегам. Потом новое узкое место нашли, и так далее. Мелкими шажками можно далеко уйти. Так что улучшайте систему постепенно, и через год сами удивитесь, как много успели сделать.

Информативные сообщения фиксации

Когда коммитите что-то, не забудьте о том, что ваше сообщение могут читать коллеги. Конечно, бывает такое, что надо срочно-срочно что-то пофиксить и коммитят кое-как. В итоге получается такой сценарий:

1. Вы находите ошибку в малозаметной строке кода.
2. С помощью системы управления версиями вы выясняете, кто и когда написал эту строку.
3. Человек, написавший строку, ушел в отпуск, уволился или ничего не помнит об этом, потому что это было давно. Таким образом, единственная доступная вам информация — короткое сообщение фиксации: «Исправление ошибки», из которого ничего не понятно.
4. Вы изменяете странную строку кода, чтобы исправить текущую ошибку.
5. Программа терпит крах в другом месте, потому что теперь воссоздана предыдущая ошибка.
6. Вы тратите много часов или дней в попытках вернуть приложение в работоспособное состояние.

Что еще?

Потом в книге идет еще много всякого полезного, что, в целом, крутится вокруг уже перечисленных выше принципов. Как автоматизирвоать процесс поставки и сборки. Как автоматизировать тесты итд. Также авторы разбирают разные сборщики (make, ant, gradle), разные системы версионного контроля (svn, git, mercurial)...

В общем, много всего интересного! Очень достойный труд, рекомендую ツ

PS: добавила книгу в общий список прочитанных мною книг.