Как мы работаем с GitHub на курсе DevOps?

На курсе «DevOps практики и инструменты» мы обучаем работе с Git’ом, как с инструментом командной работы. А также говорим про важность описания инфраструктуры, метрик мониторинга, скриптов сборки и всего-всего в виде кода. И в программе курса из практики нет ничего, что не ложилось бы в код.

А раз можно описать в коде, то можно хранить в Git’e. Github значительно популярнее облачного Bitbucket’а и Gitlab’а. Мы с ним умеем работать и поэтому выбрали именно его.

Набитые шишки

Индивидуальные репозитории у каждого студента

Сначала у нас была простая идея: 1. студент создаёт свой собственный репозиторий; 2. приглашает преподавателя в качестве maintainer’а (одного из владельцев репозитория) в свой репозиторий; 3. каждую самостоятельную работу оформляет в виде Pull Request’а; 4. преподаватель оценивает работу, если всё хорошо — даёт approve и засчитывает задание, иначе даёт свои комментарии отправляет работу на доработку.

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

Поэтому мы сделали для наших студентов публичную организацию и начали всех студентов в неё приглашать. Так мы получили возможность: — один раз добавить всех преподавателей в организацию; — больше не тратить время на рассылку приглашений в репозитории; — видеть все открытые PR’ы, то есть все сданные на проверку самостоятельные работы.

Выглядит это так:

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

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

Плохо оформленные самостоятельные работы

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

Нам же присылали на проверку: — Кучу мусора, какие-то бинарные файлы, миллион изменений, временные файлы, секреты и авторизационные данные; — Pull Request’ы без описания и Readme. И сиди гадай, что студент сделал, понял ли он что сделал, проверил ли он то, что мы просили проверить; — Pull Request’ы с неправильными структурой директорий и расположением файлов. С синтаксическими ошибками внутри файлов.

Чтобы как-то справиться с напастью, в одной из первых СР мы просим студентов добавить в свой репозиторий шаблон, по которому нужно будет оформлять все последующие PR’ы. Если последующие СР оформлены не по шаблону, мы заворачиваем работу на доработки.

Чтобы как-то справляться с неправильной структурой директорий, мы на InSpec написали несколько проверок, и запускаем их через Travis CI для каждого PR’а студента. Тесты хранятся в публичном репо, каждый поток в отдельной ветке. Конфигурацию Travis’а студенты самостоятельно добавляют в одной из первых работ.

Когда мы видим кучу мусора в PR, мы просим убрать всё лишнее. Чтобы уменьшить количество мусора в master-ветке репозитория, мы заблокировали студентам возможность прямого push’а в мастер, только через PR с Approve’ом. А вот как автоматизировать или уменьшить вероятность его появления, пока не придумали...

Какие домашние задания нужно проверить?

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

Github же позволяет создавать проекты — это такие канбан-доски для отдельных репозиториев и организации в целом. Мы создали такой проект: — Отправлено на доработку: преподаватель посмотрел PR, нашёл замечания, запросил изменения PR’а; — Очередь на проверку: сюда попадают все новые PR’ы, а также PR’ы из «Отправлено на доработку» после любого изменения, преподаватели выбирают работы для проверки из этой колонки; — Проверено: сюда попадают одобренные PR’ы, по которым нет серьезных замечаний; — Готово: сюда переходят PR’ы из «Проверено» после merge PR’а студентом.

Это позволило нам не проверять каждый PR, высматривая изменения, а брать их по очереди из «очереди на проверку». Раньше мы делали эти переводы руками, а сейчас полностью автоматизировали с помощью Github webhooks и бота на AWS Lambda. Код бота пока закрыт для широкой публики.

Переключения между OTUS и GitHub’ом

Последнее наше улучшение процесса связано с приёмкой СР в ведомости. Ведомость в OTUS для нас стала лишним инструментом. Туда прилетают вопросы, на которые надо отвечать (а у нас для этого Slack, и в там другие студенты обычно отвечают оперативнее преподавателей) и ставить оценки (когда мы их проверяем на Github). И последнее нас очень огорчало.

На простановку оценки в ведомости тратится больше времени, чем на приём некоторых ДЗ. Часто ошибаемся со столбцами, куда ставим оценку, так как номер СР не равен номеру прочитанной лекции. Мы-то ориентируемся как раз на номер занятия. Часть студентов не заполняют свои профили на Github’е и потом трудно бывает найти «кто это сдаёт работу». Да и просто иногда забывали пойти в ведомость и поставить оценку.

Благодаря Григорию Ожегову, который написал для платформы OTUS API и его поддержке, мы реализовали автоматизацию приёмки СР в ведомости. Если раньше после Approve’а PR преподаватель сам ходил в ведомость и ставил оценку, то теперь за него это делает бот при merge PR’а студентом.

Алгоритм работы бота (код которого пока закрыт) довольно простой: 1. Найти ID группы на платформе OTUS по имени организации GitHub; 2. Найти преподавателя по Github ID пользователя в assignee PR’а; 3. Найти студента по Github ID владельца PR’а; 4. Найти идентификатор СР по имени ветки PR’а, для этого в описание каждой СР в поле «для преподавателей» мы ставим имя ветки, в которой мы ожидаем выполненную работу; 5. Принять работу с вышеописанными параметрами.

Механизм довольно новый, потому есть пара нюансов. После изменения описания СР нужно получить от команды OTUS approve на изменения программы курса, иначе бот не находит СР. Некоторых студентов нам приходится прямо «задалбывать», чтобы они подключили Github аккаунт к учётной записи OTUS. Иногда случаются мелкие недочёты по автоматизации. Например, мы не ожидаем, что студент поставит себя в assignee PR’а. Но ожидаем, что он правильно, буква в букву, назовёт ветку, в которой он будет сдавать СР. А это не всегда получается так.

Непрерывное улучшение

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

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

Есть вопросы? Напишите в комментариях!