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