• Infrastructure as Code: как побороть проблемы с помощью XP
    0

    Получается хорошо юнит-тестировать при использовании высокоуровневых языков. И та часть инфраструктуры, которая сервисы имеет такие тесты. Но большая часть есть конфигурация или ее разновидности(DSL, templaters), а это не удается проверить качественно тестами. Мы не особо пробовали, но выглядит как много работы при малом выхлопе.
    Например, нам надо иметь кол на jsonnet, который генерит терраформ-конфигурацию. Это для поддержки параметров и множества окружений. Там поднимается машинка, в ней при старте выполняется скрипт, который подтягивает скрипты инициализации(скрипт протестирован). И еще при старте начинают работать демоны на машине.
    Вот это все проверяется поднятием реального ресурса. Т.е. это интеграционный тест.

  • Infrastructure as Code: как побороть проблемы с помощью XP
    0

    Спасибо. Но отчаяния-то и нет. То, что описано выше работает и помогает. А дальше только пробовать еще и еще

  • Infrastructure as Code: первое знакомство
    +1
    Изначально в группу обучения вступили все равно те разработчики, кто занимался близкой тематикой последнее время. К примеру я до этого 2 года занимался так или иначе техническими задачами, а они непременно связаны. Остальные примерно так же.
    Еще участие добровольное и те, кто не захотят остаться в инфраструктуре могут выйти.
    Плюс прорекламирую непосредственно доклад на эту тему еще от одного члена команды. devopsconf.io/moscow/2019/abstracts/5575
  • Infrastructure as Code: первое знакомство
    0
    Спасибо! В итоге мы стали писать тесты, поднимающие отдельный терраформ модуль, проверяющие, что там все поднялось корректно и все данные на машине прошли. Мы стали использовать питон, т.к. на нем пишутся скрипты-склейки, так что он уже был в части инфраструктуры.
    И пока полет нормальный. Вот что прям не вызывает проблем — так это тесты на питоне и сам питон
  • Infrastructure as Code: первое знакомство
    0
    Я еще пойму, что риски работы в России накладывают определенные ограничения

    Такой риск существует и это одна из причин.
    Также, как я уже говорил, часть функций находится в других облаках. Например, на google functions у нас бот для ScaleFT или бот, создающий карточки при инциденте.
    Еще один риск — это ценовая политика. Деньги в клауде могут улететь очень быстро, а цены могут отличаться в разы.
  • Infrastructure as Code: первое знакомство
    0
    т.е. непосредственно тебе идут оповещения от системы мониторинга?

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

    Разработчик в команде инфраструктуры должен дежурить, быть на пейджере. Есть расписание, есть процесс дневных вечерних дежурств. Кстати, можно было бы и рассказать про то, как это подробно работает.
    Обычные разработчики не дежурят(за исключением некоторых праздников).
  • Infrastructure as Code: первое знакомство
    0
    Тут скорее про то, что вот есть разработчики(мы) и нас надо подготовить к дежурствам в инфраструктуре, в которых мы не знаем как вести себя, не обладаем изначально нужными знаниями.
    При дежурствах ты становишься уже первой линией, должен первым реагировать на инциденты и если необходимо, то уже подключать аналитиков или непосредственно разработчиков, которые и ответственны за сервис.
  • Infrastructure as Code: первое знакомство
    0
    Мы изначально выбирали именно решение с возможностью работы с несколькими cloud providers. Есть у нас сервисы не только в ажуре, причем в основном именно наши, инфраструктурные.
    Про поддержку плагинов — мы частично используем плагин от Jetbrains и соответственно Rider.