Книга: Руководство по DevOps
Заключение
Заключение
В этой главе мы обсудили, как вводить в работу новые методики, повышающие качество вносимых изменений, сокращающие риск неудачных развертываний и уменьшающие зависимость от процессов согласования и одобрения изменений. Примеры из практики компаний GitHub и Target показывают: эти методики не только улучшают наши результаты, но также значительно сокращают время на создание продуктов и увеличивают производительность разработчиков. Для всего этого требуется культура высокого доверия.
Вот история об одном младшем инженере, рассказанная Джоном Оллспоу. Этот инженер спросил, можно ли отправить в развертывание небольшую правку в HTML-коде, и Оллспоу ответил: «Я не знаю». Затем он спросил: «Кто-нибудь просмотрел твой код? Ты знаешь, кого лучше всего спрашивать об изменениях такого типа? Сделал ли ты все возможное, чтобы досконально убедиться, что эти изменения будут вести себя в эксплуатации именно так, как и планировалось? Если да, то не спрашивай меня — просто внеси правки, и все».
Таким ответом Оллспоу напомнил инженеру, что за качество изменений отвечает только он сам: если она сделал все, что мог, чтобы убедиться в том, что все работает правильно, тогда ему не нужно было просить одобрения, он мог просто внести свои правки.
Создание условий, когда авторы идей сами отвечают за их качество, — важная часть производительной культуры высокого доверия. Ее мы и хотим построить. Кроме того, такие условия позволяют создать более безопасную систему, где все помогают друг другу достичь целей, преодолевая любые препятствия.
- Опасность процесса согласования изменений
- Потенциальные опасности чрезмерного контроля над изменениями
- Производительность в IT
- Рецензии коллег vs Получение разрешений
- Обеспечьте условия для координации и планирования изменений
- Введите практику рецензирования изменений
- Практический пример
- Потенциальные опасности тестирования преимущественно вручную и заморозки изменений
- Введите практику парного программирования, чтобы улучшить качество изменений
- Практический пример
- Замена неэффективного рецензирования кода парным программированием в организации Pivotal Labs (2011 г.)
- Оценка эффективности pull request процессов[139]
- Бесстрашно избавляйтесь от бюрократических процессов
- Заключение
- Заключение части IV