Зачастую лучшие решения приходят оттуда, откуда их совсем не ждут. Стоит только посмотреть на обыденные вещи немного под другим углом, как сразу над головой загорается «мыслелампочка».
Точно такая же история произошла и с нашей командой, когда к нам поступила задача на разработку системы для управления расписанием занятий и учета успеваемости учащихся колледжа.
Забегая вперед, в результате у нас получилось решить задачу разработкой приложений для облачной CRM Bitrix 24.
На примере своего кейса мы хотели бы показать, как можно использовать эту crm, на первый взгляд, не совсем в стандартных целях. Мы смеем надеяться, что наш опыт будет полезен, столкнувшимся с задачей кастомной интеграции bitrix24 и как минимум вдохновит на подобные решения.
Проект стал логическим продолжение сайта, который мы запустили для клиента ранее.
На сайте уже было расписание, но не хватало удобного управления и внутреннего, персонализированного пространства для участников процесса обучения — преподавателей и студентов.
Собрав базовые требования, мы получили приблизительно такой список:
Bitrix24, откровенно говоря, наша рабочая среда. Мы ее неплохо знаем с точки зрения пользователя. Тут мы ведем наши проекты, обмениваемся документами, ведем коммуникации с клиентами, ведем свои задачи в трекере.
Также мы, к моменту поступления задачи, имели некоторый опыт разработки приложений под b24:
Но более или менее серьезных интеграций, кроме канбан доски от компании Сибирикс, мы не знали на тот момент и не реализовывали.
Приложения в bitrix24 — это ваша разработка, которая может размещаться и работать на вашей площадке, но встроенная в портал bitrix24 через Iframe. Данная интеграция позволяет использовать Oauth 2.0 авторизацию и обеспечивает работу с данными портала через API.
Bitrix24 в данном случае будет «черным ящиком», реализовать свои решения вы можете как вам угодно. У нас, например, получилось на стеке React + Laravel, подробнее ближе к концу статьи.
Приложение в bitrix24 — это решение задач, которые нельзя решить средствами существующего в сервисе функционала.
Т.е если вас, например, не устраивает «базовое» отображение списка задач или любой другой сущности, вы можете реализовать собственное приложение, в котором сможете вывести список задач так, как вам нужно. Если вам необходимо автоматически проводить какие-то манипуляции с данными bitrix сущностей или их характеристиками — то это тоже может решаться посредством кастомных решений.
Но bitrix24 — это в первую очередь CRM система, откуда тут портал для автоматизации учебного процесса?
Использование bitrix24 в качестве платформы для реализации нашей задачи, на самом деле, выглядело заманчиво.
Практически «из коробки» мы получали решение проблемы коммуникации между студентами и преподавателями посредством использования функционала рабочих групп. Нужно было просто посмотреть на рабочие группы под нужным углом.
Группа может быть учебной — объединять куратора-преподавателя и студентов, позволяя обмениваться локальной для группы информацией.
Группа может быть предметной — физика, химия… и пр. Благодаря возможностям b24, в такой группе можно легко организовать «knowledge domain» информации по предмету. Для это есть весь нужный функционал:
Наличие платформы для разработки чат-ботов, которые автоматически доступны на мобильной версии портала, сразу наводило на мысль о создании как минимум бота, который предоставлял бы информацию о расписании занятий и информировал об его изменениях, дополнительно к sms уведомлениям.
Под те требования, которые остались непокрытыми функционалом платформы, мы решили разработать iframe-приложения.
Рабочих примеров подобной реализации не было, чтобы показать «будет приблизительно вот так». Поэтому был создан небольшой эскиз концепции. Мы составили документ, кратко описывающий то, как мы видим реализацию проекта на bitrix24. Это сыграло важную роль в принятии решения о разработке.
С требованиями и инструментарием определились, теперь можно и сам процесс разработки рассмотреть.
Последовательность описания будет следующей:
Итак поехали!
Как мы уже говорили ранее у нас имеются три отдельные сущности. Функционирующий сайт, CRM-система bitrix и iframe приложение, которое мы собрались разрабатывать. Данные, которые содержатся в этих сущностях, можно схематично изобразить в виде следующей mind-карты.
Нам необходимо было «подружить» эти разнородные сущности и решить вопрос с целостностью данных.
Поскольку, на сайте уже была сформирована и эксплуатировалась база данных по всем справочникам и самому расписанию, мы решили просто реализовать для нее REST API, чтобы эти данные можно было получить в нашем bitrix24 приложении.
Для каждой из ролей пользователя было реализовано отдельное приложение. Под схемой будет описано почему так было сделано.
Мы решили распределить так функционал, поскольку если приложение было бы одно, то нам пришлось бы реализовывать логику распределения доступа. Студентам не нужен доступ в журнал с оценками, преподавателю не нужно управлять расписанием и т.д. В целом это не страшная задача, но мы используем среду, в которой возможно настроить политику доступа к приложениям на уровне групп пользователей из коробки. К тому же мы рассматриваем bitrix24 как платформу разработки — почему бы не использовать существующий функционал.
На текущий момент в приложении существует 4-ре департамента: администраторы портала, Преподаватели, Студенты и Чат-Боты.
Изначально, до детализации требований и до принятия решения о реализации полноценного приложения, задача стояла изменить именно систему управления расписанием, поскольку реализация на стороне сайта превращала работу над составлением расписания в адские муки и отнимало много времени.
По факту это добавление\редактирование записей в БД через интерфейс инфоблоков bitrix
Т.е для занесения занятия в расписание требовалось создать элемент в табличном интерфейсе
В процессе поиска более удобного решения мы подумали — что может быть удобнее редактирования расписания в интерфейсе, которое выглядит как расписание?
И разработали функциональный прототип
А затем добавили красок, drag&drop, сайдбар и нотификации. И нарисовали сову.
Для более подробного представления о работе приложения мы записали небольшой скринкаст, в нем отображена часть функционала решения.
Функционал, который реализован:
В требованиях также значилась отправка уведомлений на случай изменения расписания. Сказано — реализовано. Уведомления доставляются чат-ботом (также доступен и в мобильном приложении) через sms шлюз и постятся в новостную ленту группы (ну чтобы уже наверняка).
По умолчанию уведомления отправляются студентам и преподавателям, в группах которых произошли изменения, но администратор может также выбирать список получателей. Тексты самих уведомлений генерируются по шаблону, но в них легко можно внести изменения.
Еще одна задача, которую мы решили в интерфейсе администратора — маппинг, связка преподавателей и групп сайта с преподавателями и группами в Bitrix. Именно по соц. группам bitrix24 определяется какое расписание показывать преподавателю, что видит студент. Т.е данные в API, а фильтруем их по данным из bitrix24. Для этого мы реализовали специальный CRUD интерфейс, в котором проставлялись эти зависимости.
Администратор, для создания связи, может выбрать преподавателя из уже имеющихся на сайте
или пригласить нового, отправив ему уведомление по email
Также в задачи администратора входит управление справочными данными, из которых «собирается» расписание — предметы, преподаватели, аудитории. В целом, эту работу можно проделать и в админ интерфейсе сайта, но чтобы администратор находился в единой среде, мы реализовали интерфейс непосредственно в приложении.
Для преподавателя мы разработали приложение, которое состоит из трех основных частей: Расписание занятий, Журнал и Успеваемость студентов.
На странице Расписания занятий преподаватель может просматривать свое расписание, с фильтром по группам, в которых он преподает. Помимо этого, преподаватель может создать на основе записи в расписании неограниченное кол-во записей журнала определенного типа (лекция, семинар, лабораторная работа, практика, домашнее задание и т.д).
В Журнале преподаватель может зафиксировать информацию об оценках, посещаемости студентов и задать домашнее задание.
Создание, удаление, редактирование занятия, а также чат со студентом выглядят так:
Самое важное, что нужно знать студенту — расписание занятий, успеваемость и домашнее задание. По аналогии с интерфейсами администратора и преподавателя, была создана страница просмотра расписания занятий. Немного изменен внешний вид и убран лишний функционал.
На странице успеваемости студент просматривает текущие оценки и средний балл по предметам. Также есть фильтр по семестрам.
На чат-бота мы возложили пока простые обязанности отправки сообщения об изменении в расписании и отправку сетки расписания по запросу. Можно запросить расписание как на определенный день, так и на всю неделю. Чат-бот, как сервис доступный в чатах портала, автоматом доступен на мобильной версии портала — крайне удобно. Таким образом мы обеспечили простой доступ к расписанию и с мобильных устройств.
Был большой соблазн в качестве иконки чат-бота использовать такое изображение
Но мы не стали, посчитав, что это слишком иронично получится.
Мы ревностно относимся к результату своей работы, ошибки приложения и проблемы у пользователей при работе с нашим приложением больно ранят наши сердца.
Для обеспечения кардио-безопасности и качественной работы приложения мы применяем комплекс мер.
Мы используем 3 независимых сервера под разработку тестирование и эксплуатацию.
В разработке действует модель git-flow.
Для авто тестирования мы используем codeception, тестируем пользовательские сценарии и api данных с сайта.
Для сборки приложения на staging и production мы используем gitlab-ci, размещая файлы по нужным директориям приложений (у нас их несколько по факту получилось см. выше), запускаем сборку front-end npm run build, composer и авто тесты.
Как бы мы ни старались все покрыть тестами невозможно, всегда найдутся исключительные ситуации. Так или иначе ошибок не избежать. Если их не избежать, то наверняка можно как-то контролировать?
Наверное, все мы привыкли к тому факту, что если на сервере вдруг произошла ошибка, то она записывается в логи и после ее можно диагностировать. Но что делать с ошибками, которые происходят на фронтенде? Все что происходит у клиента, у него и остается. Если ошибка достаточно критичная, то можно узнать о ней, через гневный отзыв клиента. Это явно не наш метод.
Чтобы отлавливать ошибки, которые могут возникнуть в процессе работы «production» приложения, мы используем и жутко радуемся этому сервису https://sentry.io. Данный сервис производит сборку как клиентских так и серверных ошибок. Все ошибки отслеживаются и должны быть зарезолвены.
Бонусом мы настроили интеграцию в slack, так, чтобы в момент возникновения прецедента, в проектном канале появлялось соответствующее уведомление. Благодаря этому мы можем узнать об ошибках раньше, чем будет клиентом создан тикет в системе поддержки, и оперативно принять меры, если ситуация критическая.
Для отслеживания состояния production машины используется zabbix. Отслеживаются все основные параметры машины от доступности до использования ресурсов.
При формировании связей сайт — портал, формировании расписания, могут возникнуть конфликтные ситуации, нарушающие целостность данных. Например, может быть ситуация, когда одному преподавателю по ошибке на один и тот же день и одну и туже пару назначают несколько занятий.
Человек — не робот. За всем точно не уследишь. Для решения таких проблем мы собрали экран диагностики «Контроль», в котором разместили в виде чек-листа список проверок и их результат.
С технической точки зрения весь проект достаточно сложный, поэтому к выбору технологий мы подошли основательно. В качестве серверного языка программирования мы решили использовать PHP, в купе с СУБД MySQL. Данная связка очень популярна в мире web-разработки, более того, хорошо известна нашей команде.
Поскольку в основе проекта лежит использование CRM Bitrix 24, то очень много завязано на использовании API портала. Очень часто будет использоваться вызов различных методов, следовательно нужно по максимуму упростить эту часть. Для этой цели мы решили использовать bitrix24-php-sdk, которая предоставляет удобный объектный подход. Заодно немного участвуем в разработке этой бибилиотеки.
Писать на native PHP в 2017 году далеко не лучший вариант, тем более для проекта такого размера. Поэтому нужно было выбрать фреймворк. Из требований — наличие MVC, ORM, миграций и сидов, работа с очередями. Под эти требования подходят много фреймворков Laravel, YII2, Zend, Phalcon и пр. малоизвестные. Мы решили выбрать Laravel, поскольку у нашей команды было больше опыта работы именно с ним.
С точки зрения фронтенда выбор хорошего инструмента был не менее важен. Мы остановили свой взгляд на связке React/Redux/React Router.
В основе React лежит компонентный подход, что очень нам подходит. Удобно реализовать один компонент и затем многократно использовать его в нескольких местах приложения.
Так, например, было с компонентом для вывода расписания занятий. В общих чертах он одинаков как для студента, так и для администратора и преподавателя. Все отличительные особенности хорошо конфигурируются через свойства компонентов.
Также у React огромное комьюнити и большое число различных реализованных компонентов. Нам очень помог компонент react dnd при реализации механизма переноса занятий.
Для написания стилей мы использовали препроцессор-Less, который существенно позволяет уменьшить количество строк CSS-кода, за счет использования иерархических структур, примесей и переменных.
За сборку проекта у нас отвечает Webpack. На самом деле выбор сборщика был не так принципиален, поскольку каких-то особенных моментов или требований у нас не было.
Работая над проектом мы получили опыт, который сложно описать в рамках одного поста. Раскрытие отдельных вопросов разумнее делать отдельными публикациями.
Точно такая же история произошла и с нашей командой, когда к нам поступила задача на разработку системы для управления расписанием занятий и учета успеваемости учащихся колледжа.
Забегая вперед, в результате у нас получилось решить задачу разработкой приложений для облачной CRM Bitrix 24.
На примере своего кейса мы хотели бы показать, как можно использовать эту crm, на первый взгляд, не совсем в стандартных целях. Мы смеем надеяться, что наш опыт будет полезен, столкнувшимся с задачей кастомной интеграции bitrix24 и как минимум вдохновит на подобные решения.
Задача
Проект стал логическим продолжение сайта, который мы запустили для клиента ранее.
На сайте уже было расписание, но не хватало удобного управления и внутреннего, персонализированного пространства для участников процесса обучения — преподавателей и студентов.
Собрав базовые требования, мы получили приблизительно такой список:
- система управления расписанием
- рассылка sms уведомлений об изменении в расписании
- учет посещаемости, журнал успеваемости
- коммуникации между студентами и преподавателями, в том числе обмен документами
Bitrix24, откровенно говоря, наша рабочая среда. Мы ее неплохо знаем с точки зрения пользователя. Тут мы ведем наши проекты, обмениваемся документами, ведем коммуникации с клиентами, ведем свои задачи в трекере.
Также мы, к моменту поступления задачи, имели некоторый опыт разработки приложений под b24:
- мы делали свое приложение, которое решает задачи мониторинга нагрузки на техподдержку
- выпустили первого коммерческого чат-бота для b24
- собрали решение по сквозной аналитике с использованием google analytics и call tracker
Но более или менее серьезных интеграций, кроме канбан доски от компании Сибирикс, мы не знали на тот момент и не реализовывали.
Приложения в bitrix24 — это ваша разработка, которая может размещаться и работать на вашей площадке, но встроенная в портал bitrix24 через Iframe. Данная интеграция позволяет использовать Oauth 2.0 авторизацию и обеспечивает работу с данными портала через API.
Bitrix24 в данном случае будет «черным ящиком», реализовать свои решения вы можете как вам угодно. У нас, например, получилось на стеке React + Laravel, подробнее ближе к концу статьи.
Приложение в bitrix24 — это решение задач, которые нельзя решить средствами существующего в сервисе функционала.
Т.е если вас, например, не устраивает «базовое» отображение списка задач или любой другой сущности, вы можете реализовать собственное приложение, в котором сможете вывести список задач так, как вам нужно. Если вам необходимо автоматически проводить какие-то манипуляции с данными bitrix сущностей или их характеристиками — то это тоже может решаться посредством кастомных решений.
Но bitrix24 — это в первую очередь CRM система, откуда тут портал для автоматизации учебного процесса?
Использование bitrix24 в качестве платформы для реализации нашей задачи, на самом деле, выглядело заманчиво.
Практически «из коробки» мы получали решение проблемы коммуникации между студентами и преподавателями посредством использования функционала рабочих групп. Нужно было просто посмотреть на рабочие группы под нужным углом.
Группа может быть учебной — объединять куратора-преподавателя и студентов, позволяя обмениваться локальной для группы информацией.
Группа может быть предметной — физика, химия… и пр. Благодаря возможностям b24, в такой группе можно легко организовать «knowledge domain» информации по предмету. Для это есть весь нужный функционал:
- хранение файлов
- новостная лента
- wiki
- чаты
Наличие платформы для разработки чат-ботов, которые автоматически доступны на мобильной версии портала, сразу наводило на мысль о создании как минимум бота, который предоставлял бы информацию о расписании занятий и информировал об его изменениях, дополнительно к sms уведомлениям.
Под те требования, которые остались непокрытыми функционалом платформы, мы решили разработать iframe-приложения.
Рабочих примеров подобной реализации не было, чтобы показать «будет приблизительно вот так». Поэтому был создан небольшой эскиз концепции. Мы составили документ, кратко описывающий то, как мы видим реализацию проекта на bitrix24. Это сыграло важную роль в принятии решения о разработке.
Приложение 24
С требованиями и инструментарием определились, теперь можно и сам процесс разработки рассмотреть.
Последовательность описания будет следующей:
- описание сущностей
- описание структуры приложения
- интерфейс администратора
- интерфейс преподавателя
- интерфейс студента
- стек используемых технологий и процессов
Итак поехали!
Основные сущности
Как мы уже говорили ранее у нас имеются три отдельные сущности. Функционирующий сайт, CRM-система bitrix и iframe приложение, которое мы собрались разрабатывать. Данные, которые содержатся в этих сущностях, можно схематично изобразить в виде следующей mind-карты.
Нам необходимо было «подружить» эти разнородные сущности и решить вопрос с целостностью данных.
Поскольку, на сайте уже была сформирована и эксплуатировалась база данных по всем справочникам и самому расписанию, мы решили просто реализовать для нее REST API, чтобы эти данные можно было получить в нашем bitrix24 приложении.
Структура решения на стороне bitrix24
Для каждой из ролей пользователя было реализовано отдельное приложение. Под схемой будет описано почему так было сделано.
Мы решили распределить так функционал, поскольку если приложение было бы одно, то нам пришлось бы реализовывать логику распределения доступа. Студентам не нужен доступ в журнал с оценками, преподавателю не нужно управлять расписанием и т.д. В целом это не страшная задача, но мы используем среду, в которой возможно настроить политику доступа к приложениям на уровне групп пользователей из коробки. К тому же мы рассматриваем bitrix24 как платформу разработки — почему бы не использовать существующий функционал.
На текущий момент в приложении существует 4-ре департамента: администраторы портала, Преподаватели, Студенты и Чат-Боты.
Структура back-end
Для реализации схемы из 3-ех приложений на уровне backend мы сформировали для себя следующие требования:
- У каждого приложения должен быть свой уникальный url (точка входа)
- У каждого приложения должен храниться уникальный идентификатор и ключ доступа (генерируются bitrix24 при создании приложения, обязательны при работе)
- Использование одного git репозитория
- Все три приложения должны иметь общую бд (все три приложения работают с одними и теми же сущностями)
В результате у нас получилось:
- Код каждого приложения размещается в директории отдельного виртуального хоста
- Вся характерная, конфигурационная информация хранится в .env файле каждого приложения
- Под git мы размещаем только приложение администратора. Хосты приложений студента и преподавателя содержат минимум сущностей, только для того, чтобы «завести» laravel, который используется в качестве framework на backend. При этом сущности, которые хранятся на основном хосте и нужны в работе всех приложений, просто линкуются symlink-ами. У каждого приложения свой bundle js и css, размещены, опять же, в директории административного приложения и подключаются через точки входа соответствующих приложений.
- У всех 3-ех приложений одна бд. Чтобы не было конфликта с миграциями и seeds директория database залинкована с хостов студента и преподавателя на директорию под git в приложение администратора.
Интерфейс администратора
Работа с расписанием
Изначально, до детализации требований и до принятия решения о реализации полноценного приложения, задача стояла изменить именно систему управления расписанием, поскольку реализация на стороне сайта превращала работу над составлением расписания в адские муки и отнимало много времени.
По факту это добавление\редактирование записей в БД через интерфейс инфоблоков bitrix
Т.е для занесения занятия в расписание требовалось создать элемент в табличном интерфейсе
В процессе поиска более удобного решения мы подумали — что может быть удобнее редактирования расписания в интерфейсе, которое выглядит как расписание?
И разработали функциональный прототип
А затем добавили красок, drag&drop, сайдбар и нотификации. И нарисовали сову.
Для более подробного представления о работе приложения мы записали небольшой скринкаст, в нем отображена часть функционала решения.
Функционал, который реализован:
- создание\редактирование\удаление занятия
- изменение места занятия в сетке расписания
- создание спаренных занятий в рамках одной пары
В требованиях также значилась отправка уведомлений на случай изменения расписания. Сказано — реализовано. Уведомления доставляются чат-ботом (также доступен и в мобильном приложении) через sms шлюз и постятся в новостную ленту группы (ну чтобы уже наверняка).
По умолчанию уведомления отправляются студентам и преподавателям, в группах которых произошли изменения, но администратор может также выбирать список получателей. Тексты самих уведомлений генерируются по шаблону, но в них легко можно внести изменения.
Как это работает
Поскольку процесс отправки большого количества сообщений может затянуться, реализацию отправки уведомлений мы собрали на основе менеджера задач gearman. Т.е есть несколько запущенных фоном workers, которые находятся в состоянии постоянной готовности принять задачу на отправку, будь-то sms или сообщение чат-бота.
Таким образом мы получили:
- контроль над ресурсами — «вокеров» висит столько, сколько мы себе по ресурсу и задаче можем позволить
- скорость работы — за счет «параллельного» исполнения мы можем обработать быстро большое кол-во сообщений
- контроль над отправкой сообщений — в случае ошибки при доставке, мы можем отследить статус задачи и, например, инициировать повторную отправку
CRUD-связей
Еще одна задача, которую мы решили в интерфейсе администратора — маппинг, связка преподавателей и групп сайта с преподавателями и группами в Bitrix. Именно по соц. группам bitrix24 определяется какое расписание показывать преподавателю, что видит студент. Т.е данные в API, а фильтруем их по данным из bitrix24. Для этого мы реализовали специальный CRUD интерфейс, в котором проставлялись эти зависимости.
Администратор, для создания связи, может выбрать преподавателя из уже имеющихся на сайте
или пригласить нового, отправив ему уведомление по email
Работа со справочниками
Также в задачи администратора входит управление справочными данными, из которых «собирается» расписание — предметы, преподаватели, аудитории. В целом, эту работу можно проделать и в админ интерфейсе сайта, но чтобы администратор находился в единой среде, мы реализовали интерфейс непосредственно в приложении.
Нотификации
Для информирования пользователя о различных событиях, в приложении используется около 25 нотификаций 4-ех типов:
- success
- warning
- pending
- error
Мы могли бы ограничиться одним «плейсментом» показа нотификаций — правый верхний угол, но к сожалению (а может даже и к счастью) мы столкнулись с ограничениями встраиваемых Iframe-приложений.
Стандартная высота Iframe блока на портале bitrix составляла порядка 800px, вместить что-либо дельное на таком клочке не представлялось возможным. При превышении этого значения у iframe блока появлялся собственный вертикальный scrollbar. Два Scrollbar на одну страницу? — «Многовато!». Благо у библиотеки bitrix был встроенный метод fitWindow, который растягивает iframe блок в соответствии с размерами его содержимого.
Мы избавились от второго скролла, но также и от возможности использования фиксированного позиционирования. И поэтому мы добавили нотификации рядом с источником их инициации.
И вот как они выглядят:
Ошибка при сохранении записи преподавателя
Успешное сохранение названия предмета
Попытка удалить что-то важное
При длительном запросе у кнопки появляется pending-state
Использование подобного рода нотификаций очень положительно сказалось на пользовательском восприятии, ведь приложение стало более живым и отзывчивым.
Интерфейс преподавателя
Для преподавателя мы разработали приложение, которое состоит из трех основных частей: Расписание занятий, Журнал и Успеваемость студентов.
На странице Расписания занятий преподаватель может просматривать свое расписание, с фильтром по группам, в которых он преподает. Помимо этого, преподаватель может создать на основе записи в расписании неограниченное кол-во записей журнала определенного типа (лекция, семинар, лабораторная работа, практика, домашнее задание и т.д).
В Журнале преподаватель может зафиксировать информацию об оценках, посещаемости студентов и задать домашнее задание.
Создание, удаление, редактирование занятия, а также чат со студентом выглядят так:
Интерфейс студента
Самое важное, что нужно знать студенту — расписание занятий, успеваемость и домашнее задание. По аналогии с интерфейсами администратора и преподавателя, была создана страница просмотра расписания занятий. Немного изменен внешний вид и убран лишний функционал.
На странице успеваемости студент просматривает текущие оценки и средний балл по предметам. Также есть фильтр по семестрам.
Чат-бот
На чат-бота мы возложили пока простые обязанности отправки сообщения об изменении в расписании и отправку сетки расписания по запросу. Можно запросить расписание как на определенный день, так и на всю неделю. Чат-бот, как сервис доступный в чатах портала, автоматом доступен на мобильной версии портала — крайне удобно. Таким образом мы обеспечили простой доступ к расписанию и с мобильных устройств.
Был большой соблазн в качестве иконки чат-бота использовать такое изображение
Но мы не стали, посчитав, что это слишком иронично получится.
Контроль качества
Мы ревностно относимся к результату своей работы, ошибки приложения и проблемы у пользователей при работе с нашим приложением больно ранят наши сердца.
Для обеспечения кардио-безопасности и качественной работы приложения мы применяем комплекс мер.
Сборка и тесты
Мы используем 3 независимых сервера под разработку тестирование и эксплуатацию.
В разработке действует модель git-flow.
Для авто тестирования мы используем codeception, тестируем пользовательские сценарии и api данных с сайта.
Для сборки приложения на staging и production мы используем gitlab-ci, размещая файлы по нужным директориям приложений (у нас их несколько по факту получилось см. выше), запускаем сборку front-end npm run build, composer и авто тесты.
Контроль ошибок
Как бы мы ни старались все покрыть тестами невозможно, всегда найдутся исключительные ситуации. Так или иначе ошибок не избежать. Если их не избежать, то наверняка можно как-то контролировать?
Наверное, все мы привыкли к тому факту, что если на сервере вдруг произошла ошибка, то она записывается в логи и после ее можно диагностировать. Но что делать с ошибками, которые происходят на фронтенде? Все что происходит у клиента, у него и остается. Если ошибка достаточно критичная, то можно узнать о ней, через гневный отзыв клиента. Это явно не наш метод.
Чтобы отлавливать ошибки, которые могут возникнуть в процессе работы «production» приложения, мы используем и жутко радуемся этому сервису https://sentry.io. Данный сервис производит сборку как клиентских так и серверных ошибок. Все ошибки отслеживаются и должны быть зарезолвены.
Бонусом мы настроили интеграцию в slack, так, чтобы в момент возникновения прецедента, в проектном канале появлялось соответствующее уведомление. Благодаря этому мы можем узнать об ошибках раньше, чем будет клиентом создан тикет в системе поддержки, и оперативно принять меры, если ситуация критическая.
Мониторинг
Для отслеживания состояния production машины используется zabbix. Отслеживаются все основные параметры машины от доступности до использования ресурсов.
Диагностика
При формировании связей сайт — портал, формировании расписания, могут возникнуть конфликтные ситуации, нарушающие целостность данных. Например, может быть ситуация, когда одному преподавателю по ошибке на один и тот же день и одну и туже пару назначают несколько занятий.
Человек — не робот. За всем точно не уследишь. Для решения таких проблем мы собрали экран диагностики «Контроль», в котором разместили в виде чек-листа список проверок и их результат.
Как работает диагностика
Диагностику неплохо бы запускать в ситуациях, которые потенциально могут создать проблемы, например, при формировании расписания. Можно на «месте» делать сразу проверку, но мы применили более гибкое и масштабируемое решение.
Чек-лист контроля мы планировали как расширяемый. Некоторые операции могут быть достаточно ресурсоемкими. Чтобы не блокировать работу приложения диагностикой, используя gearman, отправляем задачу на проверку в очередь, при возникновении «потенциально опасного» события и первом запуске приложения администратора.
В случае ошибки по одному из чеков мы запускаем нашего «злого робота» с настоятельной рекомендацией пройти в раздел контроля.
Диагностику мы не стали выносить в «сборочные» тесты, т.к разработчик может не решить, например, конфликт расписания.
Что мы использовали в работе
С технической точки зрения весь проект достаточно сложный, поэтому к выбору технологий мы подошли основательно. В качестве серверного языка программирования мы решили использовать PHP, в купе с СУБД MySQL. Данная связка очень популярна в мире web-разработки, более того, хорошо известна нашей команде.
Поскольку в основе проекта лежит использование CRM Bitrix 24, то очень много завязано на использовании API портала. Очень часто будет использоваться вызов различных методов, следовательно нужно по максимуму упростить эту часть. Для этой цели мы решили использовать bitrix24-php-sdk, которая предоставляет удобный объектный подход. Заодно немного участвуем в разработке этой бибилиотеки.
Писать на native PHP в 2017 году далеко не лучший вариант, тем более для проекта такого размера. Поэтому нужно было выбрать фреймворк. Из требований — наличие MVC, ORM, миграций и сидов, работа с очередями. Под эти требования подходят много фреймворков Laravel, YII2, Zend, Phalcon и пр. малоизвестные. Мы решили выбрать Laravel, поскольку у нашей команды было больше опыта работы именно с ним.
С точки зрения фронтенда выбор хорошего инструмента был не менее важен. Мы остановили свой взгляд на связке React/Redux/React Router.
В основе React лежит компонентный подход, что очень нам подходит. Удобно реализовать один компонент и затем многократно использовать его в нескольких местах приложения.
Так, например, было с компонентом для вывода расписания занятий. В общих чертах он одинаков как для студента, так и для администратора и преподавателя. Все отличительные особенности хорошо конфигурируются через свойства компонентов.
Также у React огромное комьюнити и большое число различных реализованных компонентов. Нам очень помог компонент react dnd при реализации механизма переноса занятий.
Для написания стилей мы использовали препроцессор-Less, который существенно позволяет уменьшить количество строк CSS-кода, за счет использования иерархических структур, примесей и переменных.
За сборку проекта у нас отвечает Webpack. На самом деле выбор сборщика был не так принципиален, поскольку каких-то особенных моментов или требований у нас не было.
Заключение
Работая над проектом мы получили опыт, который сложно описать в рамках одного поста. Раскрытие отдельных вопросов разумнее делать отдельными публикациями.
