Деплой не должен увольняться вместе с разработчиком

Увольнение разработчика — плохой способ выяснять, на чьих доступах работает деплой.

Если CI/CD использует личные учётные данные сотрудника, их отзыв может сломать выпуск изменений. И обычный оффбординг внезапно превращается в инфраструктурную задачу.

В Pyrobyte я отвечал за внутреннюю инфраструктуру разработки и доступы. Ею пользовались около 50–60 сотрудников, включая примерно 30 разработчиков.

Для CI/CD использовали отдельные deploy credentials и служебные аккаунты. Так сборки и деплои не зависели от персональных учётных данных разработчиков.

Отдельно настроили права на выпуск изменений: protected branches, разделение ролей Developer / Maintainer / Owner. В нашей конфигурации merge в критичные ветки и deploy были доступны только Maintainer.

При уходе сотрудника централизованно отзывали его доступы в GitLab, парольнике, на серверах и в остальных корпоративных системах. Весь процесс укладывался в один день.

У автоматизации оставались собственные учётные данные. Подставлять в CI/CD личные доступы следующего разработчика не требовалось.

Такие дела!