• https://docs.gitlab.com/ee/user/project/releases/#create-a-release
Тег выпуска должен начинаться с буквы v — например, v1.4.7, а не 1.4.7.
Прежде чем создавать выпуск, вам следует убедиться, что вы обновили все ссылки на версию в исходных файлах, например, в shard.yml или любых константах VERSION.
Если проект представляет собой библиотеку, то это все, что нужно. Другие приложения смогут использовать новую версию, shards install или shards update, в зависимости от того, является ли это новой или существующей зависимостью. Если проект представляет собой приложение, необходимо выполнить еще несколько шагов, чтобы пользователи могли загружать готовые двоичные файлы для его использования.
Создание производственных двоичных файлов
Хотя это было предсказано в Главе 6 «Параллелизм», в основном мы собирали двоичные файлы с помощью команды crystal build file.cr и ее эквивалента. Эти команды подходят для разработки, но они не создают полностью оптимизированный двоичный файл для производственной рабочей нагрузки/среды, подходящий для распространения.
Чтобы создать двоичный файл выпуска, нам нужно передать флаг --release. Это сообщит бэкэнду LLVM, что он должен применить к коду все возможные оптимизации. Другой вариант, который мы можем передать, — это --no-debug. Это заставит компилятор Crystal не включать символы отладки, в результате чего двоичный файл будет меньшего размера. Остальные символы можно удалить с помощью команды strip. Дополнительную информацию см. на https://man7.org/linux/man-pages/man1/strip.1.html.
После сборки с использованием этих двух вариантов вы получите меньший по размеру и более производительный двоичный файл, который будет пригоден для тестирования или использования в производственной среде. Однако он не будет переносимым, а это означает, что для него по-прежнему потребуется, чтобы у пользователя были установлены все среды выполнения Crystal и системные зависимости для конкретных приложений. Чтобы создать более портативный двоичный файл, нам нужно будет статически связать его.
Статическое связывание так же просто, как добавление параметра --static, но с одной особенностью. Загвоздка в том, что не все зависимости хорошо работают со статическим связыванием, причем главным нарушителем является libc, учитывая, что от него зависит Crystal. Вместо этого можно использовать musl-libc, который имеет лучшую поддержку статического связывания. Хотя это и не единственный способ, рекомендуемый способ создания статического двоичного файла — использовать Alpine Linux. Предоставляются официальные образы Crystal Docker на основе Alpine, которые можно использовать для упрощения этого процесса.
Для этого требуется, чтобы собственные зависимости приложения имели статические версии, доступные в базовом образе. Флаг --static также не гарантирует на 100%, что полученный двоичный файл будет полностью статически связан. В некоторых случаях статическое связывание может быть менее идеальным, чем динамическое связывание.
Например, если в зависимости обнаружена и исправлена критическая ошибка, двоичный файл необходимо будет перекомпилировать/выпустить с использованием новой версии этого пакета. Если бы он был динамически связан, пользователь мог бы просто обновить пакет, и он начал бы использовать новую версию.
Статическая компоновка также увеличивает размер двоичного файла, поскольку он должен включать код всех его зависимостей. В конце концов, стоило бы подумать, какой подход вам следует использовать в зависимости от требований распространяемой вами программы.
Пример команды для этого будет выглядеть так:
docker run --rm -it -v $PWD:/workspace -w /workspace crystallang/crystaclass="underline" latest-alpine crystal build app.cr --static --release --no-debug
При этом контейнер запускается с использованием последнего образа Crystal Alpine, монтируется в него текущий каталог, создается статический рабочий двоичный файл, а затем происходит выход и удаление контейнера.
Мы можем обеспечить статическую компоновку полученного двоичного файла с помощью команды ldd, доступной в Linux. Пользователи macOS могут использовать otool -L. Передача этой команды с именем нашего двоичного файла вернет все общие объекты, которые он использует, или статически связанные, если их нет. Эту команду можно использовать для проверки новых двоичных файлов, чтобы предотвратить любые неожиданности в дальнейшем, когда вы запустите их в другой среде.