APRICOT · RU

Проверка Docker- и DevOps-заданий — автоматически, в изолированной среде

Студент пушит репозиторий. Система собирает его Dockerfile, запускает тесты и выставляет балл в ведомость. Если сборка падает — студент видит лог и может перепослать решение, а преподаватель не тратит на это ни минуты. Работает на кафедрах МФТИ, ВШЭ, МГТУ и Центрального университета.

МФТИ, ВШЭ, МГТУ, Центральный университет · курсы до 400 человек

01студентов
4 000+
02каждая посылка
свой контейнер
03автопроверка
24/7
04курсов
100+
§ 01

Проверка DevOps-заданий, которую не нужно делать руками

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

DevOps-задание — самое дорогое в ручной проверке. Чтобы оценить одну работу, преподаватель клонирует репозиторий, собирает образ, ждёт сборку, запускает контейнер и читает логи. Это 15–20 минут на студента. На потоке в двести человек набегает неделя чистого времени — после каждого дедлайна.

Apricot делает это вместо преподавателя. Студент пушит решение в Git-репозиторий, система клонирует его, собирает Dockerfile и запускает ваши тесты в изолированном контейнере. Балл попадает в ведомость, студент получает полный лог сборки. Преподаватель открывает только спорные работы.

Как устроена проверка Docker-заданий

Система клонирует репозиторий студента с GitHub или GitLab, собирает образ, запускает тесты и сравнивает результат с эталоном. Если сборка упала по вине студента, посылка получает статус «на доработку»: форма остаётся открытой, студент чинит Dockerfile и отправляет снова. Если что-то сломалось на нашей стороне, посылка помечается как системная ошибка и на оценку не влияет.

Автоматическая проверка CI/CD и Bash

Кроме сборки образов система проверяет Bash-скрипты и CI/CD-пайплайны: студент настраивает pipeline в своём репозитории, а чекер убеждается, что стадии описаны верно и проходят. Для типовых курсов есть готовые шаблоны заданий — больше трёхсот.

§ 02

Как работает проверка DevOps-заданий

Три этапа — от создания задания до балла в ведомости.

  1. STEP 01

    Преподаватель создаёт задание

    Выбирает готовый шаблон или подключает собственный чекер: тесты, эталоны, критерии оценки, дедлайны и штрафы за просрочку.

  2. STEP 02

    Студент пушит репозиторий

    Отправляет ссылку на свой Git-репозиторий с Dockerfile, Bash-скриптами или конфигурацией пайплайна. Попытки не ограничены.

  3. STEP 03

    Сборка, тесты, балл

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

§ 03

Типы DevOps-заданий для проверки

От первого Dockerfile до полного CI/CD-пайплайна — с автоматической проверкой каждой посылки.

  • 01

    Dockerfile и сборка образов

    Студент пишет Dockerfile, система собирает образ и проверяет поведение контейнера: сборка проходит, сервис отвечает, тесты зелёные.

  • 02

    Bash и Linux

    Скрипт студента выполняется в изолированном Linux-окружении, вывод и побочные эффекты сравниваются с эталоном.

  • 03

    CI/CD-пайплайны

    Студент настраивает pipeline в своём репозитории. Чекер проверяет, что стадии описаны верно и проходят.

  • 04

    Стеки docker-compose

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

  • 05

    Kubernetes-манифесты

    Проверка конфигураций деплоя: синтаксис, структура манифестов и поведение приложения в кластере.

  • 06

    Свои чекеры под любой стек

    Проверка запускается в Docker-контейнерах, поэтому преподаватель может подключить чекер под любой инструмент с CLI — Ansible, Terraform и другие.

§ 04

Преимущества автоматической проверки DevOps

Изолированные сборки, честные статусы и ведомость курса в одном месте.

  • Изоляция по умолчанию

    Каждая посылка собирается в отдельном контейнере с лимитами на процессор, память и сеть. Хост и чужие посылки недоступны.

  • Лог вместо «не работает»

    Студент видит, на каком шаге упала сборка, и чинит сам — вместо того чтобы писать преподавателю с просьбой посмотреть.

  • Ведомость и дедлайны в одном месте

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

  • Честные статусы

    Упавшая по вине студента сборка — «на доработку» с открытой формой. Сбой платформы — системная ошибка, которая не влияет на оценку.

§ 05

Вопросы о проверке DevOps-заданий

  • 01Как проходит автоматическая проверка Docker-задания?+
  • 02Что видит студент, если сборка упала?+
  • 03Какие DevOps-темы можно проверять автоматически?+
  • 04Безопасно ли запускать студенческий код?+
  • 05Можно ли подключить свои тесты и чекеры?+
  • 06Сколько стоит проверка DevOps-заданий?+
Автор страницы

Павел Ахтямов

Преподаватель МФТИ и факультета компьютерных наук НИУ ВШЭ: распределённые системы, облачные вычисления, DevOps и инфраструктура разработки. Создатель Apricot — автогрейдера, выросшего из его курсов.

Отдайте проверку Docker-заданий машине

Расскажите про курс: сколько студентов, какие темы — Docker, Bash, CI/CD. Настроим чекеры и шаблоны за 1–2 дня. Возможен пилот на один курс.

APRICOT © 2022–2026·EdTech Automation · RU / EN·BUILD 2026.07