Преамбула — Часть 1 — Часть 2 — Часть 3 — Часть 4

Теперь заключительная часть квинтета постов о построении билда. Эта часть специфична для стека ABAP, хотя концепции могут применяться и к другим стекам.

Вероятно, вы развертывали свой код на шлюзе вручную с помощью предоставленной SAP программы /ui5/ui5_repository_load. Это в значительной степени собачий завтрак с точки зрения пользовательского опыта, и он делает много странных вещей. Есть некоторые подводные камни, которые могут вызвать головную боль, если вы о них не знаете (например, он будет игнорировать любую папку с именем build, даже если вы выберете ее в качестве корневой папки для загрузки… wat).

У нас есть этот скрипт сборки youbeaut, который может автоматически создавать ваш код и имеет авторизованный доступ к вашему серверу шлюза. Можем ли мы использовать это, чтобы разместить нашу сборку на шлюзе? Ответ прост: да. Теперь, к сожалению, нет стандартного способа сделать это легко, поэтому нам придется немного поработать над настройкой.

Служба развертывания
 Итак, как мы можем взаимодействовать со шлюзом из нашего скрипта сборки? Итак, мы создаем веб-приложения, использующие сервисы OData, и у нас уже есть аутентифицированный сеанс OData, почему бы просто не создать что-нибудь с его помощью?

У нас есть программа SAP, которую мы можем вызывать из кода службы ABAP, поэтому давайте создадим интерфейс OData для этой программы. Что ж… вы столкнетесь с проблемой — эта программа ожидает ввода от файловой системы. Вероятно, мы могли бы загрузить файлы, а затем сохранить их где-нибудь на диске, а затем передать путь — но это будет решать свои проблемы. Мы могли бы модифицировать программу, чтобы она принимала файлы напрямую, но это тоже немного неуклюже — отправлять файлы по одному было бы некрасиво и неэффективно, поэтому в идеале мы хотели бы заархивировать их перед отправкой.

Если вы немного покопаетесь, то обнаружите, что существует также программа под названием /ui5/ui5_repository_load_http. Эта программа позволяет нам загружать zip-файл. У нас та же проблема с этой программой, принимающей путь к файлу, поэтому, к сожалению, нам придется настроить программу так, чтобы она принимала zip-блоб. Но это довольно просто, и руководство по этому вопросу находится на github.

Транспорты
Кроме того, вы можете заметить, что была одна полулениво реализованная функция — транспорты. Программа ожидает, что вы предоставите ей транспорт, который может заблокировать ВСЕ необходимые файлы и приложение BSP. В то время как блокирующий транспорт можно легко найти (это будет сделано за вас, если вы будете следовать руководству), создать его довольно сложно. Есть над чем подумать. Если у вас еще нет блокировки, как с этим справиться? Должны ли мы просто создать новый транспорт? Что, если у вас уже есть открытые под вашим именем, которые вы хотели использовать, должны ли мы просто использовать их? Кроме того, с такими инструментами, как Rev-Trac, мы не хотели автоматически создавать транспорты и заставлять вас помнить об управлении ими постфактум.

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

Интеграция Gulp
Итак, теперь, когда у нас есть служба, как мы можем отправлять файлы? Ну, тут действительно два варианта.

Первый вариант — добавить его как задачу gulp. Хотя это не лучшее место. Допустим, вы настроили новую задачу под названием gulp deploy, которая получает новый токен сеанса и отправляет файлы. Но скажем, вы только что закончили какую-то функцию и хотите развернуть ее для тестирования — но это еще не все. Итак, чтобы развернуть сейчас, вам нужно убить свой сервер, а затем запустить задачу развертывания, а затем перезапустить сервер, чтобы продолжить работу. Довольно неуклюжий опыт, верно? Особенно, когда у вас уже есть токен авторизации для вашего текущего экземпляра сервера (это означает, что вы, по сути, выбрасываете его и тратите время на получение двух новых — один для развертывания и один для нового экземпляра сервера).

Вместо этого, если у нас уже есть токен на нашем сервере разработки, давайте воспользуемся им — давайте создадим способ запустить развертывание, не касаясь консоли. Browsersync позволяет нам легко создавать для него собственное промежуточное программное обеспечение, поэтому мы можем настроить некоторое промежуточное программное обеспечение, которое обслуживает статическую HTML-страницу, когда пользователь запрашивает путь «/deploy». Лично мне нравится вставлять подтверждение «вы действительно это имеете в виду», поэтому я настраиваю две страницы — «/deploy», которая показывает конфигурацию, в которую вы развертываете, и «/deploy/yes», который фактически запускает развертывание.

Но веб-страница не имеет прямого доступа к файловой системе, так как же она может извлекать и архивировать файлы для загрузки? Ну… нельзя. Так что нашему промежуточному ПО придется делать за нас всю тяжелую работу. Мы можем использовать zip-folder, чтобы заархивировать наши файлы и получить большой двоичный объект, и btoa (binary to base-64 a scii), чтобы использовать представление двоичного файла в формате base-64 для вызова OData. Здесь у вас есть два варианта: первый — использовать узел для вызова службы OData, второй — использовать браузер для вызова службы OData. Я не думаю, что это действительно имеет значение в любом случае, но я решил пойти со вторым, то есть мне нужно внедрить блоб base-64, а также некоторую конфигурацию в статическую HTML-страницу, но это означает, что я могу легко повторно использовать наш прокси промежуточное ПО для вызова службы.

Теперь последнее соображение — что произойдет, если вы закроете свой сервер, но потом поймете, что хотите его развернуть. Либо вы можете запустить сервер gulp, открыть /deploy, а затем закрыть все, когда это будет сделано, либо мы можем добавить задачу, которая сделает это за вас. Чтобы сохранить открытие нового экземпляра браузера, вы можете снова использовать электрон, чтобы быстро открыть / закрыть контейнер для отображения страниц развертывания, и таким образом вы можете очистить сервер, когда окно закрыто.

Милая, ваша сборка отправлена ​​на сервер, готовая к тестированию и переносу. Вы заметите, что вся ваша папка сборки будет отправлена ​​​​на сервер, а это означает, что при необходимости вы все равно можете запускать режим отладки вне шлюза (хорошо для отладки в QAS/PRD).

Будущее
В будущем есть только несколько вещей, которые я хотел бы добавить в скрипт сборки:

  • Тестирование. Я бы хотел интегрировать что-то вроде Jest в инструмент. Jest быстро стал одним из лучших фреймворков для тестирования, потому что он быстрый и простой в использовании. Он работает внутри самого NodeJS, поэтому вы тратите меньше времени на запуск и управление экземплярами браузера, а ваши тесты могут быть написаны на простом и понятном JavaScript.
  • Работает местная библиотека. В зависимости от того, что вы делаете, обслуживание библиотеки вне шлюза может быть неоптимальным выбором. Возможность обслуживать локальную копию библиотек ускорит реакцию, а также позволит вести автономную разработку.
  • Издевательство над сервисом. В вашем коде UI5 есть возможность сделать имитацию службы, хотя я лично ненавижу это, потому что это означает, что вам нужно переплести тестовый код с производственным кодом. Более изящным способом было бы настроить обработчик, который позволяет службе обслуживать фиктивные данные вместо реальных данных. Было бы хорошо также включить офлайн-разработку.