Быстрый старт в сборке метрик по билдам в android-проекте

Привет, Хабр! Меня зовут Андрей, я новый Android-разработчик в команде онлайн-кинотеатра PREMIER.

Когда я только пришел на работу в проект, мне поставили задачу внедрить измерение билдов для того, чтобы видеть, как с течением времени у нас меняется время сборки проекта на разных билд-машинах.

Решение задачи

После проведенного анализа я выявил два варианта решения

Использовать gradle enterprise
Написать скрипты для gradle для сборки и отправки метрик

Первый вариант нам не подходит, потому что он платный;

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

Так как оба варианта не подошли я начал искать альтернативное решение, которое не требовало бы много времени на написание скриптов и больших вложений. После n-го времени, проведенного в гугле и на гитхабе, нашелся один вариант, который удовлетворял запросы – это Talaiot.

Немного о talaoit:
Talaiot – внешняя библиотека для gradle проектов, которая измеряет и записывает время билдов/тасок в бд. В дальнейшем эта информация помогает выявлять проблемы перфоманса тех или иных фич в проекте.

Библиотека поддерживает как локальный отчеты в формате json и визуализацию в виде картинок, так и отправку отчетов в базу данных, - расположенную на сервере. Единственный минус – это ограниченный выбор баз данных для хранения данных о сборках, в основном это time-series databases, но скорее это обусловлено работой самого talaiot.

Технологический стек:

Docker-compose
Grafana
InfluxDB
InfluxCLI
Talaiot

Подготовка:

Начнем с того, что нам необходимо установить docker-compose на котором мы будет разворачивать наши контейнеры с influx-db и grafana.
Создаем папку, в которой создаем файл docker-compose.yml с описанными контейнерами.

Eсли вы более продвинутый юзер в использовании докера, никто не запрещает описать докер файл со скриптом запуска, как это сделано в примере talaiot’a на гитхабе в папке docker .

docker-compose.yml:

version: "1"

services:
influxdb:
image: influxdb:1.8.10
container_name: influx_db
environment:
- INFLUXDB_HTTP_AUTH_ENABLED=TRUE
- INFLUXDB_DB=metricsDB // название базы данных
- INFLUXDB_ADMIN_USER=admin
- INFLUXDB_ADMIN_PASSWORD=adminpass
- INFLUXDB_WRITE_USER=influxUser
- INFLUXDB_WRITE_USER_PASSWORD=influxPass
- INFLUXDB_READ_USER=grafanaUser
- INFLUXDB_READ_USER_PASSWORD=grafanaPass
- INFLUXDB_META_DIR=/var/lib/influxdb/meta
ports:
- "8086:8086"

grafana:
image: grafana/grafana-enterprise
volumes:
- grafana-storage:/var/lib/grafana:rw
depends_on:
- influxdb
ports:
- "3000:3000"

volumes:
grafana-storage:

Я создал дополнительно двух юзеров с разными правами: один записывает данные в нашу бд-шку и используется в проекте для talaiot, второй используетя графаной для чтения данных. Так-же можете можете указать параметр для каждого сервера restart: unless_stopped – это позволит контейнерам подняться самостоятельно, если удаленный сервер будет перезапущен. Сохраняем файл и закрываем его.

Далее нам нужно поднять наши контейнеры. Открываем терминал в нашей папке и пишем заветную команду docker compose up -d и….. вуаля – у нас развернуты influx-db и grafana.

Работоспособность последнего можно проверить, перейдя по ссылке [ссылка-удаленного-или-локального-сервера]:3000, например: localhost:3000 (юзер и пароль для админки графаны по-дефолту: admin).

Influx-DB:

Для работы с моей версией influx-db необходимо поставить influx-cli (ссылки сверху). После установки пишем команду:

sudo docker exec -it influx_db /bin/bash и после вводим influx, если мы все сделали правильно, терминал должен показать сообщение:

Теперь авторизируемся под админом в нашей базе данных, вводим следующие команды и данные, которые мы указали в docker-compose.yml

Теперь необходимо создать retention policy, которая будет хранить данные n-ое время, я выберу срок хранения год (подробнее про retention policy можете почитать тут)

CREATE RETENTION POLICY rpTalaiot ON metricsDB DURATION 52w REPLICATION 1

GRAFANA:

Вернемся к графане, после того, как мы авторизовались, нам необходимо связать графану и базу данных – для этого в боковом меню выбираем раздел connections -> connect data

В поисковой строке ищем influx и выбираем influxDb

В появившимся окне нажимаем по кнопке ‘create a influxDb data source’.

Открывается окно, которое заполняем так же, как у меня на скрине, url - будет ваш локальный/удаленный url сервера, либо url докера, как в моем случае. Данные юзера берете, которые указали в docker-compose.yml.

Об успешности испытаний нам скажет графана:

Мы почти на финише, осталось только настроить проект….

Работа с проектом:

Для начала нам необходимо добавить в проект зависимости talaiot, согласно документации.

В своем примере я делаю отдельный build script для talaiot, чтобы, по возможности, можно было подключать в разные проекты.

build.gradle (project) ->

plugins {
id "io.github.cdsap.talaiot" version "1.5.3"
}
apply from: "$rootDir/talaiot.gradle"

Синкаем проект и описываем скрипт согласно примеру из гита

talaior.gradle ->

talaiot {
publishers {
influxDbPublisher {
dbName = "metricsDB"
url = http://localhost:8086

taskMetricName = "task"
buildMetricName = "build"
username = "influxUser"
password = "influxPass"
}
}

filter {
build {
success = true
// disable collect sync gradle time
requestedTasks {
excludes = ['runCommonizer','prepareKotlinIdeaImport',

'prepareKotlinBuildScriptModel', 'clean']
}
}
}

metrics {
gitMetrics = false
customBuildMetrics([buildMachine: buildMachine()])
}
}

А теперь вкратце объясню, что тут за что отвечает.

В publishers мы должны выбрать паблишер. Название поддерживаемой базы данных соответствует названию паблишера, у меня это influxDbPublisher.

dbName - название базы данных, которая будет создана в инфлюксе;

url – url удаленного или локально сервера (может быть localhost или 192.168.1.8);

task и build-metricNames – я оставил без изменений;

username и password – те что указаны в docker-compose.yml для инфлюкса.

В talaiot есть возможность отбрасывать ненужные таски, чтобы исключить их замеры. Помимо замера данных, talaiot тригерит функции гита для получения названия ветки, в которой вы работаете. Т.к. у нас есть удаленные сборщики проектов по типу миракла, там гит отсутствует, поэтому мы отключили возможность использовать сбор гит-информации. Также можно указывать свои дополнительные поля для метрик, которые будут содержать информацию, необходимую вам, для нас это модель процессора.

Для получения модели процессора был написан несложный код, который выполняется в командной строке и отбрасывает ненужную информацию необходимую вам, оставляя только семейство процессора:

static def buildMachine() {

def systems = [
macos : new MacHardware(),
linux : new LinuxHardware(),
windows: new WinHardware()
]

OperatingSystem os = DefaultNativePlatform.currentOperatingSystem
BaseHardware hardwareSpec = systems[os.toFamilyName()]

if (hardwareSpec != null) {
return hardwareSpec.getBuildMachineName()
} else {
return "OS Family Unknown"
}

}

abstract class BaseHardware {
protected static String UNKNOWN_PROCESS = "Unknown process"
protected abstract String getBuildMachineInformation()

String getBuildMachineName() {
try {
return parsingMachineInformation(executeProcessAndGetResult())
} catch (Throwable throwable) {
throwable.printStackTrace()
return UNKNOWN_PROCESS
}
}

protected abstract String parsingMachineInformation(String machineInformation)

protected String executeProcessAndGetResult() {
ByteArrayOutputStream output = new ByteArrayOutputStream()
ByteArrayOutputStream error = new ByteArrayOutputStream()

Process process = getBuildMachineInformation().execute()
process.consumeProcessOutput(output, error)
process.waitForOrKill(5000)

if (error.size() > 0) {
throw new UnknownError("Cannot execute process ${error.toString()}")
}
return output.toString()
}

}
}

class MacHardware extends BaseHardware {

@Override
protected String getBuildMachineInformation() {
return "sysctl -n machdep.cpu.brand_string"
}

@Override
protected String parsingMachineInformation(String machineInformation) {
return machineInformation.trim()
}
}

class WinHardware extends BaseHardware {

@Override
protected String getBuildMachineInformation() {
return "wmic CPU get NAME"
}

@Override
protected String parsingMachineInformation(String machineInformation) {
return machineInformation
.substring(4)
.trim()
}

}

class LinuxHardware extends BaseHardware {

@Override
protected String getBuildMachineInformation() {
return "lscpu"
}

@Override
protected String parsingMachineInformation(String machineInformation) {
int startIndex = machineInformation.indexOf("Model name:") + "Model name:".length()

int lastIndex = machineInformation.indexOf('\n', startIndex)
return machineInformation.substring(startIndex, lastIndex).trim()
}
}

А, чуть не забыл, для дашборда графаны можно взять готовый sample из нашего примера и импортировать его в вашу графану. Теперь все готово к употреблению! Делаем несколько сборок проекта и проверяем результат в графане.

Итог

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

Полный пример кода для android-проекта можете посмотреть в нашем примере.

P.S. Это мой первый опыт работы с докером, поэтому если Вы хотите поделиться своей идеей по оптимизации скриптов для докера - буду рад вашим комментариям!

Источник: https://habr.com/ru/companies/gazprommedia/articles/773192/

Вернуться к списку

Интересные статьи

Прокси-метрики в E-commerce. Часть 1

В данной статье, состоящей из трёх частей, мы поделимся нашим исследованием о метриках, на которые стоит ориентироваться для увеличения долгосрочной выручки онлайн-магазина.

Улучшая движения роботов. Как стартап из MIT автоматизирует маркетплейсы

Роботы, как и предсказывали футуристы, пришли за монотонной работой. В этот раз — за работой складских сортировщиков. Поскольку из-за пандемии все научились пользоваться ...

Перевод Курса по стартапам и бизнесу от Стэнфордского Университета. Лекция №4. Создание продукта, общение с клиентами…

В этой небольшой статье я хочу кратко описать содержимое лекции №4 - Создание продукта, общение с клиентами и рост стартапа из курса по стартапам и бизнесу от Стэнфордско...

Советы по продажам для технических стартапов

Кэрол занимается развитием бизнеса компании Leadfeeder в США. Она обладает суммарно более чем 10 годами опыта в маркетинге, продажах и развитии бизнеса. Вы можете создать лучший на все...

А не фигню ли я опять делаю? Как и зачем внедрять метрики качества

Привет, Хабр! Когда-то мы использовали метрику «Вроде бы стало лучше» для оценки качества наших релизов. Но потом мы решили довериться чему-то более надёжному. В этой статье я расскажу о том, как...