QA, разработка и DevOps: кто и как доставляет качественный код до пользователя

Тестирование — важнейший этап, позволяющий убедиться в качестве кода перед передачей заказчику. Однако между моментом, когда код успешно прошел все проверки, и его появлением в среде, доступной пользователю, существует еще один значимый этап. За его организацию и эффективность отвечает DevOps.

Для того чтобы код начал работать в реальной среде, необходима инфраструктура: серверы, операционные системы, веб-серверы, базы данных, среды исполнения. А сам процесс перемещения кода от репозитория до стенда требует последовательного выполнения множества операций — компиляции, проверки уязвимостей, упаковки, развертывания.

Так, основной зоной ответственности инженеров DevOps становятся:
👉 Конфигурация среды исполнения — подготовка серверов, установка и настройка всего необходимого ПО для работы приложения.
👉 Автоматизация доставки кода — создание пайплайнов, которые самостоятельно переносят код от разработчика до стенда без ручного вмешательства.

Это означает, что разработчики продолжают работать над кодом, не отвлекаясь на настройку серверов или ручное развертывание. QA получают актуальные версии на стендах без ожидания, пока коллеги развернут им правки. Они могут самостоятельно обновлять стенды или откатываться на предыдущие версии для сравнения или более тщательной проверки.

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

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

Почему без DevOps качественный код может долго не доходить до заказчика
Без выстроенного процесса настройка серверов, установка ПО, компиляция и доставка кода ложатся на плечи разработчиков. Это отвлекает их от основной задачи, замедляет разработку и создает риски, связанные с человеческим фактором. Появление новых стендов требует повторения одних и тех же ручных операций, что увеличивает вероятность ошибок и затягивает сроки.

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

От срочных задач к прозрачной системе планирования: что такое бэклог

Задачи в проектах появляются постоянно: новые идеи, запросы пользователей, исправления ошибок, доработки проекта. Если не фиксировать их в одном месте и не расставлять приоритеты, команда работает в режиме постоянных срочных задач.

В Skillbox Media вышел материал с участием ведущего бизнес-аналитика Embedika, Эльвиры Иллензеер — о том, как навести порядок в бэклоге и выстроить прозрачную систему управления.

Разобрали на практике:
▫️ Как превратить бэклог из бесконечного списка задач в полезный инструмент, который помогает команде планировать работу и расставлять приоритеты;
▫️ Как работать с техническим долгом, чтобы он не тормозил развитие проекта;
▫️ Какие бывают виды бэклогов, чем они отличаются и для каких задач подходит каждый;
▫️ Почему бэклог нужен не только разработке, но и любым специалистам, которые работают с большим объемом задач.

🔗 Полная версия статьи доступна на сайте Skillbox Media

#сми_о_нас

Какие сложности встречаются в работе тестировщиков: 6 вызовов QA-команды

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

Собрали 6 ситуаций, с которыми регулярно сталкиваются тестировщики 👇

1️⃣ Изменение требований в процессе разработки
Одна из самых распространенных ситуаций — когда изначально описан только основной сценарий, а в ходе реализации появляются дополнительные условия и уточнения логики. В таких случаях QA необходимо пересматривать тестовые сценарии, уточнять требования и повторно проверять уже реализованную функциональность. В реальных проектах это неизбежно, поэтому важна своевременная синхронизация с аналитиками и разработчиками.

2️⃣ Сложность воспроизведения дефектов
Иногда пользователи или коллеги сообщают о проблеме, которую сложно воспроизвести. Часто такие ошибки возникают при определенных условиях:
🔷 использование конкретного браузера, устройства или операционной системы;
🔷 редкая последовательность действий;
🔷 высокая нагрузка на систему;
🔷 взаимодействие с внешними сервисами.
В подобных ситуациях тестировщик анализирует логи, проверяет различные сценарии и последовательно выявляет комбинацию условий, при которой возникает ошибка.

3️⃣ Дефекты, которые проявляются только в продакшене
Иногда система работает стабильно на тестовых стендах, но даёт сбой в рабочей среде. Причины могут быть разными: отличия в конфигурации среды, особенности реальных пользовательских данных, высокая нагрузка или поведение внешних сервисов. В таких ситуациях QA помогает проанализировать ситуацию и воспроизвести проблему в тестовой среде для ее дальнейшего устранения.

4️⃣ Давление сроков перед релизом
По мере приближения релиза сроки тестирования часто сокращаются: разработчики завершают реализацию функциональности, и у команды остается ограниченное время на проверку. В этих условиях тестировщики оперативно расставляют приоритеты, концентрируются на критичных сценариях и оценивают риски, связанные с выпуском функциональности.

5️⃣ «Спорные» дефекты
Иногда сложно определить, является ли обнаруженное поведение системы дефектом или допустимой логикой. Такое случается, когда в требованиях отсутствует явное описание сценария, участники команды по-разному интерпретируют поведение системы или пользовательский сценарий не был учтен на этапе анализа. В таких случаях дефект обсуждают внутри команды — с аналитиками, разработчиками и, при необходимости, с заказчиком.

6️⃣ Большие цепочки зависимостей
В сложных системах одна функция может зависеть сразу от нескольких сервисов или модулей. Если на одном из этапов передачи и обработки данных возникает сбой, тестировщику необходимо определить точное место его возникновения. Это требует анализа логов, проверки API и взаимодействия с несколькими командами разработки.

Сложные ситуации позволяют раскрыть основную ценность тестирования. Задачи QA выходят за рамки поиска дефектов: это понимание поведения системы в реальных условиях и поддержка команды в поиске наиболее надежных решений.

Как DevOps обеспечивает стабильность инфраструктуры: кластеры, мониторинг и облака

После доставки кода и запуска приложения основная задача – обеспечить его стабильную работу. Отказоустойчивость инфраструктуры напрямую влияет на стабильность бизнес-процессов и удовлетворенность заказчиков. Добиться этого можно за счет комплекса инструментов и подходов, среди которых — кластеры, мониторинг и облачные решения.
 
Кластеры: как управлять устойчивостью системы к сбоям
Если приложение работает на одном сервере, рано или поздно оно выйдет из строя — это вопрос времени. Для таких ситуаций есть решение — кластер, группа серверов, объединенных в единую систему и работающих как один. При отказе одного из них нагрузка автоматически перераспределяется на остальные, и сервис продолжает работать.

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

Мониторинг: как вовремя заметить проблему
Когда серверов и сервисов становится много, уследить за всем вручную уже невозможно — нужны системы, которые сами предупредят о проблеме. В нашей практике для этого используется связка Prometheus, Grafana и Alert Manager.  

🔷 Prometheus собирает метрики с серверов и сервисов — загрузку CPU, память, количество запросов, ошибки и другие значимые показатели. 
🔷 Grafana визуализирует данные в графиках и дашбордах, позволяя быстро оценить состояние системы. 
🔷 Alert Manager настраивает правила оповещения: если метрика вышла за пределы нормы, команда получает уведомление.  

Для работы с логами используется централизованный сбор через Grafana Loki и Elastic Stack. Это позволяет быстро фильтровать события и находить причину сбоя без ручного анализа логов на каждом сервере.

Облачные сервера: как сократить нагрузку на команду в два раза
До перехода на облачные решения инфраструктура базировалась на арендованных железных серверах, а их администрирование отнимало до 50% времени DevOps-команды.

Переход на облачную платформу Yandex Cloud позволил изменить подход. Kubernetes используется как управляемый сервис: за его надежность и работоспособность отвечает провайдер, специалисты работают только с функционалом. Такая схема освобождает команду от системного администрирования сервисов и позволяет перераспределить ресурсы: теперь DevOps тратят на поддержку инфраструктуры лишь 20% времени, тогда как 80% уходит на проектные задачи.

Три компонента отказоустойчивости системы
Надежность инфраструктуры достигается не за счет случайных факторов, а благодаря выстроенным процессам и применяемым инструментам: 
🔷 Кластеры обеспечивают непрерывность работы сервиса даже при отказе отдельных серверов;
🔷 Мониторинг и сбор логов позволяют выявлять проблемы до того, как их заметит заказчик;
🔷 Облачные сервисы избавляют команду от рутины, освобождая время для проектной работы.

DevOps-команда Embedika проектирует инфраструктуру таким образом, чтобы разработчики могли сосредоточиться на создании функциональности, тестировщики — на обеспечении качества, а заказчики — получать стабильный результат.

Искусственный Интеллект (дайджест): всё об ИИ и нейросетях 

Хотим порекомендовать канал наших коллег — Искусственный Интеллект (дайджест). В канале собрано самое важное про ИИ: от исследований крупнейших технологических компаний до прикладных инструментов для продаж, дизайна и контента. 

Основные направления:

◻️ Аналитика и законопроекты: разбор регулирования западных ИИ-сервисов, переход на отечественные нейросети и изменения на рынке технологий.

◻️ Практические гайды и промпты: инструкции для генерации портретов, техники объединения разных нейросетей, приёмы для создания эстетичных изображений и анимации.

◻️ Обзоры релизов и кейсов: запуски новых версий моделей с улучшенным качеством, истории применения ИИ в медицине и других сферах.

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

Будьте в курсе главного об ИИ — присоединяйтесь к каналу Искусственный Интеллект (дайджест) и повышайте уровень экспертизы в работе с нейросетями.

Госсектор и бизнес: как выстраивать эффективную коммуникацию

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

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

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

Особенности взаимодействия:
🔷 Все договоренности и изменения фиксируются письменно через официальные каналы или СЭД, любое принятое решение должно остаться в протоколе;
🔷 В госпроектах согласование любых изменений проходит длительный путь до центра принятия решений;
🔷 Отклонения от сроков реализации крайне нежелательны и влекут за собой санкции, должны иметь веские основания и обосновываться документально;
🔷 Часто в проекте участвуют две стороны: функциональный заказчик (кому нужна система) и технический (кто отвечает за архитектуру и стандарты). Умение найти компромисс в этой ситуации — ключевой навык команды.

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

Особенности взаимодействия:
🔷 Ключевые решения могут приниматься быстрее, так как центр принятия решений со стороны заказчика находится ближе;
🔷 Корректировка сроков или состава работ проходит более гибко в сравнении с госсектором, но и здесь существуют необходимые формальные процедуры;
🔷 В отличие от госсектора, где задача чаще всего очерчена рамками ТЗ, коммерческий заказчик не всегда приходит с конкретными требованиями к системе. Здесь важна роль вендора при выявлении потребности в решении и поиске технологического решения;
🔷 коммуникация проходит менее формально, однако официальные письма и работа с документацией по-прежнему присутствует.

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

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

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

Как DevOps-команда адаптирует решения под инфраструктуру заказчика

В реальных проектах набор инструментов, с которым работают DevOps-инженеры не всегда доступны из-за ограничений со стороны заказчика, а также со стороны регуляторов. Он определяет допустимые технологии, выдвигает требования или настаивает на развертывании на своих серверах с особыми условиями. За каждым таким ограничением стоят объективные причины: политика безопасности, регуляторные нормы или внутренние стандарты.

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

📍 Почему возникают ограничения?
У заказчика могут быть свои требования к инфраструктуре и инструментам:
🔷 утвержденный список разрешенного ПО;
🔷 собственные системы контроля и управления;
🔷 закрытая инфраструктура, в которой данные хранятся только на серверах заказчика;
🔷 ограничение доступа к публичным репозиториям и хранилищам артефактов.

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

📍 Как подстроиться под инфраструктуру заказчика?
Процесс адаптации начинается с этапа оценки, когда допустимые инструменты и подходы определяются заблаговременно. Можно выделить несколько ключевых подходов:

🔷 Замена инструментов. Если нельзя использовать привычные решения, разворачивается то, что разрешено. В случае, когда у заказчика своя система — пайплайны пишутся под неё.
🔷 Настройка безопасности. Усиливается сканирование образов, добавляются дополнительные проверки, если этого требует заказчик.
🔷 Адаптация процессов. Меняется подход к доставке кода в том случае, если заказчик требует ручных согласований или не позволяет автоматизировать часть этапов.

📍 Развертывание в инфраструктуре заказчика
В ряде проектов заказчик отказывается от использования облачных решений и требует развернуть систему на собственных серверах в своем центре обработки данных. В такой ситуации DevOps-инженеры:

🔷 подготавливают инфраструктуру или согласовывают требования к ней;
🔷 разрабатывают инструкции по развертыванию и настройке всех компонентов;
🔷 выезжают на площадку заказчика, если это необходимо при запуске системы.

Также возможен сценарий, при котором доступ к продуктивному контуру у команды DevOps отсутствует полностью. В этом случае инженеры пишут подробную инструкцию, а развертывание выполняют специалисты заказчика.

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

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

Подборка полезных и интересных материалов 

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

Статьи: 
📎 «Ведомости» сравнили подходы к регулированию ИИ в России и Казахстане и разобрали, чем отличаются стратегии двух стран. 
📎 «РБК Тренды» с экспертами «ОБИТ»: почему поэтапная реализация ИТ-проектов снижает затраты на 15-20%. 
📎 Статья «Коммерсантъ», в которой исследователь AIRI рассказывает о памяти ИИ: модели не умеют переводить кратковременную память в долговременную, что мешает им непрерывно обучаться.

Заметки в блогах: 
✍️ Заметка на Habr о том, как синтетические данные помогают обучать ИИ, и где начинается граница между эффективным обучением и деградацией модели. 
✍️ Материал на vc.ru об исследовании Apple: почему LLM подбирают паттерны, а не мыслят логически.

Книги:
📚 «Совместный интеллект. Жизнь и работа с ИИ», Итан Моллик — книга о том, как эффективно взаимодействовать с нейросетями в работе и жизни. 
📚 «Глубокое обучение», Гудфеллоу, Бенджио, Курвилль — всё о машинном обучении: от математических основ до реализации сверточных сетей.

Подкасты:
🎤  Подкаст ГНИВЦ: применение искусственного интеллекта в государственном секторе, включая повседневные задачи и корпоративные экспериментальные среды.
🎤 Подкаст Алексея Голубева: сооснователь amoCRM рассуждает об изменениях, которые ИИ приносит в карьеру и бизнес.