Это не кодинг на вайтборде, а настоящий Kubernetes-кластер в настоящем облаке и возможность пользоваться любой доступной информацией: Гугл, свои наработки, дока.
Так что нагуглить быстренько или использовать свои наработки - окэй, а звонок другу, если "другом" для помощи по такой простой задаче будет разработчик, то толку от такого сотрудника будет не так много.
А если друг работает где-то в другом месте, то мы лучше друга наймем, который знает или умеет нагуглить:)
Леонид не HR, а руководитель DevOps юнита, он в начале статьи представился
А насчёт грейдов, то они уж точно не усложняют текущие задачи.
Они позволяют объективно сформулировать необходимые знания, навыки и ответственность, нужные на каждом уровне. Ну и от этого формируется понятная траектория развития сотрудника, а не просто "ну ты вроде норм работал, но не особо развился по ощущениям, потому без повышения в этот раз"
По всем бывшим сотрудникам, если только не было каких-то прям жестких эксцессов, я дам хорошую рекомендацию. Значит ли это что такие сотрудники соответствуют требованиям на новом месте?
Если человек проработал 10 лет до этого, но решал только типовые задачи в большой команде с наличием рядом гуру, который всегда знал ответы на сложные вопросы, значит ли что он опытный?
А вот затраты на испытательный в реалиях текущих зп девопс инженеров очень даже может ударить по бюджету, если учесть все косвенные затраты - ожидание ухода с другого места, раскочегаривание нового поиска и новое ожидание выхода. Это вам не стажёра искать
В основном на наших проектах и большинстве проектов клиентов хватает окружений под фронтенд-фичи. Задачу с базами мы решали с помощью data transfer и самописных скриптов
Так что отнюдь, за скобками мы это не оставляли и даже записали курс совместно с Яндексом, в котором рассказали о том как это делать более детально
Насчет того, что нужно иметь для того чтобы это всё завелось согласен. Фича-бренчи это сейчас гигиена на уровне "использовать гит в разработке", а окружение под фичу и деплой фичи на окружение это как раз то, что нужно сделать
Насчет "стабильная версия" + "желтый фон" -- намеренно упрощенный пример для того чтобы показать, как может одна фича повлиять на другую. И да, собрать стабильную версию + новая фича это же задача на уровне создать ветку в гите и написать весь код в этой новой ветке. Поэтому исходил из того, что это все умеют. На эту часть тоже можем распространить консалтинг, учим этому джунов в нашей школе https://metaclass.kts.studio/
Насчет выделения окружения для сборки согласен, если проект состоит из тонны микросервисов или монолит прям огромный, то есть куча нюансов, которые нужно будет решить. Но в большинстве проектов такого количества нюансов нет и поэтому динамические окружения сетапятся быстро
Ну а насчет Jenkins не спорю абсолютно, на нём можно сделать кучу всего, сами его использовали до того как перешли на Gitlab, но порог вхождения сильно выше гитлаба
В итоге статья как раз о том, что поднимать среды - это не что-то супер сложное и странно что до сих пор есть компании, в которых уже есть несколько разработчиков, а этого инструмента нет
Про второй кейс скорее соглашусь, но про первый -- часы разработчиков и прочих сотрудников, задействованных в разработке в абсолютном большинстве случаев дороже, чем доп затраты на сервера для динамических окружений
Как часто фичи затрагивают сразу несколько компонентов, которые пишут разные команды? Обычно это происходит редко, потому что для этого и делят одну большую команду на несколько небольших кроссфункциональных
В обычном случае ваша задача решается очень просто и понятно -- одна команда выкатывает тестовую версию, которая "смотрит" в стейджевую версию других компонентов
А насчет баз, действительно это сложнее чем просто развернуть отдельно ветку фронта, но тестирование на больших базах каждой фичи это тоже что-то выходящее за рамки обычных фич в разработке
В целом уверен, что бывают редкие проекты, где проще тестить на одном сервере, но относительно подавляющего большинства это небольшой процент
Надо будет передать эту информацию кому следует (Оле) :)
Абсолютно!
Цитата из статьи:
Так что нагуглить быстренько или использовать свои наработки - окэй, а звонок другу, если "другом" для помощи по такой простой задаче будет разработчик, то толку от такого сотрудника будет не так много.
А если друг работает где-то в другом месте, то мы лучше друга наймем, который знает или умеет нагуглить:)
Это сколько лет нужно чтобы столько писем нападало?)
Эх, сейчас бы в 2к24 килобайты экономить:)
Леонид не HR, а руководитель DevOps юнита, он в начале статьи представился
А насчёт грейдов, то они уж точно не усложняют текущие задачи.
Они позволяют объективно сформулировать необходимые знания, навыки и ответственность, нужные на каждом уровне. Ну и от этого формируется понятная траектория развития сотрудника, а не просто "ну ты вроде норм работал, но не особо развился по ощущениям, потому без повышения в этот раз"
Звучит здраво, однако есть нюанс
По всем бывшим сотрудникам, если только не было каких-то прям жестких эксцессов, я дам хорошую рекомендацию. Значит ли это что такие сотрудники соответствуют требованиям на новом месте?
Если человек проработал 10 лет до этого, но решал только типовые задачи в большой команде с наличием рядом гуру, который всегда знал ответы на сложные вопросы, значит ли что он опытный?
А вот затраты на испытательный в реалиях текущих зп девопс инженеров очень даже может ударить по бюджету, если учесть все косвенные затраты - ожидание ухода с другого места, раскочегаривание нового поиска и новое ожидание выхода. Это вам не стажёра искать
Вот для этого и сделали такую штуку:)
Так это же собеседование, как иначе?:)
"Говоришь, что умеешь, а, ну ладно, верим на слово!"?
Лучше поздно, чем никогда!:)
:)
На эту тему у нас есть отдельная статья:) https://habr.com/ru/companies/kts/articles/767224/
В основном на наших проектах и большинстве проектов клиентов хватает окружений под фронтенд-фичи. Задачу с базами мы решали с помощью data transfer и самописных скриптов
Так что отнюдь, за скобками мы это не оставляли и даже записали курс совместно с Яндексом, в котором рассказали о том как это делать более детально
Насчет того, что нужно иметь для того чтобы это всё завелось согласен. Фича-бренчи это сейчас гигиена на уровне "использовать гит в разработке", а окружение под фичу и деплой фичи на окружение это как раз то, что нужно сделать
Насчет "стабильная версия" + "желтый фон" -- намеренно упрощенный пример для того чтобы показать, как может одна фича повлиять на другую. И да, собрать стабильную версию + новая фича это же задача на уровне создать ветку в гите и написать весь код в этой новой ветке. Поэтому исходил из того, что это все умеют. На эту часть тоже можем распространить консалтинг, учим этому джунов в нашей школе https://metaclass.kts.studio/
Насчет выделения окружения для сборки согласен, если проект состоит из тонны микросервисов или монолит прям огромный, то есть куча нюансов, которые нужно будет решить. Но в большинстве проектов такого количества нюансов нет и поэтому динамические окружения сетапятся быстро
Ну а насчет Jenkins не спорю абсолютно, на нём можно сделать кучу всего, сами его использовали до того как перешли на Gitlab, но порог вхождения сильно выше гитлаба
В итоге статья как раз о том, что поднимать среды - это не что-то супер сложное и странно что до сих пор есть компании, в которых уже есть несколько разработчиков, а этого инструмента нет
Может мы просто про разное говорим
Чтобы тестировщик смотрел фичу на своём компе, он же не должен разворачивать на своем компе полную версию сервиса?
А насчет тестового сервера - хоть 2, хоть 4 проблемы те же самые, что описаны в статье:
Фичи влияют друг на друга
Если какие-то фичи откладываются или зависают, то их надо руками отрывать с тестового стенда и не забыть еще это сделать до того как всё разломается
Про второй кейс скорее соглашусь, но про первый -- часы разработчиков и прочих сотрудников, задействованных в разработке в абсолютном большинстве случаев дороже, чем доп затраты на сервера для динамических окружений
Мощности же постоянно дешевеют
вы всерьез рассматриваете вариант, в котором тестировщики и менеджеры смотрят фичу на компе разработчика?:)
Это хорошая возможность для какого-нибудь пет проекта, но для продакшна это ж моветон
Как часто фичи затрагивают сразу несколько компонентов, которые пишут разные команды? Обычно это происходит редко, потому что для этого и делят одну большую команду на несколько небольших кроссфункциональных
В обычном случае ваша задача решается очень просто и понятно -- одна команда выкатывает тестовую версию, которая "смотрит" в стейджевую версию других компонентов
А насчет баз, действительно это сложнее чем просто развернуть отдельно ветку фронта, но тестирование на больших базах каждой фичи это тоже что-то выходящее за рамки обычных фич в разработке
В целом уверен, что бывают редкие проекты, где проще тестить на одном сервере, но относительно подавляющего большинства это небольшой процент
По ссылке будет развернутый на сервере проект
Отличное название, возьмем на вооружение:)