Текстовый курс по DevOps
Зачем нужны непрерывные проверки для обеспечения качества?
Организации сильно полагаются на проверки, аудиты, инспекции и согласования непосредственно перед развёртыванием в рабочих средах. Обычно их проводят люди, имеющие к вашей работе лишь косвенное отношение, если вообще имеющие. Хуже всего, что ответственные за проверки и согласования иногда неправильно понимают вашу работу, и вам приходится объяснять её прямо перед развёртыванием.
Проблемы внешних механизмов контроля
В большинстве организаций механизмы контроля создать проще, чем построить взаимное доверие. Поэтому в формах контроля изменений появляются новые вопросы, в иерархии — дополнительные уровни согласования, а для понимания и одобрения изменений требуется больше времени.
В среде с низким доверием и культурой командования и контроля одни и те же инциденты неизбежно повторяются. Возникает порочный круг: не видно, какая работа выполняется и какие проблемы повторяются, а работу собирают в крупные пакеты, чтобы как можно реже проводить трудные развёртывания. Длительные сроки поставки ухудшают способность быстро выводить продукты на рынок. Медленная, запоздалая обратная связь, по которой нельзя действовать, не даёт командам учиться на ошибках.
Компетентная организация DevOps понимает, что о работе и связанных с ней проблемах больше всего знают те, кто находится ближе всего к её выполнению. Дополнительный внешний контроль и согласования не приносят пользы потоку создания ценности. Отсюда одна из важнейших задач современного руководства: создать культуру высокого доверия, где работа прозрачна, а искреннее уважение и взаимное доверие составляют основу повседневного взаимодействия.
Сделайте коллегиальную проверку частью повседневной работы, чтобы меньше зависеть от периодических инспекций. Пусть разработчики, инженеры эксплуатации и специалисты по качеству и информационной безопасности постоянно сотрудничают и проверяют работу друг друга, чтобы обеспечить безопасное развёртывание.
Координация сложной работы без внешнего контроля
Даже одной команде бывает трудно вести проект. Когда разные команды работают над компонентами одной системы, задача усложняется. Справиться с ней помогут следующие меры:
- Комитеты по изменениям, в которые входят профильные специалисты, а не только менеджеры, помогают выявить зависимости между командами до внесения изменений.
- Слабосвязанные архитектуры на основе SOA и микросервисов сокращают зависимости и затраты на взаимодействие.
- Техническим представителям команд DevOps следует определять зависимости и порядок разработки и развёртывания.
- Постоянно общайтесь на общих платформах чатов, чтобы согласовывать изменения и проверять, одинаково ли вы их понимаете.
- Более масштабные и рискованные изменения, например миграции или изменения инфраструктуры, требуют репетиций в тестовых средах и технических мер, таких как переключение при отказе и полный откат.
Высокоэффективные организации DevOps больше полагаются на коллегиальную проверку и меньше — на внешние согласования
Многие ведущие организации DevOps, включая Amazon, Netflix, Etsy и GitHub, используют процесс проверки и развёртывания через «Pull Request». Вот как он работает:
- Разработчица создаёт отдельную ветку от основной. Ветка должна существовать не дольше нескольких рабочих дней и иметь понятное имя, например «login-screen-v2». Разработчица работает с веткой локально и регулярно вносит изменения в систему управления версиями.
- Когда разработчица считает, что ветку можно слить с основной, она открывает запрос на слияние (pull request) и просит коллег проверить изменения.
- Получив отзывы и одобрение участников команды DevOps, разработчица сливает код с основной веткой. Затем она развёртывает его в рабочих системах.
Для важных изменений, например в схемах баз данных или информационной безопасности приложений, разработчица может также отправить дополнительные запросы на проверку другим профильным специалистам, таким как администраторы баз данных и специалисты по информационной безопасности.
При проверке кода также придерживайтесь принципа небольших пакетов. Иначе проверка затягивается и отнимает много сил у инженеров. Чем больше изменение, тем быстрее растёт риск и тем менее надёжна проверка. Если изменение слишком велико и трудно для понимания, попросите разработчика разбить его на несколько небольших и понятных частей.
Изменения каждого участника команды DevOps должен проверить коллега, независимо от должности и опыта автора. Всем следует следить за потоком коммитов, чтобы быстро выявлять и устранять возможные конфликты до того, как они вызовут более серьёзные проблемы в конвейере или, что ещё хуже, при развёртывании в рабочей среде.
Парное программирование само по себе и вместе с разработкой через тестирование (TDD), когда один разработчик пишет код приложения, а другой — автоматизированный тест, позволяет проверять код прямо в процессе написания. Измерения при одинаковом размере команды и требованиях проекта показали, что парное программирование занимает на 15% больше времени, но сокращает количество ошибок в коде на 85%. Поэтому вам и команде DevOps стоит оценить возможность его применения.
Можно также рассмотреть проверку кода вместе с автором у его рабочего места, автоматические уведомления о новых коммитах и инструменты, которые помогают проверять код и повышать его качество.
ВЫВОДЫ
Поручите каждой команде DevOps отвечать за качество своей работы. Создайте культуру, в которой непрерывную и качественную проверку кода ценят так же, как написание качественного кода.
