Проект - варианты заданий и правила выполнения
Общие требования
Список будет пополнятся :)
Dockerfile:
Минимальная версия докера Docker version 19.03.13, build 4484c46d9d
Базовый образ ubuntu:22.04
Не использовать Expose
При установке любых пакетов и программ (в том числе в requirements) ВСЕГДА указывать версии
Ограничить установку зависимостей apt одной строкой (один RUN)
Если настройка одной части приложения состоит из нескольких команд → необходимо разместить их в одном слое (в одном RUN)
Docker-compose:
Минимальная версия docker compose version 1.27.4, build 40524192
Все должно собиратся по команде docker-compose build без sudo
Не использовать тип сети HOST
Не отрывать лишних (непредусмотренных заданием) портов
Не использовать порты хост-машины ⇐1024
Варианты заданий
Расшифровка условий задания
Построение тестов
Проверка на соответствие стилю кодирования / бьютификакция - подключаем проверку стиля кодирования (технологии ниже) и встраиваем ее в цепочку запуска
Статический анализ - подключаем статическую проверку (через pylint) и встраиваем ее в цепочку запуска
Анализ по 10 существующим критериям - выберите по 10 уникальных критериев проверки, настройте запуск на них и допустите все десять ошибок в коде проекта:)
Создание своего критерия и проверка только по нему - проверяем на наличие переменных, название которых совпадает с вашим именем
Интеграционные тесты - пишем интеграционные тесты (через requests) и встраиваем их в цепочку запуска
Selenium - пишем selenium тесты и встраиваем их в цепочку запуска (нельзя использовать для selenium отдельный контейнер, реализуйте тесты в рамах контейнера tester). См. описание ниже.
Docker
Внешний SSH доступ в контейнеры - организуем доступ через протокол SSH контейнер одним из следующих способов: или по ключу в каталоге с проектом, или генерируем пароль для доступа и сообщаем его при сборке / запуске, или генерируем новую пару ключе и выводим их в файлы. Порт для SSH должен быть доступен снаружи docker-compose конфигурации.
В app - по публичному ключу (существующему)
В tester - по публичному ключу (существующему)
В app и tester - по публичному ключу (существующему)
В app - по паролю
В tester - по паролю
В app и tester - по паролю
В app - по сгенерированной в процессе сборки паре ключей (ключи выводим в файл)
В tester - по сгенерированной в процессе сборки паре ключей (ключи выводим в файл)
В app и tester - по сгенерированной в процессе сборки паре ключей (ключи выводим в файл)
Вывод логов работы tester - задание о том, куда и как выводить логи тестирования в контейнере tester
Каждый этап тестирования - в docker log (stdout + stderr) и в отдельный файл оба потока по каждому виду тестирования Совместно выводим логи тестирования (stdout + stderr) так, чтобы их видел и docker logs, и они собирались в файле.
Каждый этап тестирования - в docker log ( stdout + stderr) и в общие файлы (отдельно - для stdout, отдельно - для stderr) - Совместно выводим логи тестирования (stdout + stderr) так, чтобы их видел docker logs, но при этом в один файл сохраняем stdout логов, в другой - stderr.
Каждый этап тестирования - в docker log (stdout + stderr) + добавить к записям лога timestamp - помимо вывода в docker log нужно также сделать, чтобы перед каждой записью в логе стоял timestamp (или текущее дата и время)
Docker-compose
Передача параметров в конфигурацию через .env, какие параметры передаем - нужно сделать как пример env файла, так и смаппить (А кое где и написать скрипты настройки) параметры на нужное поведение
Порт для веб-сервера - публичный порт, на котором слушает веб-сервер
Список этапов тестирования для запуска - список шагов из пункта “Построение тестов”, которые будут запущены. Если не задано, запускаем все этапы. Если задано - то только указанные.
Публичный SSHключ для доступа в контейнер(ы) - это отдельный ключ, не связанный с заданием “Внешний SSH доступ в контейнеры” из предыдущего раздела.
Ключ отладки для Flask - флаг отладочной работы (debug) для Flask приложения
Органичения ресурсов - ограничения ресурсов для контейнеров в docker-compose.yml
ОЗУ - ограничьте доступную каждому из контейнеров ОЗУ до объема 100 + НОМЕР_ВАРИАНТА * 10 МБ
Ядра процессора - ограничьте доступные в каждом контейнере количество ядер ЦПУ до (1 + НОМЕР_ВАРИАНТА % 2) (остаток от деления номера вашего варианта на два)
Максимальное Количество процессов - ограничьте до количества НОМЕР_ВАРИАНТА
Selenium-тесты
Задача в написании Selenium-тестов - написать автотесты для нескольких форм ИС ИОТ. Тестовый инстанс находится по адресу https://dev.digital.etu.ru/trajectories-test/.
Тест должен включать в себя следующие шаги:
Авторизация через ETU ID.
Используйте ваш логин/пароль из ЛК ЛЭТИ. Укажите их в .env-файле, коммитить в репозиторий не нужно
Вы должны получить в системе права администратора. Если не получите - пингуйте нас в Discord.
В системе все персональные данные заменены на сгенерированные.
Если ваш вариант включает в себя работу с ОПОП, РП или формой “Распределение документов”, авторизуйтесь за пользователя id=1305 (Schimmel Вадим August) на форме “Авторизация за другого пользователя”. У этого пользователя есть все права на все документы.
Проверьте функционирование формы, указанной в задании:
-
Большинство форм включают в себя сохранение какого-то состояния (вкладки документа, выдача прав и т.п.). В таком случае задача - ввести в форму какие-то значения (не обязательно осмысленные), сохранить, обновить страницу и проверить, что внесенные данные сохранены.
В работе с документами - можете создать новый документ или взять существующий в статусе “черновик”. Если создаете новый, не забудьте удалить.
В работе с документами - берите документы с кафедрой, соотвествующей вашему положению в таблице “Варианты заданий” (см. ниже). Так мы избежим конфликтов из-за одновременного выполнения тестов.
В работе с пользователями - берите пользователей, у которых фамилия соответствует вашей сгенерированной (можно посмотреть сверху в сайдбаре).
Перечень кафедр
Кафедра, в которой вы работаете = (ваш номер в “Варианты заданий”) % 40 + 1.
Кафедры:
каф.АМ
каф.ЛИНС
каф.ЭПУ
каф.ИИСТ
каф.ВМ
каф.МНЭ
каф.РАПС
каф.ЭП
каф.ЭУТ
каф.ФЛ
каф.ИМ
каф.ТВ
каф.МОЭВМ
каф.МСК
каф.БЖД
каф.СО
каф.ВТ
каф.САПР
каф.ФЭТ
каф.Фот
каф.МВЭ
каф.ПМИГ
каф.ИНЯЗ
каф.ТОЭ
каф.СП
каф.ПЭ
каф.ТОР
каф.БТС
каф.РС
каф.САУ
каф.ИКГП
каф.ЭТПТ
каф.РЯ
каф.МИТ
каф.ФХ
каф.РЭС
каф.ИЗОС
каф.АПУ
каф.ИС
каф.ФВиС
Это не все кафедры ЛЭТИ, только те, по которым есть более 100 РП.
Варианты средней сложности
Вам необходимо реализовать docker-compose конфигурацию из двух узлов (не больше и не меньше):
Оба контейнера должны использовать написанные вами образы, собираемые из локальных Dockerfile. Шаблоны для имен Dockerfile:
Dockerfile_app
Dockerfile_tester
Помимо Dockerfile, вам также необходимо сделать файл README.md, содержащий примеры команд для запуска тестов и проверки всей конфигурации. Это сильно ускорит проверку:)
Параметры конфигурации задаются в таблице вариантов + общие требования (http://se.moevm.info/doku.php/courses:devops:project#общие_требования).
Варианты высокой сложности
1. Автоматизация тестирования курсовых по Android
Идея - разработать набор github actions, которые будут по состоянию репозитория проверять (базово) соответствие этапам выполнения работы и генерировать / отображать статус в readme.
Подробности об этапах:
https://se.moevm.info/doku.php/staff:courses:application_development_for_mobile_platforms:course_work:topics
Проверяем:
Макет и UC (есть вики страница, файл макета загружен в репо)
UI на заглушках (если задан нужный тег- проверяем наличие исходников андроид проекта, его собираемость через github actions, .gitignore , название пакета )
Юнит-тесты ( тег, сборка и запуск)
App is ready (тег, требования, запуск, запуск стресстестов)
Оценка сложности UI вашего приложения (вики станица и ее содержимое)
Пояснительная записка (наличие файлов )
Интеграционные тесты ( тег, сборка и запуск)
Используем в качестве технологий github actions. Сдаем отдельным репо.
2. Проверка корректности учебных работ на языке Python (командная строка)
Идея - автоматизировать процесс проверки лабораторных и курсовых работ.
Для проверки кода - pylint, для тестирования работы в командной строке https://github.com/cucumber/aruba, для профилирования работы - valgrind.
Формат выполнения github actions. Сдаем отдельным репо.
Этапы проверки
Успешная проверка на явные синтаксические проблемы через линтер(не запустится, нет комментов, невменяемые имена переменных….)
Успешное тестирование работы на заранее известных примерах аргументов командной строки (== приложение не падает с заранее известными аргументами )
Стресс-тестирование аргументов командной строки (проверка, что если подавать почти рандомные аргументы, приложение не сломается. Аргументы необходимо генерировать рандомно, но в соответствии с описанием ожидаемой структуры )
Стресс-тестирование stdin
Профилирование работы по памяти и времени ( valgrind + time)
3. Проверка корректности учебных работ на языке С (командная строка)
Аналогично теме 2, но компилируем в gcc (и проверяем что все ок с компиляцией) + другие линтеры.
Правила оценивания
Правила работы в репозитории
По работе в selenium