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