Архив метки: automation

Автоматизация инфраструктуры в GCP с Deployment Manager

deployment manager

Даже не знаю, как так получилось, но даже регулярно пересекаясь с Google Cloud Platform последние два года, я абсолютно упустил тот факт, что в GCP есть свой собственный инструмент для автоматизации развёртывания инфраструктуры: создания виртуальных машин, аккаунтов, сетей и прочего. Но он реально есть! В главном меню даже есть ссылка.
Инструмент называется Deployment Manager и он может автоматически создать практически всё, что есть Google Cloud. Прямо с одной команды. Так как DM разрабатывал Гугл, то у первого весьма извилистая кривая обучения, не всегда свежая документация, и иногда неочевидные логика. Но штука работает. Так как до этого я в основном автоматизировал развёртывание приложений от хоста и вверх — через всякие VagrantAnsibledocker-compose или kubectl, по посмотреть, как делать первую половину задачи — от хоста и вниз, — будет весьма интересно.

Читать далее Автоматизация инфраструктуры в GCP с Deployment Manager

Отправляем проактивные сообщения с Microsoft Bot Framework

Futurama восстание роботов

Я тут подумал ещё раз о том боте, который вроде как должен будет вместо меня следить за ненадёжными тестами, и внезапно понял одну штуку. Все сценарии, с которыми я игрался, были так или иначе построены на инициируемых пользователем диалогах. Тот шлёт сообщение, бот отвечает, шлёт ещё одно, бот опять отвечает, и т. п. Но в моём случае, получив задание, бот будет работать молча, и, лишь заметив что-нибудь любопытное, должен начать беседу сам. Microsoft называет такие сценарии проактивными сообщениями, и вот как это можно провернуть на Microsoft Bot Framework. Читать далее Отправляем проактивные сообщения с Microsoft Bot Framework

Разбираемся с Microsoft Bot Framework

Маленький Бендер

Так как конторский CI/CD висит на мне, то натурально я заинтересован в том, чтобы билд оставался зелёным. Не то, чтобы я тут же бросался к каждому упавшему тесту, но за ненадёжными точно присматриваю.

Когда ветка master держится красной чересчур уж долго, вот какие штуки начинают творится с её упавшими тестами:

  1. Ищем историю падений теста в нашем Google BigQuery (select Name, Result, count(*) from TestResults_...).
  2. Если исторически тест вел себя в большей степени как генератор случайных результатов, и в меньшей степени как тест, создаём для него тикет.
  3. Добавляем тест в игнор и указываем в качестве причины вновь созданный тикет.
  4. Находим, кто же написал это непотребство (git blame) и вешаем кейс на автора.

В общем, очень просто. И ещё очень скучно. Тестов-то у нас много. Я бы автоматизировал это всё, но есть одно небольшое «но» — не всегда можно определить, кто же текущий «владелец» теста. Программисты же увольняются, рефакторят чужое, ну и ломают git’овскую историю по праздникам. Я думал заморочиться и выкатить какое-нибудь machine learning решение для этого, но то попахивает перебором. А вот написать бота выглядит как-то более выполнимо. Он бы мониторил тесты, отслеживал статистику, и когда ему что-то непонятно, вроде на кого повесить кейс, спрашивал бы меня.

Осталось только понять, как этих ботов делают. Читать далее Разбираемся с Microsoft Bot Framework