Философия DevOps

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

Для гарантирования успеха инициатив, связанных с devops, требуется нисходящая поддержка со стороны менеджмента. Если противники изменений сумеют убедить руководителей организации в ненужности перемен, вряд ли что-то получится. Изменения требуют времени, и в течение переходного периода неизбежно возникают проблемы. По причине отсутствия единого решения по внедрению изменений придется воспользоваться методом проб и ошибок для подбора инструментов и процессов, наиболее подходящих для вашей организации.

Предоставьте сотрудникам организации возможность дать обратную связь. Пусть делятся своими мыслями о ходе процесса изменений, о том, как эти изменения отражаются на них. Уделяйте внимание негативным отзывам и авторам таких отзывов. Если предлагаемые изменения не устраивают множество людей, возможно, следует докопаться до причин такого недовольства и внести необходимые коррективы. Но если несколько недовольных сотрудников поднимают шумиху, не позвольте им «пустить под откос» изменения, которые приносят благо большинству сотрудников. Далеко не каждый сотрудник подходит организации, а если он противится любым изменениям, в том числе и внедрению devops, лучше с ним расстаться.

Часть IV. Инструменты

Глава 11. Обзор экосистемы инструментов

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

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

Разработка программного обеспечения

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

Локальная среда разработки

Наличие последовательной локальной среды разработки критически важно для быстрого привлечения сотрудников к процессу разработки программ. Сказанное вовсе не означает, что нужно «запереть» сотрудников в узкие рамки стандартного редактора, лишив их каких-либо дополнительных возможностей по настройке. Скорее это означает, что в распоряжении пользователей появятся инструменты, которые позволят им эффективно выполнять работу.

Минимальные требования к локальной среде разработки могут существенно отличаться в зависимости от индивидуальных предпочтений. Если нужно просто расширить сотрудничество, достаточно установить несколько дополнительных мониторов. Если же предполагается проводить длительные сеансы просмотра в комфортных условиях, придется установить мониторы высокого разрешения, клавиатуры, мыши и другие устройства ввода информации. Процесс классификации текущего стандарта локальной среды разработки включает идентификацию согласованной структуры, используемой как внутри команды, так и на межкомандном уровне. Благодаря такой классификации облегчается и ускоряется привлечение новых сотрудников к выполнению важных заданий в вашей организации.