Как стать автором
Обновить
12
0
Александр @yaak

DevOps

Отправить сообщение

Статья отдает подростковым максимализмом. Причем прям все тезисы. Нотя верю, что практически все так рассуждают на определенном этапе.

Да, все именно так. Причем отращивание синьорити в UK — это не только технический челлендж. Точнее практически совсем не технический))))))

Наверное нет смысла говорить про средние зарплаты. Понятно, что средний уровень там выше. Только специалисты среднего уровня там особо и не нужны. Если вы хотите цифр, то крепкий синьор в столицах будет получать 250+. В Берлине… подозреваю, что 50-70к в год гросс. Разница в стоимости жизни можете посмотреть на numbeo.

Не знаю насчет Иннополиса, но в столицах вполне себе зарплаты по европейским меркам. Не знаю вашего опыта, но утекать мозгом в другие страны — это очень даже тяжело. И далеко не всегда оправданно.

Сначала прочитал Иллинойс… понятно, зачем иннополис нужен весьма специфическим ит-компаниям. Но зачем молодым людям ехать в шляпу с тремя улицами, одним баром и столовой??? Чтобы получить удостоверение-сертификат?))))

Просмотрел, спасибо
Не сталкивался с подобным. Можете рассказать подробнее? По идее он в каждой итерации берет по одному инстансу и делает spot-клон. В каких случаях происходит перекос?
И да и нет. У AWS на первый взгляд высокий ценовой порог вхождения. Я пытался показать, что путем нехитрых манипуляций можно снизить стоимость большинства задач, в том числе с достаточно архаичными подходами. А это будет мостиком к интеграции в облако и перехода к devops-практике.
Если ваш бизнес связан с ERM, то это будет прям идеальный кейс. Напишите статью, было бы здорово познакомиться с практической частью.
Это же старая как мир история. Бизнесу проще нанять нового человека на те деньги, что вы хотите или даже большие. Или даже, сюрприз-сюрприз, нанять двух людей на те же большие деньги вместо вас. И повышение должности/зарплаты зачастую проще получить во время очередного возвращения на работу. В больших компаниях люди каруселью ходят с места на место выбивая улучшения.
У работника и у работодателя диметрально противоположные ценности и задачи. Я как работник, хочу много денег и развития или же нифига не делать и ходить в красивом костюме по европейским командировкам за большие деньги. Работодатель хочет минимизировать риски и накладные расходы. Отсюда и начинается лицемерная игра с HR-хитростями. А потом у людей начинается аллергия на «динамичные проекты с увлекательными задачами и возможностью внести свой вклад». Относитесь к работникам как к партнерам, которые пришли в офис ровно затем же, зачем и вы — заработать, получить, посозидать и развиться.
github.com/joeyh/github-backup — да, но в limitations написано, что github-backup does not log into GitHub, so it cannot backup private repositories. Плюс оно, как пишет автор, repository-focused. Другими словами надо опять же откуда-то вначале получить список репо.
Использовать гитлаб или облачные решения — это вопрос. Причем не всегда только технический.
Да, в бб есть OAuth, можно использовать его в запросе, это лучше. Использование git clone — это уже специфика того, что для бэкапа используется динамическая машина, которая благополучно умирает после выполнения задачи. В случае persistent-хоста — ваше решение лучше.
В вашем решении есть две проблемы:
  1. git pull не бэкапит репозиторий, есть ощущение, что вы не совсем понимаете суть этой команды. То же самое с использованием вами git clone
  2. Ваше решение в целом короткое и элегантное. Правда оно плодит ручные операции(уведомить о создании репо, что-то склонировать), которых я стараюсь избегать

В общем да, тут лежит пример
Можете пояснить свое первую мысль?
1) Что надо сделать, чтобы уведомить вашу систему бэкапа о добавлении новых репозиториев?
2) Что делает ваша команда git pull? что-то мне подсказывает, что мерджит текущую ветку с ориджином. Как быть с остальными?
История в начале — иллюстрация достаточно специфичной, скучной и запутанной ситуации, итогом которой были вышеозначенные проблемы. Вообще, если она действительно вас заинтересовала, то причиной всех этих синхронизаций был переезд проекта от одной компании к другой. Соответственно, подобный механизм синхронизации был выбран для минимизации простоя. «Домашний репо» — сервис внутри компании, из которой осуществлялся переезд. Очевидная для вас мысль о необходимости бэкапа гита не является очевидной для многих проектов.
Полезная статья! Скажите, а почему вы предпочитаете именно MariaDB? Сильно ли повлияет на производительность подобных решений использование Mysql?
Отличная статья. А можете пояснить, каким образом в узле может закончиться место? Есть какие-то ограничения постгреса на размер узла?
1

Информация

В рейтинге
Не участвует
Откуда
Санкт-Петербург, Санкт-Петербург и область, Россия
Дата рождения
Зарегистрирован
Активность