Пост в корп. блоге, какой бы он ни был тупой или неразвлекающий, все равно не приведет к падению рейтинга компании/блокировке аккаунта, или вообще чему-то.
Как это не приведет к падению рейтинга? Рейтинг компании зависит от рейтинга последних публикаций. Более того, я даже видел, как одна компания прятала свой пост после того, как его начали минусовать — очевидно, чтобы он не упал ещё ниже (а вместе с ним и общий рейтинг компании). Что ещё веселее, его потом обратно «опубликовали» (когда голосовать за пост, т.е. портить рейтинг компании, уже было нельзя).
Наконец, есть и более «тонкий», долгоиграющий эффект: если в блоге компании идёт постоянная ерунда, то доверие к блогу (и бренду вообще) падает. А как ещё должна страдать компания?..
Спасибо за отличный вопрос — он достоин отдельной статьи, постараемся в ближайшее время.
P.S. А сегодня как раз опубликовали про совсем свежий Jenkins X, реакция на который от одного из наших разработчиков звучит так: «Эта штука не ускорит инкрементальные билды приложения для последовательных git-коммитов — одна из главных фишек dapp».
Сравнение с примитивными скриптами всё же притянуто (то ли по незнанию, то ли по другому опыту — у нас, конечно, имеется серьёзное и масштабное применение dapp, когда «примитивные скрипты» не выглядят как… сколь-нибудь адекватный вариант), но всё равно раскройте, пожалуйста, своё видение этой «жуткости» — разработчикам будет полезно увидеть такую обратную связь
Да: когда его смотрели, было слишком сырым. Сейчас написали обзор, потому что прояснились перспективы стабилизации. Вот как эти перспективы осуществятся, так и будет смысл посмотреть ещё раз.
Во-первых, DevOps-компаний на хабре (и в России) не так много.
Во-вторых, мы пишем и свои (например — и далее по ссылкам из «P.S.»), и иногда переводим.
Да, пока только в Edge. Вот из официального анонса: «we are proud to announce that Docker for Mac with beta Kubernetes support is now publicly available as part of the Edge release channel».
В комментариях к оригинальному анонсу поддержки K8s в Docker CE для Mac/Win несколько раз спрашивали про Linux, но ответа до сих пор нет. Наверняка это где-то всё же должно было обсуждаться (с обратной связью от представителей Docker Inc), но я не встречал. В блоге Docker опять-таки анонсировали только для Mac.
Что рассматривалось из готовых CM-систем, умалчивается, но основной посыл в том, что «классические инструменты управления конфигурациями не подходят для сборки контейнеров и управления ими». Т.е. они в принципе не особо подходили под специализированные задачи (в обслуживании уже контейнеров), и такой выбор можно понять…
Вот ещё цитата по теме (из упомянутого в конце статьи case study):
The biggest impact that we had was for the deployment of new services. Before using containers, we had to first deploy a new server and create configurations with Chef. It would take sometimes a day, sometimes two, just to create a new service. And with all the tooling that we made around the containers, copying a new service is a matter of minutes. So it’s really a huge gain.
P.S. В сегодняшних вакансиях BlaBlaCar присутствует такое требование, как «Good knowledge of configuration management», но без указания каких-либо конкретных продуктов. Взял эти данные из их описания Senior Site Reliability Engineer.
P.S. Если в былые времена, в контексте по-настоящему массовых проектов (условно — популярных Linux-дистрибутивов), такие анонсы на популярных веб-ресурсах негативно сказывались на распространении их образов по зеркалам, то… здесь всё-таки не тот случай.
Потому что его задерживают — предположу, что на день или на два; такое уже случалось. А по ссылке из комментария выше (она указана и в статье) — официальный план по датам от разработчиков.
К совету выше про minikube для самого старта (устранения того самого «порога вхождения») — присоединяюсь. Мы переводили статью по быстрому старту в нём. Но перед этим полезно общую теорию по K8s почитать — об общих принципах работы, основных примитивах и т.п. Сами мы хотели такой цикл статей сообразить, но никак не получается добраться, а в зарубежном интернете подобные материалы появляются всё чаще. К слову, про самые-самые основы был хороший доклад «Наш опыт с Kubernetes в небольших проектах» (там же есть ссылка на видео); большую его часть составляет именно введение в Kubernetes.
Как это не приведет к падению рейтинга? Рейтинг компании зависит от рейтинга последних публикаций. Более того, я даже видел, как одна компания прятала свой пост после того, как его начали минусовать — очевидно, чтобы он не упал ещё ниже (а вместе с ним и общий рейтинг компании). Что ещё веселее, его потом обратно «опубликовали» (когда голосовать за пост, т.е. портить рейтинг компании, уже было нельзя).
Наконец, есть и более «тонкий», долгоиграющий эффект: если в блоге компании идёт постоянная ерунда, то доверие к блогу (и бренду вообще) падает. А как ещё должна страдать компания?..
P.S. А сегодня как раз опубликовали про совсем свежий Jenkins X, реакция на который от одного из наших разработчиков звучит так: «Эта штука не ускорит инкрементальные билды приложения для последовательных git-коммитов — одна из главных фишек dapp».
Во-вторых, мы пишем и свои (например — и далее по ссылкам из «P.S.»), и иногда переводим.
P.S. В опросе к посту на хабре сейчас 72 % ответили, что они разработчики, так что выборка уже более представительная.
Вот ещё цитата по теме (из упомянутого в конце статьи case study):
P.S. В сегодняшних вакансиях BlaBlaCar присутствует такое требование, как «Good knowledge of configuration management», но без указания каких-либо конкретных продуктов. Взял эти данные из их описания Senior Site Reliability Engineer.
P.S. Если в былые времена, в контексте по-настоящему массовых проектов (условно — популярных Linux-дистрибутивов), такие анонсы на популярных веб-ресурсах негативно сказывались на распространении их образов по зеркалам, то… здесь всё-таки не тот случай.