Насколько нам известно, ORBOX используют не только телекомпании и стриминги, но и производители контента. У разработчика ПО есть кейсы с продакшенами, которые проверяют материалы перед отправкой заказчику (в том числе с помощью онлайн-сервиса ORBOX Online). На постоянной основе производители контента и пост-продакшен студии тоже используют ORBOX для проверки контента на входе и на выходе. Можете написать нашим коллегам из Текома, они наверняка будут рады обсудить это подробнее.
Если говорить про возможности QC-систем, в целом они могут обнаружить липсинк. Некоторые из них с помощью сочетания нейронных сетей и машинного обучения анализируют видео и выявляют моменты, когда звук и движение губ не совпадают.
Это не опечатка, а скорее привычка. Я употреблял фразу «увеличивать ТТМ» подразумевая «увеличивать эффективность показателя», увеличение количества доставок в продакшен и тд. И конечно это подразумевает уменьшение самой метрики. Мы не увеличиваем время доставки, а наоборот уменьшаем.
stored процедур у нас архитектурно нет. Миграции разрабатываются с учётом обратной совместимости и на стендах это достаточно легко ловится.
С учетом этого миграции на прод в 90% случаях проходят без проблем. Если по каким-то причинам мы понимаем, что совместимости нет и миграция в один конец - то планирование релиза в ненагруженное время с деградацией. Но с учетом микросервисов если влияние и бывает, то только на часть функционала.
По интеграции - да есть интеграции jira и gitlab. К задаче прилинковываются MR и видно кто что делал. При создании релиза в gitlab там указываются связанные jira задачи и дальше по кнопкам создаются релизные задачи где это все линкуется, а по закрытию - закрывается задача и делается нотификации (об этом я писал выше в статье)
Такие проблемы есть, хоть и редки (тут никуда не деться, когда среды общие). На память приходит проблема, когда для одной задачи нужно короткое время жизни токена, а для другой подольше. Но, учитывая что по версионированию в гите видно кто вносил изменения такое решается горизонтально.
Что касается фича стендов, то они у нас есть. В рамках этой статьи не стали про них писать, ибо там тоже есть о чем рассказать). Мы используем https://www.rancher.com/ для этого и поднимаем стенд, если видим, что задача долгая или по запросу команд.
По стендам у нас еще действует следующие договоренности: на стейдже мы тестируем фичу и только. Стенд может быть нестабильным и туда может вливаться много задач. Конфликты решаются горизонтально в командах.
На препрод проводятся интеграционные тесты и если нужно какие то автотесты. После тестов уже идет релиз конкретной оттестированной задачи на препроде в прод с прохождением обязательных автотестов.
Проблем с sealed secrets не было от слова совсем, а vault нам пока так и не пригодился. Если мы решим внедрять vault, то думаю и секреты переведем в него тоже
Насколько нам известно, ORBOX используют не только телекомпании и стриминги, но и производители контента. У разработчика ПО есть кейсы с продакшенами, которые проверяют материалы перед отправкой заказчику (в том числе с помощью онлайн-сервиса ORBOX Online). На постоянной основе производители контента и пост-продакшен студии тоже используют ORBOX для проверки контента на входе и на выходе. Можете написать нашим коллегам из Текома, они наверняка будут рады обсудить это подробнее.
Если говорить про возможности QC-систем, в целом они могут обнаружить липсинк. Некоторые из них с помощью сочетания нейронных сетей и машинного обучения анализируют видео и выявляют моменты, когда звук и движение губ не совпадают.
Это не опечатка, а скорее привычка. Я употреблял фразу «увеличивать ТТМ» подразумевая «увеличивать эффективность показателя», увеличение количества доставок в продакшен и тд. И конечно это подразумевает уменьшение самой метрики. Мы не увеличиваем время доставки, а наоборот уменьшаем.
Точную версию не вспомню, но это 2020 год, возможно даже с одних из первых версий используем :)
helmwave.yml.tpl
---
version: 0.25.0
project: {{ env "APP_NAME" }}
releases:
- name: {{ env "RELEASE_NAME" }}
namespace: {{ env "NAMESPACE" }}
environment: {{ env "CI_ENVIRONMENT_NAME" }}
chart:
name: ./chart
atomic: true
maxhistory: 10
resetvalues: true
wait: true
timeout: 360s
values:
- ./chart/values.yaml
- ./chart/values-common.yaml
- ../{{ env "APP_NAME" }}/helm/values-base.yaml
- ../{{ env "APP_NAME" }}/helm/{{ env "VALUES_FILE" }}
- ../special-project/helm/{{ env "VALUES_FILE" }}
recreate: false
По комментариям спасибо, учтем.
stored процедур у нас архитектурно нет. Миграции разрабатываются с учётом обратной совместимости и на стендах это достаточно легко ловится.
С учетом этого миграции на прод в 90% случаях проходят без проблем. Если по каким-то причинам мы понимаем, что совместимости нет и миграция в один конец - то планирование релиза в ненагруженное время с деградацией. Но с учетом микросервисов если влияние и бывает, то только на часть функционала.
По интеграции - да есть интеграции jira и gitlab. К задаче прилинковываются MR и видно кто что делал. При создании релиза в gitlab там указываются связанные jira задачи и дальше по кнопкам создаются релизные задачи где это все линкуется, а по закрытию - закрывается задача и делается нотификации (об этом я писал выше в статье)
Такие проблемы есть, хоть и редки (тут никуда не деться, когда среды общие). На память приходит проблема, когда для одной задачи нужно короткое время жизни токена, а для другой подольше. Но, учитывая что по версионированию в гите видно кто вносил изменения такое решается горизонтально.
Что касается фича стендов, то они у нас есть. В рамках этой статьи не стали про них писать, ибо там тоже есть о чем рассказать). Мы используем https://www.rancher.com/ для этого и поднимаем стенд, если видим, что задача долгая или по запросу команд.
По стендам у нас еще действует следующие договоренности: на стейдже мы тестируем фичу и только. Стенд может быть нестабильным и туда может вливаться много задач. Конфликты решаются горизонтально в командах.
На препрод проводятся интеграционные тесты и если нужно какие то автотесты. После тестов уже идет релиз конкретной оттестированной задачи на препроде в прод с прохождением обязательных автотестов.
Рассматривали конечно, но в итоге решили, что на тот момент для нас это избыточно и остановились на https://github.com/bitnami-labs/sealed-secrets
Проблем с sealed secrets не было от слова совсем, а vault нам пока так и не пригодился. Если мы решим внедрять vault, то думаю и секреты переведем в него тоже