#мнение Доступ к production
Эта тема навеяна спором в чате, потому хочу более явно раскрыть своё мнение на этот счёт и заодно можем обсудить в комментариях.
Я считаю, что любой разработчик от junior должен иметь доступ к production выкладке сервисов, вливанию в master и проведению релизов. Конечно есть ограничения доступа к данным их чтению или изменению, которые определяются политикой компании и эти ограничения несомненно должны присутствовать.
Это лично мое мнение и отражает то, как я построил процессы в компании. В крупных компаниях такой подход не всегда подойдёт по безопасности. Доступ же у нас предоставляется сразу после прохождениям сотрудника испытательного срока и обучения процессам.
Зачем это? В первую очередь независимо от уровня знаний, люди - это в первой очередь твоя команда, с которой ты создаёшь ценность для компании, поэтому если ты не можешь каждому из них доверять - это плохой старт для взаимоотношений.
Давая им доступ, ты повышаешь не только уровень доверия, но и ответственности. Теперь разработчик будет понимать, как тот код, который он пишет, будет работать на production. Он будет более аккуратно относится к тому коду, который попадает на prod и внимательнее делать ревью.
Так же у него быстро сформируется понимание инфраструктуры, DevOps практик, логирования, мониторинга, автоматизации. Благодаря этому люди могут быстро расти и развиваться.
Что это даёт команде? В первую очередь распределение нагрузки. При 6-ти разработчиках в команде и релизах 1 раз в неделю - это всего 1 релиз на человека в 1,5 месяца. Конечно первые релизы все проводят при поддержке старших товарищей, но это временно. А если принять во внимание выкладку hotfix - то это значительное снижение нагрузки на senior разработчиков.
Что это даёт компании? Кроме распределённой нагрузки - это отсутствие централизации знаний об устройстве систем и взаимозаменяемость.
Были ли проблемы? Конечно, но они единичны. Надо быть готовым к тому, что кто-то по незнанию может что-то сломать. Может выложить не тот сервис или не ту версию или вообще уронить сервер. Поэтому прежде чем внедрять такую практику нужно убедиться что система может быть быстро восстановлена, а все разработчики прошли обучение и понимают как работать с вашим кластером и сервисами. Аналогично вливание в master должен проходить по общим правилам код ревью, несмотря на доступы.
Но когда вы успешно это внедрите, вы поймёте, что плюсов от этого намного больше, чем рисков. Неумелый разработчик может при релизе сломать что-то на 5 минут, но зато после обучения он может сам быстро починить что-то критичное, значительно сократив время простоя системы. Кроме того, сразу будут видны слабые места в процессах релиза, которые может автоматизировать.
Эта тема навеяна спором в чате, потому хочу более явно раскрыть своё мнение на этот счёт и заодно можем обсудить в комментариях.
Я считаю, что любой разработчик от junior должен иметь доступ к production выкладке сервисов, вливанию в master и проведению релизов. Конечно есть ограничения доступа к данным их чтению или изменению, которые определяются политикой компании и эти ограничения несомненно должны присутствовать.
Это лично мое мнение и отражает то, как я построил процессы в компании. В крупных компаниях такой подход не всегда подойдёт по безопасности. Доступ же у нас предоставляется сразу после прохождениям сотрудника испытательного срока и обучения процессам.
Зачем это? В первую очередь независимо от уровня знаний, люди - это в первой очередь твоя команда, с которой ты создаёшь ценность для компании, поэтому если ты не можешь каждому из них доверять - это плохой старт для взаимоотношений.
Давая им доступ, ты повышаешь не только уровень доверия, но и ответственности. Теперь разработчик будет понимать, как тот код, который он пишет, будет работать на production. Он будет более аккуратно относится к тому коду, который попадает на prod и внимательнее делать ревью.
Так же у него быстро сформируется понимание инфраструктуры, DevOps практик, логирования, мониторинга, автоматизации. Благодаря этому люди могут быстро расти и развиваться.
Что это даёт команде? В первую очередь распределение нагрузки. При 6-ти разработчиках в команде и релизах 1 раз в неделю - это всего 1 релиз на человека в 1,5 месяца. Конечно первые релизы все проводят при поддержке старших товарищей, но это временно. А если принять во внимание выкладку hotfix - то это значительное снижение нагрузки на senior разработчиков.
Что это даёт компании? Кроме распределённой нагрузки - это отсутствие централизации знаний об устройстве систем и взаимозаменяемость.
Были ли проблемы? Конечно, но они единичны. Надо быть готовым к тому, что кто-то по незнанию может что-то сломать. Может выложить не тот сервис или не ту версию или вообще уронить сервер. Поэтому прежде чем внедрять такую практику нужно убедиться что система может быть быстро восстановлена, а все разработчики прошли обучение и понимают как работать с вашим кластером и сервисами. Аналогично вливание в master должен проходить по общим правилам код ревью, несмотря на доступы.
Но когда вы успешно это внедрите, вы поймёте, что плюсов от этого намного больше, чем рисков. Неумелый разработчик может при релизе сломать что-то на 5 минут, но зато после обучения он может сам быстро починить что-то критичное, значительно сократив время простоя системы. Кроме того, сразу будут видны слабые места в процессах релиза, которые может автоматизировать.