С помощью Hubot можно было проверять работоспособность сервисов, развертывать код в производственную среду и блокировать оповещения, когда сервисы переходили в профилактический режим. Повторяющиеся действия, например smoke-test при сбое развертывания, выведение серверов эксплуатации из работы, возврат к исходной ветке для front-end-сервисов или извинения инженерам, вызванным в нерабочее время, тоже стали возможными действиями в Hubot[154].
Результаты внедрения изменений в репозиторий исходного кода и команды, запускавшие процесс разветрывания, появлялись в чате. Кроме того, когда внесенные изменения продвигались по конвейеру развертывания, их статус также отображался в чате.
Типичный разговор в чате мог выглядеть так:
«@sr: @jnewland, как получить список больших репозиториев? что-то вроде disk_hogs?»
«@jnewland:/disk_hogs»
Ньюлэнд отмечает: некоторые вопросы, которые раньше часто задавали во время работы над проектом, теперь звучат очень редко. Например, инженеры могут спрашивать друг у друга: «Как там развертывание?», или «Ты проведешь развертывание или я?», или «В каком состоянии загрузка?»
Среди всех преимуществ — в их числе быстрая адаптация новых сотрудников и повышение производительности — Ньюлэнд особо выделяет то, что работа стала более человечной, инженеры теперь могли быстро и без усилий находить проблемы и помогать друг другу в их решении.
GitHub создал среду для совместного поиска новых знаний, которые могут быть трансформированы в статус организационных. Делиться знаниями с коллегами стало очень легко. Далее в этой главе мы рассмотрим способы того, как создавать пути и ускорять распространение нового опыта.
Автоматизируйте типовые процессы в ПО для многократного использования
Мы слишком часто закрепляем стандарты и процессы проектирования архитектуры, тестирования, развертывания и управления инфраструктурой в документах Word. Затем они пылятся в дальнем углу какого-нибудь сервера. Проблема в том, что инженеры, разрабатывающие новые приложения или среды, не всегда знают, что эти документы существуют, или у них нет времени реализовывать требования стандартов. В результате они создают свои инструменты и процессы с ожидаемым исходом: хрупкие, неподдерживаемые и ненадежные приложения, а также среды, которые сложно использовать, поддерживать и развивать.
Вместо того чтобы записывать опыт в файлы Word, мы должны так преобразовать эти стандарты и процессы, содержащие накопленный опыт компании, чтобы их было легко использовать. Один из лучших способов сделать эти знания полезными — поместить их в централизованный репозиторий и сделать его доступным для всех сотрудников.