Деплой не должен увольняться вместе с разработчиком
Увольнение разработчика — плохой способ выяснять, на чьих доступах работает деплой.
Если CI/CD использует личные учётные данные сотрудника, их отзыв может сломать выпуск изменений. И обычный оффбординг внезапно превращается в инфраструктурную задачу.
В Pyrobyte я отвечал за внутреннюю инфраструктуру разработки и доступы. Ею пользовались около 50–60 сотрудников, включая примерно 30 разработчиков.
Для CI/CD использовали отдельные deploy credentials и служебные аккаунты. Так сборки и деплои не зависели от персональных учётных данных разработчиков.
Отдельно настроили права на выпуск изменений: protected branches, разделение ролей Developer / Maintainer / Owner. В нашей конфигурации merge в критичные ветки и deploy были доступны только Maintainer.
При уходе сотрудника централизованно отзывали его доступы в GitLab, парольнике, на серверах и в остальных корпоративных системах. Весь процесс укладывался в один день.
У автоматизации оставались собственные учётные данные. Подставлять в CI/CD личные доступы следующего разработчика не требовалось.
Такие дела!
· 7 ч
Когда деплой (или любой другой аспект) держится только на одном человеке, первый же вопрос - как так получилось? Разумеется, вопрос актуален для размеров команды, когда физически возможно ответственность разделить хотя бы на двоих.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 7 ч
В специфике работы студии - такое, к сожалению, встречается за каждым углом, и борьба с bus фактором - в любых его проявлениях - это ежедневный труд)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён